Created attachment 414112 [details] build.log (xz compressed due to size) Building gtk+-3.16.7 on amd64-fbsd results in a segmentation fault in gtk-query-immodules-3.0 ../../gtk/gtk-query-immodules-3.0 im-am-et.la im-cedilla.la im-cyrillic-translit.la im-inuktitut.la im-ipa.la im-multipress.la im-thai.la im-ti-er.la im-ti-et.la im-viqr.la im-xim.la > immodules.cache Makefile:1500: recipe for target 'immodules.cache' failed gmake[3]: *** [immodules.cache] Segmentation fault (core dumped) gmake[3]: *** Deleting file 'immodules.cache' Stack trace: (gdb) run Starting program: /var/tmp/portage/x11-libs/gtk+-3.16.7/work/gtk+-3.16.7-abi_x86_64.amd64_fbsd/gtk/.libs/gtk-query-immodules-3.0 Program received signal SIGSEGV, Segmentation fault. 0x000000080757d513 in g_type_name () from /usr/lib/libgobject-2.0.so.0 (gdb) where #0 0x000000080757d513 in g_type_name () from /usr/lib/libgobject-2.0.so.0 #1 0x000000080756a44f in g_param_type_register_static () from /usr/lib/libgobject-2.0.so.0 #2 0x000000080756bd4f in ?? () from /usr/lib/libgobject-2.0.so.0 #3 0x000000080755a57a in ?? () from /usr/lib/libgobject-2.0.so.0 #4 0x0000000800606754 in ?? () from /libexec/ld-elf.so.1 #5 0x000000080060aafe in ?? () from /libexec/ld-elf.so.1 #6 0x0000000800604465 in ?? () from /libexec/ld-elf.so.1 #7 0x0000000000000000 in ?? ()
(In reply to Chí-Thanh Christopher Nguyễn from comment #0) > 0x000000080756bd4f in ?? () from /usr/lib/libgobject-2.0.so.0 This level of detail isn't exactly helpful :) Please rebuild dev-libs/glib and whatever package is responsible for ld-elf.so.1 with -ggdb in CFLAGS to get a backtrace that shows what is actually happening. And then try to build gtk+ with -ggdb too, so the gtk-query-immodules-3.0 executable also has debugging symbols.
new stack trace with debug info: Program received signal SIGSEGV, Segmentation fault. 0x0000000807580513 in g_type_name (type=<optimized out>) at /var/tmp/portage/dev-libs/glib-2.44.1/work/glib-2.44.1/gobject/gtype.c:3321 3321 /var/tmp/portage/dev-libs/glib-2.44.1/work/glib-2.44.1/gobject/gtype.c: No such file or directory. (gdb) where #0 0x0000000807580513 in g_type_name (type=<optimized out>) at /var/tmp/portage/dev-libs/glib-2.44.1/work/glib-2.44.1/gobject/gtype.c:3321 #1 0x000000080756d44f in g_param_type_register_static (name=0x80758dccc "GParamValueArray", pspec_info=pspec_info@entry=0x8077a15e0 <pspec_info>) at /var/tmp/portage/dev-libs/glib-2.44.1/work/glib-2.44.1/gobject/gparam.c:1410 #2 0x000000080756ed4f in _g_param_spec_types_init () at /var/tmp/portage/dev-libs/glib-2.44.1/work/glib-2.44.1/gobject/gparamspecs.c:1512 #3 0x000000080755d57a in gobject_init_ctor () at /var/tmp/portage/dev-libs/glib-2.44.1/work/glib-2.44.1/gobject/gtype.c:4450 #4 0x0000000800606754 in objlist_call_init (lockstate=0x7fffffffe1b0, list=<optimized out>) at /var/tmp/portage/sys-freebsd/freebsd-libexec-10.2/work/libexec/rtld-elf/rtld.c:2433 #5 0x000000080060aafe in _rtld (sp=<optimized out>, exit_proc=<optimized out>, objp=<optimized out>) at /var/tmp/portage/sys-freebsd/freebsd-libexec-10.2/work/libexec/rtld-elf/rtld.c:662 #6 0x0000000800604465 in .rtld_start () at /var/tmp/portage/sys-freebsd/freebsd-libexec-10.2/work/libexec/rtld-elf/amd64/rtld_start.S:39 #7 0x0000000000000000 in ?? ()
(In reply to Chí-Thanh Christopher Nguyễn from comment #2) This looks like a crash in libgobject's ctor when it's being loaded by the dynamic loader. Which simply should never happen :/ Please check whether other things on your system that are based on gobject are also crashing. Because a crash at such a basic level should be affecting everything related to gnome, xfce etc.
Also, has *any* version of gtk+ or libgobject worked on this system? Which versions worked? Please check what changed in your toolchain etc. since that time?
It is a new system I am setting up for the Prague LinuxDays. gtk+-2.4.28-r1 built fine and firefox runs fine. I am seeing similar a problem with x11-libs/pango[X] though, pango-querymodules also segfaults during the build.
I am currently looking through the patches that FreeBSD applies to glib https://svnweb.freebsd.org/ports/head/devel/glib20/files/ to see if there is anything relevant. This is the stacktrace of pango, it also fails in gobject_init_ctor (gdb) where #0 0x0000000802bde513 in g_type_name (type=<optimized out>) at /var/tmp/portage/dev-libs/glib-2.44.1/work/glib-2.44.1/gobject/gtype.c:3321 #1 0x0000000802bcb44f in g_param_type_register_static (name=0x802bebccc "GParamValueArray", pspec_info=pspec_info@entry=0x802dff5e0 <pspec_info>) at /var/tmp/portage/dev-libs/glib-2.44.1/work/glib-2.44.1/gobject/gparam.c:1410 #2 0x0000000802bccd4f in _g_param_spec_types_init () at /var/tmp/portage/dev-libs/glib-2.44.1/work/glib-2.44.1/gobject/gparamspecs.c:1512 #3 0x0000000802bbb57a in gobject_init_ctor () at /var/tmp/portage/dev-libs/glib-2.44.1/work/glib-2.44.1/gobject/gtype.c:4450 #4 0x0000000800606754 in objlist_call_init (lockstate=0x7fffffffe200, list=<optimized out>) at /var/tmp/portage/sys-freebsd/freebsd-libexec-10.2/work/libexec/rtld-elf/rtld.c:2433 #5 0x000000080060aafe in _rtld (sp=<optimized out>, exit_proc=<optimized out>, objp=<optimized out>) at /var/tmp/portage/sys-freebsd/freebsd-libexec-10.2/work/libexec/rtld-elf/rtld.c:662 #6 0x0000000800604465 in .rtld_start () at /var/tmp/portage/sys-freebsd/freebsd-libexec-10.2/work/libexec/rtld-elf/amd64/rtld_start.S:39 #7 0x0000000000000000 in ?? ()
Potentially relevant: https://bugzilla.gnome.org/show_bug.cgi?id=756139 Maybe freebsd's libc, like musl, doesn't preserve the ctor order?
Check if either of the following works (it should force ctor order hopefully): LD_PRELOAD="/usr/lib/libglib-2.0.so.0" gtk-query-immodules-3.0 or LD_PRELOAD="/usr/lib/libglib-2.0.so.0:/usr/lib/libgobject-2.0.so.0" gtk-query-immodules-3.0
No, I still get the segfault. (gdb) show environment LD_PRELOAD LD_PRELOAD = /usr/lib/libglib-2.0.so.0:/usr/lib/libgobject-2.0.so.0 (gdb) run Starting program: /var/tmp/portage/x11-libs/gtk+-3.16.7/work/gtk+-3.16.7-abi_x86_64.amd64_fbsd/gtk/.libs/gtk-query-immodules-3.0 Program received signal SIGSEGV, Segmentation fault. 0x0000000800b7f513 in g_type_name (type=<optimized out>) at /var/tmp/portage/dev-libs/glib-2.44.1/work/glib-2.44.1/gobject/gtype.c:3321 3321 /var/tmp/portage/dev-libs/glib-2.44.1/work/glib-2.44.1/gobject/gtype.c: No such file or directory. (gdb) where #0 0x0000000800b7f513 in g_type_name (type=<optimized out>) at /var/tmp/portage/dev-libs/glib-2.44.1/work/glib-2.44.1/gobject/gtype.c:3321 #1 0x0000000800b6c44f in g_param_type_register_static (name=0x800b8cccc "GParamValueArray", pspec_info=pspec_info@entry=0x800da05e0 <pspec_info>) at /var/tmp/portage/dev-libs/glib-2.44.1/work/glib-2.44.1/gobject/gparam.c:1410 #2 0x0000000800b6dd4f in _g_param_spec_types_init () at /var/tmp/portage/dev-libs/glib-2.44.1/work/glib-2.44.1/gobject/gparamspecs.c:1512 #3 0x0000000800b5c57a in gobject_init_ctor () at /var/tmp/portage/dev-libs/glib-2.44.1/work/glib-2.44.1/gobject/gtype.c:4450 #4 0x0000000800606754 in objlist_call_init (lockstate=0x7fffffffe170, list=<optimized out>) at /var/tmp/portage/sys-freebsd/freebsd-libexec-10.2/work/libexec/rtld-elf/rtld.c:2433 #5 0x000000080060aafe in _rtld (sp=<optimized out>, exit_proc=<optimized out>, objp=<optimized out>) at /var/tmp/portage/sys-freebsd/freebsd-libexec-10.2/work/libexec/rtld-elf/rtld.c:662 #6 0x0000000800604465 in .rtld_start () at /var/tmp/portage/sys-freebsd/freebsd-libexec-10.2/work/libexec/rtld-elf/amd64/rtld_start.S:39 #7 0x0000000000000000 in ?? ()
Please check if this is specific to gtk/pango module querying, or just gobject alone triggers the problem. Write a dummy 1-line .c file: int main(int argc, const char ** argv) { return 0; } Compile like this: gcc dummy.c `pkg-config --cflags --libs gobject-2.0` -o dummy See if your dummy executable segfaults with the same backtrace. Because it should go through the same gobject_init_ctor() when libgobject is loaded.
The test program compiles and runs without any segfault.
(In reply to Chí-Thanh Christopher Nguyễn from comment #11) Then I am out of suggestions :( Please try with glib-2.46.0-r1 from the gnome overlay: https://gitweb.gentoo.org/proj/gnome.git/tree/dev-libs/glib If that still segfaults, please report upstream, probably to glib maintainers (this affects both gtk+ and pango, and libgobject looks like the common factor): https://bugzilla.gnome.org/enter_bug.cgi?product=glib&component=gobject and add gnome@gentoo.org to the CC list.
(In reply to Alexandre Rostovtsev from comment #12) Also, when reporting to upstream, paste the backtrace into a comment because they have some special bugzilla magic to identify similar bactraces.
The problem has gone away after upgrading to gcc-5.4.0 and binutils-2.26.1
ok, thanks for the heads up.
