Working on a haxeui project using the heaps.io backend I occasionally got crashes of my app directly on startup (starting it via hashlink as well as using compiled hl/c).
Trying to nail the issue, I compiled my hl/c stuff with address-sanitzer and immediately got a hit in the generated init-code.
To investigate further, I added some printfs to the generated hl/c code and found, that the issue originates from the enum-init-code for some enums from heaps.io, in the run below it seems EventKind triggered it, but I also saw other enums triggering it.
The code seems iterating over some fields (see how r2 goes from 0 to 7) but at some point, the next iteration breaks and in this case, '8' ends up in r4 which is when interpreted as a pointer and triggers ASAN (within hl_types_ArrayObj_push).
To ensure, the issue is not related to my code, which includes native extensions, I tried to reproduce with the heaps.io-hello-world-project.
ASAN fires for this as well directly on startup and it is also an out-of-bounds READ but different location:
AddressSanitizer:DEADLYSIGNAL
=================================================================
==19477==ERROR: AddressSanitizer: SEGV on unknown address 0x00004020000d (pc 0x7c958e11ab30 bp 0x7ffc084c5390 sp 0x7ffc084c5368 T0)
==19477==The signal is caused by a READ memory access.
#0 0x7c958e11ab30 in __sanitizer_internal_memmove /usr/src/debug/gcc/gcc/libsanitizer/sanitizer_common/sanitizer_libc.cpp:75
#1 0x7c958dfa4eb8 in hl_bytes_blit (/tmp/hashlink/tmp/hashlink-1.14/build//bin/libhl.so.1+0x69eb8) (BuildId: 771e3fba1794b2b8e54a9f23982d5d7ce0bef4ce)
#2 0x60572e9f914d in hl_types_ArrayBytes_hl_UI16___expand hl/types/ArrayBytes_hl_UI16.c:1051
#3 0x60572e9f4fb6 in hl_types_ArrayBytes_hl_UI16_push hl/types/ArrayBytes_hl_UI16.c:186
#4 0x60572ea1d77b in h3d_impl_MemoryManager_initIndexes h3d/impl/MemoryManager.c:115
#5 0x60572ea1d57d in h3d_impl_MemoryManager_init h3d/impl/MemoryManager.c:74
#6 0x60572ea14fe6 in h3d_Engine_onCreate h3d/Engine.c:505
#7 0x60572ed17631 in h3d_impl_GlDriver_init__$1 h3d/impl/GlDriver.c:5603
#8 0x60572ebfbc18 in haxe_Timer_delay__$1 haxe/Timer.c:70
#9 0x60572ebfb880 in haxe_Timer_new__$1 haxe/Timer.c:21
#10 0x60572ebf77b4 in sys_thread_EventLoop_progress sys/thread/EventLoop.c:232
#11 0x60572ee5b32f in hxd_System_runMainLoop hxd/System.c:312
#12 0x60572ebfbc49 in haxe_Timer_delay__$1 haxe/Timer.c:70
#13 0x60572ebfb880 in haxe_Timer_new__$1 haxe/Timer.c:21
#14 0x60572ebf91a5 in sys_thread_EventLoop_loop sys/thread/EventLoop.c:491
#15 0x60572f08c3d5 in sys_thread__Thread_Thread_Impl__processEvents sys/thread/_Thread/Thread_Impl_.c:43
#16 0x60572f109cba in fun$init hl/init.c:11886
#17 0x60572f16d70b in hl_entry_point /tmp/repro3/build/Main.c:521
#18 0x60572f10c96c in hlc_static_call hl/reflect.c:17
#19 0x7c958dfab1e9 in hl_call_method (/tmp/hashlink/tmp/hashlink-1.14/build//bin/libhl.so.1+0x701e9) (BuildId: 771e3fba1794b2b8e54a9f23982d5d7ce0bef4ce)
#20 0x7c958dfab4d0 in hl_dyn_call (/tmp/hashlink/tmp/hashlink-1.14/build//bin/libhl.so.1+0x704d0) (BuildId: 771e3fba1794b2b8e54a9f23982d5d7ce0bef4ce)
#21 0x7c958dfac2f4 in hl_dyn_call_safe (/tmp/hashlink/tmp/hashlink-1.14/build//bin/libhl.so.1+0x712f4) (BuildId: 771e3fba1794b2b8e54a9f23982d5d7ce0bef4ce)
#22 0x60572e9d217a in main /tmp/hashlink/tmp/hashlink-1.14/build//../src/hlc_main.c:158
#23 0x7c958da59e07 (/usr/lib/libc.so.6+0x25e07) (BuildId: 98b3d8e0b8c534c769cb871c438b4f8f3a8e4bf3)
#24 0x7c958da59ecb in __libc_start_main (/usr/lib/libc.so.6+0x25ecb) (BuildId: 98b3d8e0b8c534c769cb871c438b4f8f3a8e4bf3)
#25 0x60572e9d19b4 in _start (/tmp/repro3/build/Main+0x4089b4) (BuildId: 2eaee664e7adb445e3b705f611a49f14b8d70801)
The Main.hx is simply the hello-world-heaps example:
class Main extends hxd.App {
override function init() {
var tf = new h2d.Text(hxd.res.DefaultFont.get(), s2d);
tf.text = "Hello World !";
}
static function main() {
new Main();
}
}
Compiled to hl/c like this:
haxe --main Main -lib heaps -lib hlsdl -debug -hl build/Main.c
Version & system Info:
Working on a haxeui project using the heaps.io backend I occasionally got crashes of my app directly on startup (starting it via hashlink as well as using compiled hl/c).
Trying to nail the issue, I compiled my hl/c stuff with address-sanitzer and immediately got a hit in the generated init-code.
To investigate further, I added some printfs to the generated hl/c code and found, that the issue originates from the enum-init-code for some enums from heaps.io, in the run below it seems EventKind triggered it, but I also saw other enums triggering it.
The code seems iterating over some fields (see how r2 goes from 0 to 7) but at some point, the next iteration breaks and in this case, '8' ends up in r4 which is when interpreted as a pointer and triggers ASAN (within hl_types_ArrayObj_push).
The characters printed out above originate from my instrumentation in
And here the generated hl_types_ArrayObj_push function:
To ensure, the issue is not related to my code, which includes native extensions, I tried to reproduce with the heaps.io-hello-world-project. ASAN fires for this as well directly on startup and it is also an out-of-bounds READ but different location:
The Main.hx is simply the hello-world-heaps example:
Compiled to hl/c like this:
haxe --main Main -lib heaps -lib hlsdl -debug -hl build/Main.cAnd natively compiled like so:
gcc -o Main Main.c -I . -I ${HL}/../src -L ${HL}/bin/ -lhl -g -lSDL2 ${HL}/bin/uv.hdll ${HL}/bin/sdl.hdll ${HL}/bin/fmt.hdll ${HL}/bin/ui.hdll -luv -fsanitize=address -lSDL2 -lmWhere HL points to the hashlink-1.14 build/source.
The hello-world Haxe example runs smoothly though.