see: https://bugzilla.redhat.com/show_bug.cgi?id=891113 https://bugzilla.redhat.com/show_bug.cgi?id=865539 there's backtraces there, also: Additional info: backtrace_rating: 4 cmdline: xfce4-session crash_function: magazine_chain_pop_head executable: /usr/bin/xfce4-session kernel: 3.7.1-1.fc19.x86_64 remote_result: NOTFOUND uid: 1000 Truncated backtrace: Thread no. 1 (9 frames) #0 magazine_chain_pop_head at gslice.c:532 #1 thread_memory_magazine1_alloc at gslice.c:835 #2 g_slice_alloc at gslice.c:994 #3 g_array_sized_new at garray.c:198 #4 g_array_new at garray.c:170 #5 _dbus_gtypes_from_arg_signature at dbus-gsignature.c:200 #6 dbus_g_proxy_emit_remote_signal at dbus-gproxy.c:1777 #7 dbus_g_proxy_manager_filter at dbus-gproxy.c:1355 #15 gtk_main at gtkmain.c:1257 The crashes seem somewhat random unfortunately. ;(
Sadly this seems to be increasing in frequency. ;( [ 62.155631] xfce4-session[1383]: segfault at ffffffff00000000 ip 00007fc6b041d1af sp 00007fff82a7d2d0 error 4 in libglib-2.0.so.0.3503.0[7fc6b03ba000+121000] [ 142.221402] xfce4-session[2975]: segfault at ffffffff00000000 ip 00007fbb1a79a1af sp 00007fff9e20d060 error 4 in libglib-2.0.so.0.3503.0[7fbb1a737000+121000] [ 364.454128] xfce4-session[4539]: segfault at ffffffff00000000 ip 00007f5533dee1af sp 00007fff56abfaa0 error 4 in libglib-2.0.so.0.3503.0[7f5533d8b000+121000] [ 449.070814] xfce4-session[6348]: segfault at ffffffff00000000 ip 00007ff0be2321af sp 00007ffffc97c840 error 4 in libglib-2.0.so.0.3503.0[7ff0be1cf000+121000] [14129.127767] xfce4-session[8108]: segfault at ffffffff00000000 ip 00007fc8b3bf11af sp 00007fff9e045610 error 4 in libglib-2.0.so.0.3503.0[7fc8b3b8e000+121000] [36287.178871] xfce4-session[24893]: segfault at ffffffff00000000 ip 00007f5f41da91af sp 00007fffef96daf0 error 4 in libglib-2.0.so.0.3503.0[7f5f41d46000+121000] [36530.389847] xfce4-session[20474]: segfault at ffffffff00000000 ip 00007f85d64321af sp 00007fffb58b4e60 error 4 in libglib-2.0.so.0.3503.0[7f85d63cf000+121000] [36619.040731] xfce4-session[22293]: segfault at ffffffff00000000 ip 00007f942e4aa1af sp 00007fffe0b49a00 error 4 in libglib-2.0.so.0.3503.0[7f942e447000+121000] [36679.058052] xfce4-session[23879]: segfault at ffffffff00000000 ip 00007eff2a46d82c sp 00007fff7e911230 error 4 in libglib-2.0.so.0.3503.0[7eff2a40b000+121000] [37364.920335] xfce4-session[25400]: segfault at ffffffff00000000 ip 00007fb0266531af sp 00007fff323d39b0 error 4 in libglib-2.0.so.0.3503.0[7fb0265f0000+121000] it's glib2-2.35.3 Happy to try any debugging or gathering more info.
Also, there's reports that 'G_SLICE=always-malloc G_DEBUG=gc-friendly' causes the crashes to go away. So, possibly this is related to g_slice allocation? Another possibly related backtrace/crash: #0 magazine_chain_pop_head at gslice.c:532 #1 thread_memory_magazine1_alloc at gslice.c:835 #2 g_slice_alloc at gslice.c:994 #3 g_tree_node_new at gtree.c:139 #4 g_tree_insert_internal at gtree.c:443 #5 g_tree_replace at gtree.c:421 #6 xfsm_properties_set_string at xfsm-properties.c:505 #7 xfsm_properties_set_from_smprop at xfsm-properties.c:656 #8 xfsm_client_merge_properties at xfsm-client.c:346 #9 sm_set_properties at sm-layer.c:374 https://bugzilla.redhat.com/show_bug.cgi?id=927379
Not 100% sure if this is related or not, but since upgrading to glib 2.36 i'm seeing xfce4-session crashes upon logout, and also pointing at g_slice_alloc() : (gdb) bt #0 0x00000a6e0753386f in g_slice_alloc () from /usr/local/lib/libglib-2.0.so.3600.0 #1 0x00000a6e0c0c83ca in simple_add_entry () from /usr/local/lib/libxfce4util.so.3.0 #2 0x00000a6e0c0c900e in _xfce_rc_simple_parse () from /usr/local/lib/libxfce4util.so.3.0 #3 0x00000a6e0c0c7738 in xfce_rc_simple_open () from /usr/local/lib/libxfce4util.so.3.0 #4 0x00000a6bfa11702a in xfsm_manager_store_session () from /usr/local/bin/xfce4-session #5 0x00000a6bfa118f67 in xfsm_manager_complete_saveyourself () from /usr/local/bin/xfce4-session
And it also seems G_SLICE=always-malloc G_DEBUG=gc-friendly mitigates this crash, session is properly saved in .cache/sessions.
Seems like this also happens on Alpine Linux, x86_64. I got a backtrace with debugging symbols: #0 magazine_chain_pop_head (magazine_chunks=magazine_chunks@entry=0xb1106203ae0) at gslice.c:532 #1 0x00006f3d2348e46f in thread_memory_magazine1_alloc (ix=<optimized out>, tmem=<optimized out>) at gslice.c:835 #2 g_slice_alloc (mem_size=mem_size@entry=48) at gslice.c:994 #3 0x00006f3d23768b7d in handler_new (after=0) at gsignal.c:575 #4 0x00006f3d2376beea in g_signal_connect_closure_by_id (instance=instance@entry=0xb11062504f0, signal_id=signal_id@entry=20, detail=detail@entry=0, closure=0xb110627f2e0, after=after@entry=0) at gsignal.c:2293 #5 0x00006f3d23be76ba in export_signals (object=0xb11062504f0, info_list=0xb110624e820) at dbus-gobject.c:2445 #6 dbus_g_connection_register_g_object (connection=0xb110622edf8, at_path=0xb110624a090 "/org/xfce/SessionClients/2df371776_0473_4ccf_9935_10cbdf179961", object=0xb11062504f0) at dbus-gobject.c:2824 #7 0x00000b11055bbc40 in xfsm_client_dbus_init (client=0xb11062504f0) at xfsm-client.c:446 #8 xfsm_client_set_initial_properties (client=client@entry=0xb11062504f0, properties=0xb110623fa40) at xfsm-client.c:254 #9 0x00000b11055c2dda in xfsm_manager_register_client (manager=0xb1106238000, client=client@entry=0xb11062504f0, previous_id=previous_id@entry=0x0) at xfsm-manager.c:914 #10 0x00000b11055ba798 in sm_register_client (sms_conn=<optimized out>, client_data=0xb11062504f0, previous_id=0x0) at sm-layer.c:213 #11 0x00006f3d26048895 in _SmsProcessMessage () from /usr/lib/libSM.so.6 #12 0x00006f3d25e3aa2c in IceProcessMessages () from /usr/lib/libICE.so.6 #13 0x00000b11055b963b in ice_process_messages (channel=<optimized out>, condition=<optimized out>, user_data=0xb1106275a80) at ice-layer.c:111 #14 0x00006f3d23475de8 in g_main_dispatch (context=0xb110622b990) at gmain.c:3054 #15 g_main_context_dispatch (context=context@entry=0xb110622b990) at gmain.c:3630 #16 0x00006f3d234760d3 in g_main_context_iterate (context=0xb110622b990, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3701 #17 0x00006f3d234765f4 in g_main_loop_run (loop=0xb110623c0a0) at gmain.c:3895 #18 0x00006f3d24d853b2 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0 #19 0x00000b11055b8eae in main (argc=1, argv=0x77b6789954d8) at main.c:308 Also, 'info locals' returns: chunk = 0xffffffff00000000
Slightly different backtrace when running with G_SLICE=debug-blocks: #0 magazine_chain_pop_head (magazine_chunks=magazine_chunks@entry=0x1debcaf5220) at gslice.c:532 #1 0x00006dfbe96a646f in thread_memory_magazine1_alloc (ix=<optimized out>, tmem=<optimized out>) at gslice.c:835 #2 g_slice_alloc (mem_size=mem_size@entry=40) at gslice.c:994 #3 0x00006dfbe96b37a2 in g_tree_node_new (key=key@entry=0x1debcb79b10, value=value@entry=0x1debcb79b70) at gtree.c:139 #4 0x00006dfbe96b3cf6 in g_tree_insert_internal (tree=0x1debcb06b20, key=0x1debcb79b10, value=0x1debcb79b70, replace=1) at gtree.c:488 #5 0x00006dfbe96b4357 in g_tree_replace (tree=<optimized out>, key=<optimized out>, value=<optimized out>) at gtree.c:421 #6 0x000001deb8c79e00 in xfsm_properties_set_string (properties=<optimized out>, property_name=<optimized out>, property_value=<optimized out>) at xfsm-properties.c:505 #7 0x000001deb8c7a517 in xfsm_properties_set_from_smprop (properties=properties@entry=0x1debcb06b50, sm_prop=sm_prop@entry=0x1debcb79880) at xfsm-properties.c:656 #8 0x000001deb8c71076 in xfsm_client_merge_properties (client=client@entry=0x1debcb4ecf0, props=props@entry=0x1debcb45ef0, num_props=num_props@entry=7) at xfsm-client.c:346 #9 0x000001deb8c6efde in sm_set_properties (sms_conn=<optimized out>, client_data=0x1debcb4ecf0, num_props=7, props=0x1debcb45ef0) at sm-layer.c:374 #10 0x00006dfbec261033 in _SmsProcessMessage () from /usr/lib/libSM.so.6 #11 0x00006dfbec052a2c in IceProcessMessages () from /usr/lib/libICE.so.6 #12 0x000001deb8c6e63b in ice_process_messages (channel=<optimized out>, condition=<optimized out>, user_data=0x1debcb292c0) at ice-layer.c:111 #13 0x00006dfbe968dde8 in g_main_dispatch (context=0x1debcb27850) at gmain.c:3054 #14 g_main_context_dispatch (context=context@entry=0x1debcb27850) at gmain.c:3630 #15 0x00006dfbe968e0d3 in g_main_context_iterate (context=0x1debcb27850, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3701 #16 0x00006dfbe968e5f4 in g_main_loop_run (loop=0x1debcb380d0) at gmain.c:3895 #17 0x00006dfbeaf9d3b2 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0 #18 0x000001deb8c6deae in main (argc=1, argv=0x70fa795642c8) at main.c:308
I managed to make it crash with G_SLICE=always-malloc. Here is the backtrace: #0 0x000068d1014418bc in raise () from /lib/libc.so.0.9.32 #1 0x000068d10143d3b7 in abort () from /lib/libc.so.0.9.32 #2 0x000068d10143cc0a in ?? () from /lib/libc.so.0.9.32 #3 0x000068d10143beb4 in malloc () from /lib/libc.so.0.9.32 #4 0x000068d104491d7d in IceAcceptConnection () from /usr/lib/libICE.so.6 #5 0x00000d5e766bb6ac in ice_connection_accept (channel=<optimized out>, condition=<optimized out>, watch_data=0xd5e793bdc30) at ice-layer.c:178 #6 0x000068d101ad7de8 in g_main_dispatch (context=0xd5e793b0760) at gmain.c:3054 #7 g_main_context_dispatch (context=context@entry=0xd5e793b0760) at gmain.c:3630 #8 0x000068d101ad80d3 in g_main_context_iterate (context=0xd5e793b0760, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3701 #9 0x000068d101ad85f4 in g_main_loop_run (loop=0xd5e793c7a20) at gmain.c:3895 #10 0x000068d1033e73b2 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0 #11 0x00000d5e766bafae in main (argc=1, argv=0x731fe27ab898) at main.c:308 No symbol table info available.
I don't know if it is related but I also noticed this warning: (xfce4-session.dbg:16977): GLib-WARNING **: GChildWatchSource: Exit status of a child process was requested but ECHILD was received by waitpid(). Most likely the process is ignoring SIGCHLD, or some other thread is invoking waitpid() with a nonpositive first argument; either behavior can break applications that use g_child_watch_add()/g_spawn_sync() either directly or indirectly. It puzzles me because I have verified that SIGCHLD is not ignored and I patched out the waitpid() in the kde compat. I also grepped the libs that they don't do any waitpid().
Another crash rooted in g_slice_alloc, this time during a regular session when launching a new app. #0 0x00001e1fdc05186f in g_slice_alloc () from /usr/local/lib/libglib-2.0.so.3600.0 #1 0x00001e1fdc05fdfe in g_tree_node_new () from /usr/local/lib/libglib-2.0.so.3600.0 #2 0x00001e1fdc05ff0d in g_tree_insert_internal () from /usr/local/lib/libglib-2.0.so.3600.0 #3 0x00001e1dc901a3bf in xfsm_properties_set_from_smprop () from /usr/local/bin/xfce4-session #4 0x00001e1dc90118f3 in xfsm_client_merge_properties () from /usr/local/bin/xfce4-session #5 0x00001e1dc9010107 in sm_init () from /usr/local/bin/xfce4-session #6 0x00001e1fcdf8c6c9 in _SmsProcessMessage () from /usr/X11R6/lib/libSM.so.8.0 #7 0x00001e1fdcd03fff in IceProcessMessages () from /usr/X11R6/lib/libICE.so.9.0 #8 0x00001e1dc900f131 in ice_cleanup () from /usr/local/bin/xfce4-session #9 0x00001e1fdc03595a in g_main_context_dispatch () from /usr/local/lib/libglib-2.0.so.3600.0 #10 0x00001e1fdc037708 in g_main_context_iterate () from /usr/local/lib/libglib-2.0.so.3600.0 #11 0x00001e1fdc03882b in g_main_loop_run () from /usr/local/lib/libglib-2.0.so.3600.0 #12 0x00001e1fdb4fb833 in gtk_main () from /usr/local/lib/libgtk-x11-2.0.so.2400.0
This has been reported several times against the Ubuntu 13.04 (Raring) distribution: https://bugs.launchpad.net/bugs/1104435 I don't think that you can release the 4.10 build until this crash is fixed.
I'm in agreement. It seems to be a show stopper.
(In reply to comment #10) > This has been reported several times against the Ubuntu 13.04 (Raring) > distribution: > https://bugs.launchpad.net/bugs/1104435 > > I don't think that you can release the 4.10 build until this crash is fixed. I am not convinced the bug is in xfce4-session. It could also be a bug in glib.
It could be in glibc, but I have a feeling it's somewhere in client code. It is possible it's in glibc, but improbable without further evidence. The reason I say this is because there would probably be a lot more people reporting the same or similar issues with glibc, perhaps regardless of their desktop environment.
(In reply to comment #13) > It could be in glibc, but I have a feeling it's somewhere in client code. It > is possible it's in glibc, but improbable without further evidence. The > reason I say this is because there would probably be a lot more people > reporting the same or similar issues with glibc, perhaps regardless of their > desktop environment. i think you meant _glib_ here. glibc is something else :) > I don't think that you can release the 4.10 build until this crash is fixed. 4.10 was released a year ago. If the issue is really in xfce4-session and a fix is a found, there will be a bugfix release of it. The problem was definitely caused by various os/distributions upgrading their glib version to 2.36, and the crashes are a consequence of this.
(In reply to comment #14) > i think you meant _glib_ here. glibc is something else :) > > > I don't think that you can release the 4.10 build until this crash is fixed. > > 4.10 was released a year ago. If the issue is really in xfce4-session and a > fix is a found, there will be a bugfix release of it. > > The problem was definitely caused by various os/distributions upgrading > their glib version to 2.36, and the crashes are a consequence of this. Hey Landry. Yes, I meant glib, not glibc. However, my point is still relevant because glib is just as ubiquitous which suggests to me that there might expect to be a lot more activity around the bug if that were the case as opposed to specific to just one desktop environment. Although, it could be that the bug is in glib, but the client's usage of the library is unique enough that only we are the ones seeing this behaviour. Who knows. We need more info.
Got another crash with a different traceback this time. xfce4-session was starting the apps of the session, with the debug log : [1366139916] -> Set string (UserID, landry) [1366139917] Client Id = 110af6c82f000136596667800000064170000, received SET PROPERTIES [Num props = 1] [1366139917] Name: RestartCommand [1366139917] Type: LISTofARRAY8 [1366139917] Value: [1366139917] /usr/local/lib/firefox-21.0/firefox, [1366139917] --sm-config-prefix, [1366139917] /firefox-PfYLAg/, [1366139917] --sm-client-id, [1366139917] 110af6c82f000136596667800000064170000, [1366139917] --screen, [1366139917] 0 [1366139917] [1366139917] [1366139917] -> Set strv (RestartCommand) [1366139918] ICE connection fd = 18, received NEW CLIENT [1366139918] ICE connection fd = 18, received REGISTER CLIENT [Previous Id = 110af6c82f000136353664600000290120000] #0 0x00000bb07648786f in g_slice_alloc () from /usr/local/lib/libglib-2.0.so.3600.0 (gdb) bt #0 0x00000bb07648786f in g_slice_alloc () from /usr/local/lib/libglib-2.0.so.3600.0 #1 0x00000bb06c93c3ca in simple_add_entry () from /usr/local/lib/libxfce4util.so.3.0 #2 0x00000bb06c93d00e in _xfce_rc_simple_parse () from /usr/local/lib/libxfce4util.so.3.0 #3 0x00000bb06c93bedc in _xfce_rc_config_new () from /usr/local/lib/libxfce4util.so.3.0 #4 0x00000bae61d1cfaf in xfsm_splash_screen_new () from /usr/local/bin/xfce4-session #5 0x00000bae61d1d588 in xfsm_splash_screen_new () from /usr/local/bin/xfce4-session #6 0x00000bae61d1da12 in xfsm_startup_session_continue () from /usr/local/bin/xfce4-session #7 0x00000bae61d1767e in xfsm_manager_register_client () from /usr/local/bin/xfce4-session #8 0x00000bae61d10963 in sm_init () from /usr/local/bin/xfce4-session #9 0x00000bb06374e05e in _SmsProcessMessage () from /usr/X11R6/lib/libSM.so.8.0 #10 0x00000bb06dbeafff in IceProcessMessages () from /usr/X11R6/lib/libICE.so.9.0 #11 0x00000bae61d0f131 in ice_cleanup () from /usr/local/bin/xfce4-session #12 0x00000bb07646b95a in g_main_context_dispatch () from /usr/local/lib/libglib-2.0.so.3600.0 #13 0x00000bb07646d708 in g_main_context_iterate () from /usr/local/lib/libglib-2.0.so.3600.0 #14 0x00000bb07646e82b in g_main_loop_run () from /usr/local/lib/libglib-2.0.so.3600.0 #15 0x00000bb0718f3833 in gtk_main () from /usr/local/lib/libgtk-x11-2.0.so.2400.0 #16 0x00000bae61d0f7b6 in main () from /usr/local/bin/xfce4-session of course, linked again to XfceRc->GSlice
The only way I can see g_slice_alloc possibly segfaulting is if its only parameter block_size was either 0 or the client requested more memory than was available. Otherwise the problem could well be in glib since if the call failed, one might expect it to have returned NULL, but then the crash would have happened in the caller when it dereferenced it and not within the g_slice_alloc function itself. I also don't think it is a threading issue because glib is allegedly thread safe.
I can confirm the errors seen here, since I upgraded glib to 2.36.1. I've never encountered those problems with 2.34.x or earlier versions. Crahes tend to occur when raising a window or launching e.g. Thunar or another glib/gtk app, even when restoring a (precompiled binary) Firefox window. xfce4-session segfaults then X crashes (the latter may be another problem at my side). --- GLib-WARNING **: GChildWatchSource: Exit status of a child process was requested but ECHILD was received by waitpid(). Most likely the process is ignoring SIGCHLD, or some other thread is invoking waitpid() with a nonpositive first argument; either behavior can break applications that use g_child_watch_add()/g_spawn_sync() either directly or indirectly. Plus other 'g_slice_set_config' errors, with "sys_page_size == 0 failed". ---
I can confirm this bug with the new glib2. Other Arch Linux are having similar problems: https://bugs.archlinux.org/task/34892 https://bbs.archlinux.org/viewtopic.php?pid=1264082 I'm seeing the following entry in "dmesg": xfce4-session[451]: segfault at ffffffff00000000 ip 00007f9802f24537 sp 00007fffb8eeba50 error 5 in libglib-2.0.so.0.3600.1[7f9802ec1000+fc000]
(In reply to comment #18) > I can confirm the errors seen here, since I upgraded glib to 2.36.1. I've > never encountered those problems with 2.34.x or earlier versions. ... > --- > GLib-WARNING **: GChildWatchSource: Exit status of a child process was > requested but ECHILD was received by waitpid(). Most likely the process is > ignoring SIGCHLD, or some other thread is invoking waitpid() with a > nonpositive first argument; either behavior can break applications that use > g_child_watch_add()/g_spawn_sync() either directly or indirectly. I have a feeling that whatever causes this warning causes a memory corruption or a double free. I could not find any reason to *why* this warning shows up so I think something fishy here is going on. I have the following suggestions to move forward on this: 1) fix the above ECHILD warning and see if problem still happens. 2) git bisect glib and find the exact glib commit that introduces this error. A wild guess would be: https://git.gnome.org/browse/glib/commit/glib/?id=ce0022933c255313e010b27f977f4ae02aad1e7e (which seems to be partially reverted recently)
It would be nice is someone could test if this patch (to glib) solves this issue: https://git.gnome.org/browse/glib/commit/glib/gspawn.c?id=eb860fd898a6a2bd86c11d245294cd0e8cd4304b
Hi, Applied the patch and recompiles glib 2.36.1, but same problems occur in Xfce (maybe a little less frequent) : GChildWatchSource errors all the same and "random" crashes/segfaults when launching Thunar or other gtk windows/apps. Thanks!
Pushed 2 fixes to master for this. Please give it a shot.
I updated glib to 2.36.1 + I disabled SANE_MALLOC_PROTOS (see https://bugzilla.gnome.org/show_bug.cgi?id=698716), and the crashes seem to have disappeared for me (one day of using now). I also have a coredump of one of the previous crashes. If you're interested, I could post the binaries with symbols inside and the core somewhere so you can inspect yourselves. I looked at the disassembly just before the crash: it's somewhere inside g_slice_alloc (it's -O2 so the calls above probably got inlined) and there is a series of pointer dereferences (some a bit ofsetted) with 0-tests, so essentially walking some 0-ended linked list, until it gets into a place where there's 0xffffffff00000000 and at dereferencing this it SIGSEGVs.
Hi, I could not reproduce this bug with xfce4-session patched with the 2 fixes (async spawn + double-free bug), no lmatter how hard I try. No more gchildwatchsource errors. glib is still patched with #21. Seems fixed. Should I try once again with an unpatched stable 2.36.1 glib? Thanks again
I forgot to add that the non-crashing version described above still produces one GChildWatchSource warning at the start (unpatched released xfce4-session-4.10).
Given that lots of coredumps are showing 0xffffffff00000000 errors, would be nice to know if the crashes happen only on x86_64/amd64 or if they've also been experienced on 32-bits archs.
(In reply to comment #27) > Given that lots of coredumps are showing 0xffffffff00000000 errors, would be > nice to know if the crashes happen only on x86_64/amd64 or if they've also > been experienced on 32-bits archs. It looks like the bug reported against Ubuntu is limited to x86_64/amd64. I checked the bug that is linked to this one (1104435) and all of its duplicates.
(In reply to comment #23) > Pushed 2 fixes to master for this. Please give it a shot. This one alone fixes it: http://git.xfce.org/xfce/xfce4-session/commit/?id=ab391138cacc62ab184a338e237c4430356b41f9 The other might have impact on startup time if you have many apps. I don't know how much difference in time it is vfork vs fork, if any at all. I suppose it should be tested. vfork *migh* be noticeable faster (even if g_spawn_async is cleaner).
Please let me know when it's available in a PPA, and I will install it and test it.
I doubt its any slower certainly not with the *normal* amount of applications started with this (say < 20), and using the spawn function from glib makes it more future proof.
I hope there is a new release of xfce4-session soon which has the patch shared here as I'm also suffering the same issue. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=706425 Looking forward to a new release.
If some more people can test the patches and can confirm the issue is fixed (the segfaults, probably not the new warnings) i can make a new release.
(In reply to comment #33) > If some more people can test the patches and can confirm the issue is fixed > (the segfaults, probably not the new warnings) i can make a new release. No crashes for me after applying the patches to xfce4-session and glib.
No crashes anymore here after applying the patches to xfce4-sessions AND glib 2.36.1 but I still have logout problems/freezes, though maybe not directly linked to this bug.
I've had no further crashes here since applying the 2 patches. I also pushed them out to Fedora rawhide / 19alpha folks... so far no reports either way from them however. ;(
*** Bug 10068 has been marked as a duplicate of this bug. ***
This error occurs since I upgraded glib to 2.36 (debian package 2.36.1-2) with xfce4-session 4.8 (debian package: 4.8.3-3). No crashes for me after applying the patch (http://git.xfce.org/xfce/xfce4-session/commit/?id=ab391138cacc62ab184a338e237c4430356b41f9) to xfce4-session.
This error occurred for one of the user accounts on my laptop when I first opened Pidgin in it, and then tried to go to "Sessions and Startup" to remove it. Since then, xfce4-session would crash opening "Sessions and Startup" or when logging out. I am running Xubuntu 13.04, xfce4-session = 4.10.0-2ubuntu1, libglib2.0-0 = 2.36.0-1ubuntu2 I downloaded the xfce4-session-4.10.0 src tarball, applied the patch (http://git.xfce.org/xfce/xfce4-session/commit/?id=ab391138cacc62ab184a338e237c4430356b41f9), compiled and installed locally, and then symlinked the patched binaries into /usr/bin over the installed ones (moving the installed ones out of the way first). I'm not getting any more crashes now.
Was fixed in master and backported to 4.10 in http://git.xfce.org/xfce/xfce4-session/commit/?h=xfce-4.10&id=3ed422cb352b65 bc7c4ff6d68b1ed89bd278464f and released in 4.10.1, marking closed.