tarantool

Statically built binary crashed (libobjc and libpthread)

Bug #980569 reported by Konstantin Shulgin on 2012-04-13

This bug affects 1 person

Affects		Status	Importance	Assigned to	Milestone
	tarantool	Fix Released	Critical	Pavel Cherenkov	tarantool 1.4.6

Bug Description

Statically built binary crashed before enter to main. It happen because libobjc initializing above libpthread.

GDB back trace:
Program received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
(gdb) bt
#0 0x0000000000000000 in ?? ()
#1 0x000000000044ccda in __objc_init_thread_system ()
#2 0x0000000000447a5c in __objc_exec_class ()
#3 0x000000000053fa47 in __libc_csu_init ()
#4 0x000000000053f21a in __libc_start_main ()
#5 0x0000000000404ac1 in _start ()

Revision history for this message

Konstantin Shulgin (konstantin-shulgin) wrote on 2012-04-13:

Coredump Edit (18.0 KiB, application/x-tar)

Revision history for this message

Konstantin Shulgin (konstantin-shulgin) wrote on 2012-04-13:

example.tar.bzip2 Edit (614 bytes, application/x-tar)

I have made a little example where the bug can be reproduced.

Revision history for this message

Pavel Cherenkov (pcherenkov) wrote on 2012-04-13:

Found a more-or-less relevant case to look at: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52590 .

The culprit appears to be in faulty (NULL) resolution of references to pthread methods when invoked from within clib's initialization, the article (above) suggests that not the *all* of [required] libpthread.a objects get included into the static executable by the linker, so we might want to force the inclusion of the *WHOLE* of libpthread.a using -Wl,--whole-archive/-Wl,--no-whole-archive block.

This is exactly what the currently committed fix does - no SIGSEGV at initialization now.

On a more general thread of thought, static linking is often looked down, as seen in this article:
http://www.akkadia.org/drepper/no_static_linking.html