After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 659676 - Gnome shell crashes
Gnome shell crashes
Status: RESOLVED OBSOLETE
Product: gnome-shell
Classification: Core
Component: general
3.1.x
Other Linux
: High critical
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
: 662950 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2011-09-21 09:22 UTC by Frederic Bezies
Modified: 2012-01-08 20:48 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
screen log (116.08 KB, application/octet-stream)
2011-09-21 14:17 UTC, Frederic Bezies
  Details
screen log (right mime type this time) (116.08 KB, text/plain)
2011-09-21 14:19 UTC, Frederic Bezies
  Details
gdb log of crash. (21.73 KB, text/plain)
2011-09-21 20:13 UTC, Frederic Bezies
  Details
st: Fix crash in theme-node-transition (1.23 KB, patch)
2011-09-21 20:45 UTC, Florian Müllner
committed Details | Review

Description Frederic Bezies 2011-09-21 09:22:07 UTC
I have "random" crashes related to gnome-shell-calendar-server

I do nothing special to make it happens.

Here is what I get in .xsession-error :

Avertissement du gestionnaire de fenêtres : CurrentTime used to choose focus window; focus window may not be correct.
Avertissement du gestionnaire de fenêtres : Got a request to focus the no_focus_window with a timestamp of 0.  This shouldn't happen!

