abrt version: 1.1.17 architecture: x86_64 Attached file: backtrace, 68629 bytes cmdline: /usr/bin/gnome-shell component: gnome-shell Attached file: coredump, 211689472 bytes crash_function: gjs_object_from_g_object executable: /usr/bin/gnome-shell kernel: 2.6.38-0.rc8.git0.1.fc15.x86_64 package: gnome-shell-2.91.91-1.fc15 rating: 4 reason: Process /usr/bin/gnome-shell was killed by signal 11 (SIGSEGV) release: Fedora release 15 (Lovelock) time: 1299854386 uid: 500 How to reproduce ----- 1. Nothing special 2. 3.
Created attachment 483728 [details] File: backtrace
Package: gnome-shell-2.91.91-1.fc15 Architecture: x86_64 OS Release: Fedora release 15 (Lovelock) How to reproduce ----- 1. started session 2. issued gnome-shell --replace as it doesn't start by default 3. just working with some windows 4. gnome-shell crashed, providing no alternate window manager (lucky me, I had a console and I could compose "metacity" with cutting-pasting with mouse (as keyboard input doesn't focus) and could 'recover')
Package: gnome-shell-2.91.91-1.fc15 Architecture: x86_64 OS Release: Fedora release 15 (Lovelock) How to reproduce ----- 1. Install Fedora 15 Alpha 2. Update system to latest packages from 'updates-testing' 3. Login to gnome-shell desktop and use system as normal (terminals, pidgin, evolution, firefox) Comment ----- After about 7 hours of use, gnome-shell crashes. Unclear if any single action causes the crash.
Package: gnome-shell-2.91.91-1.fc15 Architecture: x86_64 OS Release: Fedora release 15 (Lovelock) How to reproduce ----- 1. I was opening several times NetworkManager and its context menus. 2. Moved by my mouse into the top left corner to activate the activities menu. 3.
Discussed at the 2011-04-15 blocker review meeting. As Shell auto-respawns on crashes, we don't consider any Shell crash to be an automatic blocker, as the impact of a Shell crash is not actually that terrible (you just get to watch it reload). An unrecoverable crash (crashing in a loop) would be more worrying. This one seems not to hit many people and not to happen often, so we don't consider it a blocker given present info. We also suspect it may be fixed as there hasn't been a report for a while. GNOME team, are you confident that this is fixed (do you know of a specific commit to fix this)? Reporters, have any of you seen this with recent packages? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
(In reply to comment #5) > GNOME team, are you confident that this > is fixed (do you know of a specific commit to fix this)? Reporters, have any of > you seen this with recent packages? This particular stack trace will actually happen for many different kinds of reference counting problems in other areas. Basically if native C code erroneously drops a refcount to 0 and frees an object, the JavaScript garbage collector is going to come along at a later point and bomb on it (it's a separate thread, this happens asynchronously). I think we've fixed most refcounting issues at this time.
hey, I understood about one word in three of that! so, let's close this for now, I guess.