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!

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 :(

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.

@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.

(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.

Which packages ? Gnome-Shell ? mutter ? Clutter ? gvfs ?

I will do my best, but as I said before, it happens randomly !

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.

Re: packages: debug info for glib(2) and gtk(3) also welcome...

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.

They will be needed, very likely. Install your distro's debugging symbols before setting up gdb, you'll save time (yours and ours).

(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

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)

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.

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.

(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. :-(

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.

(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.

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

Thanks ionut. But the problem is : I don't know WHAT and HOW TO make it crash :(

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 ?

Created attachment 197188 [details]
gdb log of crash.

Hope this gdb log could be helpful !

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!

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.

(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!

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 :(

(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.

(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...

(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?

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.

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 ?!

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.

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 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 ...

[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 ?!

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.

(In reply to comment #34)
> Maybe --enable-introspection is /wrong/ here ?!

No, gnome-shell actually requires Clutter with introspection.

*** Bug 662950 has been marked as a duplicate of this bug. ***

(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?

You can close it. It is long dead for me.

Cool.