(gnome-shell:31209): St-CRITICAL **: setup_framebuffers: assertion `width > 0' failed
** Message: applet now removed from the notification area
gnome-shell-calendar-server[31220]: Got HUP on stdin - exiting
gnome-session[1269]: WARNING: Application 'gnome-shell.desktop' killed by signal
      JS LOG: GNOME Shell started at Wed Sep 21 2011 11:12:02 GMT+0200 (CEST)
** Message: applet now embedded in the notification area

I'm using archlinux, and here are version of my gnome packages.

gnome-shell : 3.1.91.1
Evolution (if it is related in some way) : 3.1.92
Mutter : 3.1.91.1
Clutter : 1.8.0

Could it be related to google agenda sync in Evolution ?!
Comment 1 Rui Matos 2011-09-21 11:14:48 UTC
gnome-shell-calendar-server gets and HUP when gnome-shell crashes or otherwise terminates.

Without a stack trace from the crash it's very hard to determine what caused it.
Can you get us a stack trace? Please see http://live.gnome.org/GettingTraces for more information on how to do so. Thanks in advance!
Comment 2 Frederic Bezies 2011-09-21 11:30:55 UTC
The problem is I don't know HOW TO reproduce it. On next crash, I will paste the content of my .xsession-error. So it could help to find how to reproduce this bug. Sorry for not being able to send you a trace before :(
Comment 3 David Zeuthen (not reading bugmail) 2011-09-21 11:44:34 UTC
This does not appear to be related to the calendar server - please don't make guesses based on output and always include stack traces so it's easier to pinpoint the problem when triaging bugreports - thanks in advance!

Reassigning to the general component of the Shell.
Comment 4 Frederic Bezies 2011-09-21 11:48:19 UTC
@David : sorry for the wrong component.

As I said, it is kinda random, so I will try to do my best to build debug versions and wait for next crash to arrive and give traces.

Sorry again, but when it is random crashes, it is hard to give a lot of infos !

Have a good day.
Comment 5 Milan Bouchet-Valat 2011-09-21 12:49:03 UTC
(In reply to comment #2)
> The problem is I don't know HOW TO reproduce it. On next crash, I will paste
> the content of my .xsession-error. So it could help to find how to reproduce
> this bug. Sorry for not being able to send you a trace before :(
Be careful, .xsession-errors is not enough to get a backtrace. See http://live.gnome.org/GettingTraces, but you need to do this *before* the crash happens.
Comment 6 Frederic Bezies 2011-09-21 12:57:05 UTC
Which packages ? Gnome-Shell ? mutter ? Clutter ? gvfs ?

I will do my best, but as I said before, it happens randomly !
Comment 7 Milan Bouchet-Valat 2011-09-21 12:58:48 UTC
No need to know when it happens, just run gnome-shell constantly in gdb, and one day or another it will crash again. If you suspend or hibernate, you only need to set up the debugging once, and then wait.
Comment 8 André Klapper 2011-09-21 12:59:53 UTC
Re: packages: debug info for glib(2) and gtk(3) also welcome...
Comment 9 Frederic Bezies 2011-09-21 13:01:02 UTC
Will start with a debug version of Gnome-Shell. If glib and gtk are needed after a first stack trace, will build them too with debug symbol.
Comment 10 Milan Bouchet-Valat 2011-09-21 13:02:45 UTC
They will be needed, very likely. Install your distro's debugging symbols before setting up gdb, you'll save time (yours and ours).
Comment 11 Florian Müllner 2011-09-21 13:41:42 UTC
(In reply to comment #7)
> No need to know when it happens, just run gnome-shell constantly in gdb, and
> one day or another it will crash again.

While running in gdb is good advice to get a backtrace for a random crash, it's important to mention that running gnome-shell (or any other window manager) in gdb is trickier than doing so with normal applications, as the desktop will end up frozen after the crash.

Some gnome-shell specific debugging instructions are available on the wiki: https://live.gnome.org/GnomeShell/Debugging
Comment 12 Frederic Bezies 2011-09-21 14:17:57 UTC
Created attachment 197157 [details]
screen log

Log of screen until I run gdb and my main gnome shell display is busted (no more windows or top bar, only mouse cursor)
Comment 13 Frederic Bezies 2011-09-21 14:19:50 UTC
Created attachment 197158 [details]
screen log (right mime type this time)

Screen log until gdb is run. Gnome-Shell is not displaying windows after I run gdb-attach command.
Comment 14 Frederic Bezies 2011-09-21 18:21:35 UTC
Got a crash, but with new packages (gnome shell 3.1.92 was installed 2 hours ago).

Don't have a trace, but maybe a clue with these errors ?

** Message: applet now embedded in the notification area
Avertissement du gestionnaire de fenêtres : CurrentTime used to choose focus window; focus window may not be correct.
Avertissement du gestionnaire de fenêtres : Got a request to focus the no_focus_window with a timestamp of 0.  This shouldn't happen!

(gnome-shell:1629): St-CRITICAL **: setup_framebuffers: assertion `width > 0' failed
** Message: applet now removed from the notification area
gnome-shell-calendar-server[1639]: Got HUP on stdin - exiting
gnome-session[1294]: WARNING: Application 'gnome-shell.desktop' killed by signal
NOTE: child process received `Goodbye', closing down

Hope it helps.
Comment 15 Milan Bouchet-Valat 2011-09-21 18:23:57 UTC
(In reply to comment #14)
> Hope it helps.
Probably not much, they're the same as before, and most of them, if not all, are completely unrelated. :-(
Comment 16 Frederic Bezies 2011-09-21 18:34:40 UTC
Sorry I cannot help more here because :

1) I cannot get gdb to work with gnome-shell. When I run it, gnome shell is UNUSABLE. Only cursor is displayed, no more windows to interact.

2) I gave you all the datas and infos I can give you now.

So you can close this bug as invalid, or anything else, because I cannot be more helpful.

Sorry ! I will stand crashes hoping they won't happen too often.

And sorry for wasting your time with this bug report.

Have a good day.
Comment 17 Jasper St. Pierre (not reading bugmail) 2011-09-21 18:42:42 UTC
(In reply to comment #16)
> Sorry I cannot help more here because :
> 
> 1) I cannot get gdb to work with gnome-shell. When I run it, gnome shell is
> UNUSABLE. Only cursor is displayed, no more windows to interact.

This is the pitfall of trying to debug the window manager. Use ssh if you have more than one computer, and screen/tmux plus a VT if not.

https://live.gnome.org/GnomeShell/Debugging has instructions on how to retrieve backtraces.

Unfortunately, Arch doesn't provide debuginfo packages, meaning that you're going to have to build the packages manually for clutter, mutter, gnome-shell, etc.

> 2) I gave you all the datas and infos I can give you now.
> 
> So you can close this bug as invalid, or anything else, because I cannot be
> more helpful.
> 
> Sorry ! I will stand crashes hoping they won't happen too often.
> 
> And sorry for wasting your time with this bug report.
> 
> Have a good day.
Comment 18 Ionut Biru 2011-09-21 19:25:51 UTC
debug packages are available in: http://pkgbuild.com/~ioni/debug

to debug this switch to tty and do:

ps ax | grep gnome-shell and notice the pid

gdb -p PID

set logging on

continue

then switch back to gnome-shell and make it crash. after that switch back to tty on run bt full

then upload gdb.log created by gdb
Comment 19 Frederic Bezies 2011-09-21 19:48:34 UTC
Thanks ionut. But the problem is : I don't know WHAT and HOW TO make it crash :(
Comment 20 Frederic Bezies 2011-09-21 20:13:13 UTC
Well thanks Ionut, again. Don't know how I made it crash, but I got a trace.

I upload it right now :)

Crashing saying this :

Program received signal SIGSEGV, Segmentation fault.
0x00007fe604089504 in _cogl_pipeline_get_authority (pipeline=0x0, difference=4) at ./cogl-pipeline-private.h:881
881	./cogl-pipeline-private.h: Aucun fichier ou dossier de ce type.
	in ./cogl-pipeline-private.h

So, is cogl guilty there ?
Comment 21 Frederic Bezies 2011-09-21 20:13:51 UTC
Created attachment 197188 [details]
gdb log of crash.

Hope this gdb log could be helpful !
Comment 22 Florian Müllner 2011-09-21 20:45:31 UTC
Created attachment 197189 [details] [review]
st: Fix crash in theme-node-transition

Setting up the framebuffers for transitions may fail, in which case
the material used for drawing is left uninitialized, so trying to
access it results in a crash.
Instead bail out in this case, which means that we won't paint
anything during the transition - still, drawing errors are better
than crashes ...

(In reply to comment #20)
> So, is cogl guilty there ?

Nope, it's our fault.


(In reply to comment #21)
> Hope this gdb log could be helpful !

Indeed, thanks!
Comment 23 Frederic Bezies 2011-09-21 20:51:38 UTC
Well, you can also thanks Ionut who provides debug packages. But even if .xsession-error log wasn't very informative, it pointed framebuffer since the beginning : 

St-CRITICAL **: setup_framebuffers: assertion `width > 0'
failed

