Gerald, Sent from my iPad
On 7 apr. 2014, at 20:26, Gerald Pfeifer
wrote: [88116.886900] gnome-shell[1548]: segfault at d445000 ip 00007fa416282eb6 sp 00007fff06649fc8 error 4 in libc-2.18.so[7fa41615a000+1a5000] [88144.679178] e1000e 0000:00:19.0: irq 46 for MSI/MSI-X [88144.779906] e1000e 0000:00:19.0: irq 46 for MSI/MSI-X [88144.780145] IPv6: ADDRCONF(NETDEV_UP): enp0s25: link is not ready [88144.782651] iwlwifi 0000:03:00.0: L1 Enabled; Disabling L0S [88144.789305] iwlwifi 0000:03:00.0: Radio type=0x1-0x2-0x0 [88144.872905] IPv6: ADDRCONF(NETDEV_UP): wlp3s0: link is not ready [88170.571392] gnome-shell[23540]: segfault at 6675000 ip 00007f2f3b713eb6 sp 00007fffe8e24d68 error 4 in libc-2.18.so[7f2f3b5eb000+1a5000] [88253.631370] gnome-shell[24105]: segfault at 6a5e000 ip 00007fda95f25eb6 sp 00007fff8c9a17f8 error 4 in libc-2.18.so[7fda95dfd000+1a5000]
Is GNOME Shell really a monolithic mega process that allows one aspect of it to tear down the entire desktop environment when GNOME 2 would handle a pkill gnome-shell very satisfactorily? The primary question is this, though: How can I provide input for someone to have a reasonable chance of fixing
Seeing the segfault in gnome-shell/libc, i think the best chance is to configure the system to create coredumps of crashes (i generally configure my factory ststem to write any dump to /cores) and once this happens, you can create backtraces based on the dump. Allows you to analyze an error after the crash actually happened, as opposed to running gs constantly under gdb, hoping to ever hit it. If info is required for how to set this up, please let know... I have this documented somewhere, but it would do for a good blog post :) Dominique-- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-gnome+owner@opensuse.org