There is no backtrace
(gdb) exec-file /ws/sarvi-sjc/wisktrack/tests/testprog64
(gdb) run
Starting program: /ws/sarvi-sjc/wisktrack/tests/testprog64 readlink
During startup program terminated with signal SIGSEGV, Segmentation fault.
(gdb) bt
No stack.
(gdb) show environment LD_PRELOAD
LD_PRELOAD = /nobackup/sarvi/iosxr/platforms/common/thinxr/build/obj-x86-linux/libcpio_preload.so:/ws/sarvi-sjc/wisktrack/${LIB}/libwisktrack.so
(gdb) show args
Argument list to give program being debugged when it is started is "readlink".
(gdb)
(gdb) exec-file /ws/sarvi-sjc/wisktrack/tests/testprog64
(gdb) run
Starting program: /ws/sarvi-sjc/wisktrack/tests/testprog64 readlink
During startup program terminated with signal SIGSEGV, Segmentation fault.
(gdb) bt
No stack.
(gdb) show environment LD_PRELOAD
LD_PRELOAD = /nobackup/sarvi/iosxr/platforms/common/thinxr/build/obj-x86-linux/libcpio_preload.so:/ws/sarvi-sjc/wisktrack/${LIB}/libwisktrack.so
(gdb) show args
Argument list to give program being debugged when it is started is "readlink".
(gdb)
The segfault seems to be happening in the library constructor of libwisktrack.so or earlier.
If I dont do eprintln!() in the constructor, the crash doesnt happen, when I replace it with a simple assignment statement.
That said, gdb seems to crashig early and without backtrace.
It almost, looks to me like there is something about the RUST compiled code running in the library constructor context that is causing the crash. If wrote a comparable "Hello World" LD_PRELOAD code in C, the crash doesnt happen.
Do you think it is worth taking this thread to rust internals forum for some extra eyes on the problem?