Well, it was hard to grab a trace, but at least, if this patch could make it into gnome-shell soon, I will be happy.

And sorry for the noise, I'm into a bad time.
Comment 24 Milan Bouchet-Valat 2011-09-21 20:59:29 UTC
(In reply to comment #23)
> Well, you can also thanks Ionut who provides debug packages. But even if
> .xsession-error log wasn't very informative, it pointed framebuffer since the
> beginning : 
> 
> St-CRITICAL **: setup_framebuffers: assertion `width > 0'
> failed
Yeah, but anyway it's very hard to debug a problem from a simple warning, without knowing where in the code the bug is. So a trace is almost always required.

> Well, it was hard to grab a trace, but at least, if this patch could make it
> into gnome-shell soon, I will be happy.
> 
> And sorry for the noise, I'm into a bad time.
No problem, thanks for the debugging!
Comment 25 Frederic Bezies 2011-09-23 13:58:53 UTC
I completely agree about trace, but I was very hard to get one here.

Any hope to get this patch integrated for Gnome Shell 3.2 ? Would be great, I had three crashes today in about 5 hours of use :(
Comment 26 Jasper St. Pierre (not reading bugmail) 2011-09-23 14:56:45 UTC
(In reply to comment #25)
> I completely agree about trace, but I was very hard to get one here.
> 
> Any hope to get this patch integrated for Gnome Shell 3.2 ? Would be great, I
> had three crashes today in about 5 hours of use :(

The patch fixes the crash, but not why we're creating a transition with 0 width. A gjs_dumpstack would be helpful.
Comment 27 André Klapper 2011-09-23 15:00:47 UTC
(In reply to comment #22)
> Created an attachment (id=197189) [details] [review]
> st: Fix crash in theme-node-transition

Florian: Planning to ask r-t for a hardcode freeze break? (Or did I miss it?)
Sounds like it would be worth it...
Comment 28 Florian Müllner 2011-09-23 15:16:48 UTC
(In reply to comment #27)
> Florian: Planning to ask r-t for a hardcode freeze break? (Or did I miss it?)
> Sounds like it would be worth it...

Does it make sense to ask for a freeze break before code review?


Frederic, are you by any chance using any gnome-shell theme?
Comment 29 Frederic Bezies 2011-09-23 15:41:26 UTC
I'm using default theme. My gnome shell is very closer to a new brand one.

@jasper : When I tried gjs_dumpstack () I got only one line in gdb, this one :

$1 = 25222112

Not really helpful I think.
Comment 30 Frederic Bezies 2011-09-24 19:06:21 UTC
Don't know if it helps, but a few minutes ago, got this crash only after changing my desktop wallpaper. Maybe it could help triggering the bug ?!
Comment 31 Frederic Bezies 2011-09-25 09:27:01 UTC
Added proposed patch, and try some things that led to this crash, and nothing happens.

Could it be added for 3.2 final, or is it too late ? Should I have to ask Ionut Biru to add it to archlinux version ?

Thanks for your answers.
Comment 32 Owen Taylor 2011-09-26 17:58:09 UTC
Review of attachment 197189 [details] [review]:

This patch looks right to me as far as it goes. Please don't close the bug when this is committed, however, since the code is still broken, since there is a critical warning being printed.

 - The code that assumes that st_theme_node_transition_get_paint_box() returns integer results that convert into floats needs to be fixed. Use floor/ceil to determine the surrounding integer box. This may mean that we're not painting at 0,0 on the fbo, but at 0.999,0.999 or something, so we need to account for that as well.
 - If we expect a 0,0 paint box to be legitimate in some cases (an empty actor, say), then we need to handle that via normal code paths rather than g_return_if_fail()
Comment 33 Florian Müllner 2011-09-26 20:42:05 UTC
Comment on attachment 197189 [details] [review]
st: Fix crash in theme-node-transition

Attachment 197189 [details] pushed as 8bd5b1e - st: Fix crash in theme-node-transition

Possibly an interesting data point: I've tried to trigger the bug artificially (by adding a return statement right after the assert), but while I get a lot of drawing artifacts during transitions, I cannot reproduce the crash.

What versions of cogl/clutter are you running? We are using the stable 1.8 branches for now, as the master branches are known to break a lot of stuff all over the place. Anyway, patch pushed for 3.2 ...
Comment 34 Frederic Bezies 2011-09-27 04:27:36 UTC
[fred@fredo-arch ~]$ pacman -Qi cogl | grep Version
Version               : 1.8.0-1

[fred@fredo-arch ~]$ pacman -Qi clutter | grep Version
Version               : 1.8.0-1

And about compilation option of both :

For cogl :

build() {
  cd "$srcdir/$pkgname-$pkgver"
  ./configure --prefix=/usr
  make
}

For clutter :

build() {
  cd "${srcdir}/${pkgname}-${pkgver}"
  ./configure --prefix=/usr --enable-introspection
  make
}

Maybe --enable-introspection is /wrong/ here ?!
Comment 35 Frederic Bezies 2011-09-27 04:28:42 UTC
And thanks for the patch. Since I added in my own version of gnome-shell, crashes are completely gone. Can't wait for gnome 3.2 now. Simply love it.
Comment 36 Florian Müllner 2011-09-27 11:50:50 UTC
(In reply to comment #34)
> Maybe --enable-introspection is /wrong/ here ?!

No, gnome-shell actually requires Clutter with introspection.
Comment 37 Jasper St. Pierre (not reading bugmail) 2011-10-28 17:30:18 UTC
*** Bug 662950 has been marked as a duplicate of this bug. ***
Comment 38 André Klapper 2012-01-08 20:16:59 UTC
(In reply to comment #35)
> And thanks for the patch. Since I added in my own version of gnome-shell,
> crashes are completely gone. Can't wait for gnome 3.2 now. Simply love it.

Frederic, is the issue reported here still a problem in 3.2 or could this be closed?
Comment 39 Frederic Bezies 2012-01-08 20:46:13 UTC
You can close it. It is long dead for me.
Comment 40 Milan Bouchet-Valat 2012-01-08 20:48:31 UTC
Cool.