User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; fr-FR; rv:1.8.1.3) Gecko/20070321 Firefox/2.0.0.3 Build Identifier: When xfce4-panel is run (version 4.4.1) and if the file panels.xml contains an xfce4-menu item, then it segfaults. Removing this item (by commenting it for instance) prevent the segfault to appear. This problem appears only on SPARC architecture. All the tests have been made with blastwave packages (for xfce and other libs like gtk) Reproducible: Always
Is the Xfce menu available on your system (ie. if it does not exists, the panel might crash because the file/module was not found).
(In reply to comment #1) > Is the Xfce menu available on your system (ie. if it does not exists, the panel > might crash because the file/module was not found). > I hope it's not that. That would be an awful way to handle missing plugins... Anyway, William, would it be possible for you to get a backtrace from that crash?
Hi > Anyway, William, would it be possible for you to get a backtrace from that > crash? I can provide it, but i don't have symbols for my gtk lib and it segfault after 8 calls in gtk. If you really want it, tell me i will reinstall debug version. Has anyone else the problem on solaris sparc ? working or not ?
Here is the bracktrace. I have no symbols for gtk stuff... sorry for that (dbx) run Running: xfce4-panel (process id 2461) Reading fr_FR.ISO8859-15.so.3 Reading xlibi18n.so.2 Reading libxfce.so Reading libmp.so.2 Reading libmd5.so.1 Reading libscf.so.1 Reading libdoor.so.1 Reading libuutil.so.1 Reading libshowdesktop.so Reading libmd5_psr.so.1 Reading libpager.so Reading libtasklist.so Reading libsystray.so Reading libseparator.so Reading liblauncher.so Reading libclock.so Reading libactions.so Reading libpixbufloader-png.so Reading pango-basic-fc.so blue zones computation ------------------------------------------------ blue 0: 'T' 1493f 'H' 1493f 'E' 1493f 'Z' 1493f 'O' 1520r 'C' 1520r 'Q' 1520r 'S' 1520r -- ref = 1493, shoot = 1520 blue 1: 'H' 0f 'E' 0f 'Z' 0f 'L' 0f 'O' -29r 'C' -29r 'U' -29r 'S' -29r -- ref = 0, shoot = -29 blue 2: 'f' 1556r 'i' 1556f 'j' 1556f 'k' 1556f 'd' 1556f 'b' 1556f 'h' 1556f -- ref = 1556, shoot = 1556 blue 3: 'x' 1120f 'z' 1120f 'r' 1147r 'o' 1147r 'e' 1147r 's' 1147r 'c' 1147r -- ref = 1120, shoot = 1147 blue 4: 'x' 0f 'z' 0f 'r' 0f 'o' -29r 'e' -29r 's' -29r 'c' -29r -- ref = 0, shoot = -29 blue 5: 'p' -426f 'q' -426f 'g' -426r 'j' -426r 'y' -426r -- ref = -426, shoot = -426 Reading svg_loader.so Reading librsvg-2.so.2.15.90 Reading libgnomevfs-2.so.0.1400.2 Reading libbonobo-2.so.0.0.0 Reading libgconf-2.so.4.1.0 Reading libbonobo-activation.so.4.0.0 Reading libORBit-2.so.0.1.0 Reading libgthread-2.0.so.0.1200.11 Reading librt.so.1 Reading libgsf-1.so.1.9.1 Reading libcroco-0.6.so.3.0.1 Reading libxml2.so.2.6.26 Reading libpthread.so.1 Reading libssl.so.0.9.8 Reading libcrypto.so.0.9.8 Reading libORBitCosNaming-2.so.0.1.0 Reading libpopt.so.0.0.0 Reading libthread.so.1 Reading libresolv.so.2 Reading libaio.so.1 Reading libbz2.so.1.0.3 (xfce4-panel:2461): Gdk-CRITICAL **: file gdkscreen-x11.c: line 216: assertion `GDK_IS_SCREEN (screen)' failed t@1 (l@1) signal SEGV (no mapping at the fault address) in gdk_window_foreign_new_for_display at 0xfee5dde4 0xfee5dde4: gdk_window_foreign_new_for_display+0x019c: ld [%o0 + 40], %o0 (dbx) gdb on (dbx) bt current thread: t@1 =>[1] gdk_window_foreign_new_for_display(0x50098, 0x2070000d, 0x22de80, 0x252ca0, 0xfee9a52c, 0x0), at 0xfee5dde4 [2] 0xff0ee78c(0xb3818, 0x2070000d, 0x0, 0x0, 0x1b8e48, 0xfee586cc), at 0xff0ee78c [3] 0xff1ecee8(0xffbfebb0, 0xff1ecd9c, 0xb3818, 0x134, 0x2, 0x1c), at 0xff1ecee8 [4] 0xfee48130(0xff1ece00, 0x185cb8, 0x0, 0x582a8, 0xfe874df4, 0x0), at 0xfee48130 [5] 0xfee48ff4(0x50098, 0x185cb8, 0xffbfebb0, 0x0, 0x2070000d, 0x22dd78), at 0xfee48ff4 [6] 0xfee4a754(0x50098, 0xfee9a54c, 0x630b4, 0x8, 0x0, 0x44680), at 0xfee4a754 [7] 0xfee4a93c(0x574b8, 0x1488, 0x4c280, 0x50098, 0x1400, 0xfee96b80), at 0xfee4a93c [8] 0xfe73b508(0x58198, 0x23, 0xfee4a8f4, 0x0, 0xfe7ba3a4, 0xfe7bd5f0), at 0xfe73b508 [9] g_main_context_dispatch(0x58198, 0x15bc, 0xfe7bd5f0, 0x6e, 0x1400, 0xfe7bd5ec), at 0xfe73cbd0 [10] 0xfe73d0dc(0x58198, 0x1, 0x1, 0x581a0, 0x24a868, 0x3), at 0xfe73d0dc [11] g_main_loop_run(0x2524c8, 0x0, 0x6b010, 0x1, 0xfe7ba3a4, 0xfe7ba3a4), at 0xfe73d9a4 [12] gtk_main(0x0, 0x0, 0x2524c8, 0x226cc0, 0xff2c0854, 0x5cd8), at 0xff070e9c [13] panel_app_run(0x18c00, 0x37400, 0x18c00, 0x2, 0x376e0, 0x19400), at 0x196f0 [14] main(0x1, 0xffbfefb4, 0xffbfefbc, 0x24400, 0x24400, 0x24400), at 0x187e8 (dbx)
Hmm, that looks a bit like a gtk bug to me. There is no code in the panel that directly calls gdk_window_foreign_new(). Too bad the backtrace doesn't show where the call originates. It could be that we are passing incorrect data to gtk, but that's going to be hard to find. My guess is that it has something to do with gtkplug/gtksocket internals, and maybe we are passing incorrect window id's or something like that.
Once the devel panel moves to master, I'm going to close this. The new panel handles modules that are no found in a better way and the whole plugin system has been overhauled too, so does not really apply anymore.
Devel branch has been merged in master. A 4.7.0 release will follow soon. If you think this bug is not fixed? Feel free to reopen the bug.