Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

fix builtin_list.c:58:10: fatal error: builtin_proto.h: No such file … #2

Merged
merged 1 commit into from
Dec 31, 2019
Merged

fix builtin_list.c:58:10: fatal error: builtin_proto.h: No such file … #2

merged 1 commit into from
Dec 31, 2019

Conversation

xiaoxiang781216
Copy link
Contributor

…or directory

Make builtin_list.c instead of builtin_list.o depend on builtin_proto.h and builtin_proto.c

Change-Id: I1ac6c9b7172d433f5d74c9dd248869adf1f5e387
Signed-off-by: Xiang Xiao xiaoxiang@xiaomi.com

@xiaoxiang781216
fix builtin_list.c:58:10: fatal error: builtin_proto.h: No such file …
462e0fb 
…or directory

Make builtin_list.c instead of builtin_list.o depend on builtin_proto.h and builtin_proto.c

Change-Id: I1ac6c9b7172d433f5d74c9dd248869adf1f5e387
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
@patacongo patacongo merged commit 8c8c481 into apache:master Dec 31, 2019
@xiaoxiang781216 xiaoxiang781216 deleted the builtin branch December 31, 2019 17:10
@masayuki2009
Copy link
Contributor

Hello @xiaoxiang781216 ,

I noticed that this PR caused a build error for lc823450-xgevk:ipl2 configuration.
Actually the configuration was slightly different from others (e.g. nsh is not used) but there was no error before merging this PR.

make[2]: Entering directory '/home/ishikawa/opensource/RTOS/nuttx/apps/builtin'
make -C registry .updated TOPDIR="/home/ishikawa/opensource/RTOS/nuttx/nuttx" APPDIR="/home/ishikawa/opensource/RTOS/nuttx/apps"
make[3]: Entering directory '/home/ishikawa/opensource/RTOS/nuttx/apps/builtin/registry'
make[3]: *** No rule to make target '.updated'.  Stop.
make[3]: Leaving directory '/home/ishikawa/opensource/RTOS/nuttx/apps/builtin/registry'
Makefile:48: recipe for target 'registry/.updated' failed
make[2]: *** [registry/.updated] Error 2
make[2]: Leaving directory '/home/ishikawa/opensource/RTOS/nuttx/apps/builtin'

@xiaoxiang781216
Copy link
Contributor Author

I will take a look at this afternoon.

@masayuki2009
Copy link
Contributor

I will take a look at this afternoon.

@xiaoxiang781216 Thanks!

@xiaoxiang781216
Copy link
Contributor Author

@masayuki2009 try this PR:
#3
I can build lc823450-xgevk:ipl2 without error with this patch.

@masayuki2009
Copy link
Contributor

@masayuki2009 try this PR:
#3
I can build lc823450-xgevk:ipl2 without error with this patch.

@xiaoxiang781216 Thanks, the patch fixed the build error.

yamt added a commit to yamt/incubator-nuttx-apps that referenced this pull request May 7, 2021
@yamt
netlib_parseurl.c: Fix string overruns
0fe456a 
For EINVAL, it doesn't make sense to keep parsing.
(For E2BIG, it might make some sense.)

Found by LLVM ASan.

```
=================================================================
==81622==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6020000000f2 at pc 0x00010d2746ca bp 0x7ffee29a9980 sp 0x7ffee29a9978
READ of size 1 at 0x6020000000f2 thread T0
    #0 0x10d2746c9 in netlib_parseurl netlib_parseurl.c:121
    apache#1 0x10d26b293 in parseurl webclient.c:479
    apache#2 0x10d265e48 in webclient_perform webclient.c:690
    apache#3 0x10d277c5b in main main.c:210
    apache#4 0x7fff7a06f3d4 in start+0x0 (libdyld.dylib:x86_64+0x163d4)

0x6020000000f2 is located 0 bytes to the right of 2-byte region [0x6020000000f0,0x6020000000f2)
allocated by thread T0 here:
    #0 0x10d3996d3 in wrap_strdup+0x203 (libclang_rt.asan_osx_dynamic.dylib:x86_64+0x3e6d3)
    apache#1 0x10d276abe in main main.c:147
    apache#2 0x7fff7a06f3d4 in start+0x0 (libdyld.dylib:x86_64+0x163d4)

SUMMARY: AddressSanitizer: heap-buffer-overflow netlib_parseurl.c:121 in netlib_parseurl
Shadow bytes around the buggy address:
  0x1c03ffffffc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1c03ffffffd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1c03ffffffe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1c03fffffff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1c0400000000: fa fa fd fd fa fa fd fd fa fa 00 00 fa fa 00 00
=>0x1c0400000010: fa fa 00 fa fa fa 00 00 fa fa 00 06 fa fa[02]fa
  0x1c0400000020: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x1c0400000030: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x1c0400000040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x1c0400000050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x1c0400000060: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
  Shadow gap:              cc
==81622==ABORTING
```
xiaoxiang781216 pushed a commit that referenced this pull request May 8, 2021
@yamt @xiaoxiang781216
netlib_parseurl.c: Fix string overruns
998abe1 
For EINVAL, it doesn't make sense to keep parsing.
(For E2BIG, it might make some sense.)

Found by LLVM ASan.

```
=================================================================
==81622==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6020000000f2 at pc 0x00010d2746ca bp 0x7ffee29a9980 sp 0x7ffee29a9978
READ of size 1 at 0x6020000000f2 thread T0
    #0 0x10d2746c9 in netlib_parseurl netlib_parseurl.c:121
    #1 0x10d26b293 in parseurl webclient.c:479
    #2 0x10d265e48 in webclient_perform webclient.c:690
    #3 0x10d277c5b in main main.c:210
    #4 0x7fff7a06f3d4 in start+0x0 (libdyld.dylib:x86_64+0x163d4)

0x6020000000f2 is located 0 bytes to the right of 2-byte region [0x6020000000f0,0x6020000000f2)
allocated by thread T0 here:
    #0 0x10d3996d3 in wrap_strdup+0x203 (libclang_rt.asan_osx_dynamic.dylib:x86_64+0x3e6d3)
    #1 0x10d276abe in main main.c:147
    #2 0x7fff7a06f3d4 in start+0x0 (libdyld.dylib:x86_64+0x163d4)

SUMMARY: AddressSanitizer: heap-buffer-overflow netlib_parseurl.c:121 in netlib_parseurl
Shadow bytes around the buggy address:
  0x1c03ffffffc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1c03ffffffd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1c03ffffffe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1c03fffffff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1c0400000000: fa fa fd fd fa fa fd fd fa fa 00 00 fa fa 00 00
=>0x1c0400000010: fa fa 00 fa fa fa 00 00 fa fa 00 06 fa fa[02]fa
  0x1c0400000020: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x1c0400000030: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x1c0400000040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x1c0400000050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x1c0400000060: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
  Shadow gap:              cc
==81622==ABORTING
```
@ThePassionate ThePassionate mentioned this pull request Sep 18, 2024
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@xiaoxiang781216 @masayuki2009 @patacongo