You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 then 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 then 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.
The text was updated successfully, but these errors were encountered: