apple2 - dbg/dbg.c
gmake[2]: *** [Makefile:283: ../libwrk/apple2/dbg.o] Segmentation fault (core dumped)
gmake[1]: *** [Makefile:118: apple2] Error 2
gmake: *** [Makefile:7: all] Error 2
~/source/cc65/libsrc $ gdb ../bin/cc65 cc65.core
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "amd64-unknown-openbsd6.7"...
Core was generated by cc65'.
Program terminated with signal 11, Segmentation fault.
Loaded symbols for /home/frakswe/source/cc65/bin/cc65
Reading symbols from /usr/lib/libm.so.10.1...done.
Loaded symbols for /usr/lib/libm.so.10.1
Reading symbols from /usr/lib/libc.so.96.0...done.
Loaded symbols for /usr/lib/libc.so.96.0
Reading symbols from /usr/libexec/ld.so...Error while reading shared library symbols:
Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module /usr/libexec/ld.so]
#0 strlen () at /usr/src/lib/libc/arch/amd64/string/strlen.S:125
125 /usr/src/lib/libc/arch/amd64/string/strlen.S: No such file or directory.
in /usr/src/lib/libc/arch/amd64/string/strlen.S
(gdb) q
What is strlen.S ?;
https://github.com/openbsd/src/blob/master/lib/libc/arch/amd64/string/strlen.S
_ALIGN_TEXT
1:
movq (%rax),%rdx /* get bytes to check */
Testing cc65 on another random file does not crash:
~/source/cc65/libsrc/apple2 $ ../../bin/cc65 closedir.c -o closedir.o
~/source/cc65/libsrc/apple2 $ ls closedir*
closedir.c closedir.o
Building cc65 with clang or gcc v8 , same result.
Why this?
Do you have an explanation why https://travis-ci.org/github/cc65/cc65/builds works?
No. This is infuriating.
Can you give more info like a backtrace from gdb? BTW, your gdb is ancient. 9.2 is current.
yeah i have to come up with something better to get to the bottom of this.
uneven crashing:
zsh: segmentation fault (core dumped) ../../bin/cc65 _scanf.c -o _scanf.o
~/source/cc65/libsrc/common $ ../../bin/cc65 _scanf.c -o _scanf.o
~/source/cc65/libsrc/common $ ../../bin/cc65 _scanf.c -o _scanf.o
zsh: segmentation fault (core dumped) ../../bin/cc65 _scanf.c -o _scanf.o
~/source/cc65/libsrc/common $ ../../bin/cc65 _scanf.c -o _scanf.o
zsh: segmentation fault (core dumped) ../../bin/cc65 _scanf.c -o _scanf.o
~/source/cc65/libsrc/common $ ../../bin/cc65 _scanf.c -o _scanf.o
zsh: segmentation fault (core dumped) ../../bin/cc65 _scanf.c -o _scanf.o
~/source/cc65/libsrc/common $ ../../bin/cc65 _scanf.c -o _scanf.o
~/source/cc65/libsrc/common $ ../../bin/cc65 _scanf.c -o _scanf.o
zsh: segmentation fault (core dumped) ../../bin/cc65 _scanf.c -o _scanf.o
~/source/cc65/libsrc/common $ ../../bin/cc65 _scanf.c -o _scanf.o
zsh: segmentation fault (core dumped) ../../bin/cc65 _scanf.c -o _scanf.o
~/source/cc65/libsrc/common $
clang -fsanitize=address also turns up problems in strlen.
PreparseArg looks like it's calling SB_InitFromString with an uninitialized string directly from xmalloc.
https://github.com/cc65/cc65/blob/fd208fdf0b6f968ba7491dcec1f53be71af08abd/src/cc65/codeent.c#L589
https://github.com/cc65/cc65/blob/fd208fdf0b6f968ba7491dcec1f53be71af08abd/src/common/strbuf.c#L82
PreparseArg was added in 688342e. @acqn
Details below.
clang version 10.0.1
Target: x86_64-apple-darwin16.7.0
apple2 - common/_afailed.c
=================================================================
==29382==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000000bb4 at pc 0x00010c90985a bp 0x7fff5349d7a0 sp 0x7fff5349cf60
READ of size 5 at 0x602000000bb4 thread T0
#0 0x10c909859 in wrap_strlen+0x179 (libclang_rt.asan_osx_dynamic.dylib:x86_64+0x14859)
#1 0x10c83a92c in SB_InitFromString+0x3c (cc65:x86_64+0x1000db92c)
#2 0x10c76473b in PreparseArg+0xfb (cc65:x86_64+0x10000573b)
#3 0x10c764bdc in NewCodeEntry+0x20c (cc65:x86_64+0x100005bdc)
#4 0x10c79ef2a in CS_AddVLine+0xefa (cc65:x86_64+0x10003ff2a)
#5 0x10c8244c9 in AddCodeLine+0x179 (cc65:x86_64+0x1000c54c9)
#6 0x10c777c0c in g_getimmed+0x8c (cc65:x86_64+0x100018c0c)
#7 0x10c77adde in g_push+0x4e (cc65:x86_64+0x10001bdde)
#8 0x10c803798 in hie_compare+0x4d8 (cc65:x86_64+0x1000a4798)
#9 0x10c8033ff in hie_compare+0x13f (cc65:x86_64+0x1000a43ff)
#10 0x10c801a99 in hie_internal+0x129 (cc65:x86_64+0x1000a2a99)
#11 0x10c803221 in hie4+0xc1 (cc65:x86_64+0x1000a4221)
#12 0x10c801a99 in hie_internal+0x129 (cc65:x86_64+0x1000a2a99)
#13 0x10c8030e1 in hie3+0xc1 (cc65:x86_64+0x1000a40e1)
#14 0x10c801a99 in hie_internal+0x129 (cc65:x86_64+0x1000a2a99)
#15 0x10c7fc8a7 in hie1+0x357 (cc65:x86_64+0x10009d8a7)
#16 0x10c8009f8 in NoCodeConstExpr+0x118 (cc65:x86_64+0x1000a19f8)
#17 0x10c81a228 in DoIf+0x3e8 (cc65:x86_64+0x1000bb228)
#18 0x10c8185b0 in Preprocess+0x630 (cc65:x86_64+0x1000b95b0)
#19 0x10c81e4eb in NextToken+0x14b (cc65:x86_64+0x1000bf4eb)
#20 0x10c7eabd7 in Declarator+0x237 (cc65:x86_64+0x10008bbd7)
#21 0x10c7eaad7 in Declarator+0x137 (cc65:x86_64+0x10008bad7)
#22 0x10c7ea312 in ParseDecl+0xf2 (cc65:x86_64+0x10008b312)
#23 0x10c7a5959 in Compile+0xa69 (cc65:x86_64+0x100046959)
#24 0x10c812bbc in main+0xa7c (cc65:x86_64+0x1000b3bbc)
#25 0x7fffd512d234 in start+0x0 (libdyld.dylib:x86_64+0x5234)
0x602000000bb4 is located 0 bytes to the right of 4-byte region [0x602000000bb0,0x602000000bb4)
allocated by thread T0 here:
#0 0x10c9393d6 in wrap_malloc+0xa6 (libclang_rt.asan_osx_dynamic.dylib:x86_64+0x443d6)
#1 0x10c83d342 in xmalloc+0x12 (cc65:x86_64+0x1000de342)
#2 0x10c764730 in PreparseArg+0xf0 (cc65:x86_64+0x100005730)
#3 0x10c764bdc in NewCodeEntry+0x20c (cc65:x86_64+0x100005bdc)
#4 0x10c79ef2a in CS_AddVLine+0xefa (cc65:x86_64+0x10003ff2a)
#5 0x10c8244c9 in AddCodeLine+0x179 (cc65:x86_64+0x1000c54c9)
#6 0x10c777c0c in g_getimmed+0x8c (cc65:x86_64+0x100018c0c)
#7 0x10c77adde in g_push+0x4e (cc65:x86_64+0x10001bdde)
#8 0x10c803798 in hie_compare+0x4d8 (cc65:x86_64+0x1000a4798)
#9 0x10c8033ff in hie_compare+0x13f (cc65:x86_64+0x1000a43ff)
#10 0x10c801a99 in hie_internal+0x129 (cc65:x86_64+0x1000a2a99)
#11 0x10c803221 in hie4+0xc1 (cc65:x86_64+0x1000a4221)
#12 0x10c801a99 in hie_internal+0x129 (cc65:x86_64+0x1000a2a99)
#13 0x10c8030e1 in hie3+0xc1 (cc65:x86_64+0x1000a40e1)
#14 0x10c801a99 in hie_internal+0x129 (cc65:x86_64+0x1000a2a99)
#15 0x10c7fc8a7 in hie1+0x357 (cc65:x86_64+0x10009d8a7)
#16 0x10c8009f8 in NoCodeConstExpr+0x118 (cc65:x86_64+0x1000a19f8)
#17 0x10c81a228 in DoIf+0x3e8 (cc65:x86_64+0x1000bb228)
#18 0x10c8185b0 in Preprocess+0x630 (cc65:x86_64+0x1000b95b0)
#19 0x10c81e4eb in NextToken+0x14b (cc65:x86_64+0x1000bf4eb)
#20 0x10c7eabd7 in Declarator+0x237 (cc65:x86_64+0x10008bbd7)
#21 0x10c7eaad7 in Declarator+0x137 (cc65:x86_64+0x10008bad7)
#22 0x10c7ea312 in ParseDecl+0xf2 (cc65:x86_64+0x10008b312)
#23 0x10c7a5959 in Compile+0xa69 (cc65:x86_64+0x100046959)
#24 0x10c812bbc in main+0xa7c (cc65:x86_64+0x1000b3bbc)
#25 0x7fffd512d234 in start+0x0 (libdyld.dylib:x86_64+0x5234)
SUMMARY: AddressSanitizer: heap-buffer-overflow (libclang_rt.asan_osx_dynamic.dylib:x86_64+0x14859) in wrap_strlen+0x179
Shadow bytes around the buggy address:
0x1c0400000120: fa fa 05 fa fa fa 07 fa fa fa fd fa fa fa fd fd
0x1c0400000130: fa fa fd fa fa fa fd fd fa fa 00 fa fa fa 03 fa
0x1c0400000140: fa fa 04 fa fa fa fd fa fa fa fd fd fa fa 03 fa
0x1c0400000150: fa fa 05 fa fa fa fd fa fa fa fd fd fa fa fd fa
0x1c0400000160: fa fa fd fa fa fa fd fa fa fa fd fa fa fa 00 00
=>0x1c0400000170: fa fa 04 fa fa fa[04]fa fa fa fa fa fa fa fa fa
0x1c0400000180: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x1c0400000190: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x1c04000001a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x1c04000001b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x1c04000001c0: 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
==29382==ABORTING
backtrace:
(gdb) bt
) at cc65/codeent.c:640
) at cc65/codeseg.c:441
) at cc65/segments.c:242
) at cc65/codegen.c:1065
) at exprdesc.h:233
) at cc65/expr.c:3952
) at cc65/function.c:650
) at cc65/compile.c:310
(gdb) c
https://github.com/cc65/cc65/blob/fd208fdf0b6f968ba7491dcec1f53be71af08abd/src/cc65/codeent.c#L589
The initialization of StrBuf in PreparseArg() is wrong. I've been busy lately but I'll take a look further if the problem persists after the initialization fix.
Thank you jmr for finding the issue and acqn, i applied your fix and OpenBSD is now happy and so am i.
Most helpful comment
clang -fsanitize=addressalso turns up problems instrlen.PreparseArglooks like it's callingSB_InitFromStringwith an uninitialized string directly fromxmalloc.https://github.com/cc65/cc65/blob/fd208fdf0b6f968ba7491dcec1f53be71af08abd/src/cc65/codeent.c#L589
https://github.com/cc65/cc65/blob/fd208fdf0b6f968ba7491dcec1f53be71af08abd/src/common/strbuf.c#L82
PreparseArgwas added in 688342e. @acqnDetails below.