gtk_recent_files_menu_populate() does not properly guard against recursion

[William Pitcock]

Binary package hint: gnome-panel

The crash was a general protection fault according to dmesg:
  [ 1601.234701] gnome-panel[6302] general protection rip:2ad310d40d71 rsp:7fff9b7c5e90 error:0

ProblemType: Crash
Architecture: amd64
CrashCounter: 1
Date: Fri Jan 4 19:19:47 2008
DistroRelease: Ubuntu 8.04
ExecutablePath: /usr/bin/gnome-panel
NonfreeKernelModules: cdrom
Package: gnome-panel 1:2.20.1-0ubuntu2
PackageArchitecture: amd64
ProcCmdline: gnome-panel --sm-client-id default1
ProcCwd: /home/nenolod
ProcEnviron:
 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
 LANG=en_US.UTF-8
 SHELL=/bin/bash
Signal: 11
SourcePackage: gnome-panel
StacktraceTop:
 idle_populate_func (data=<value optimized out>)
 gdk_threads_dispatch (data=0x951560)
 g_main_context_dispatch ()
 ?? () from /usr/lib/libglib-2.0.so.0
 g_main_loop_run () from /usr/lib/libglib-2.0.so.0
Title: gnome-panel crashed with SIGSEGV in idle_populate_func()
Uname: Linux petrie 2.6.24-2-generic #1 SMP Thu Dec 20 17:58:55 GMT 2007 x86_64 GNU/Linux
UserGroups: adm admin audio cdrom dialout dip floppy lpadmin netdev plugdev powerdev scanner video

[William Pitcock (nenolod)]

This is a bug in gtk+2.0's new Recent Files feature. The function gtk_recent_files_menu_populate() does not guard properly against recursion. Debdiff which in theory corrects this will follow shortly.

[William Pitcock (nenolod)]

This should add an appropriate fix for the recursion problem. At least, with this fix, I haven't had gnome-panel crash while using programs which access lots of files.

[Emmet Hikory (persia)]

I can also replicate a crash in gnome-panel under similar circumstances, which crash is no longer present with the application of this patch.

[Daniel Holbach (dholbach)]

Sébastien: can you comment on this one?

[Sebastien Bacher (seb128)]

The crash is not a frequent one apparentl so I would prefer to wait for upstream or debian to commit a fix so we don't have to get ubuntu specific changes to gtk

[Emmet Hikory (persia)]

I'm not sure about "not a frequent one" as, for me, with the unpatched libgtk, gnome-panel crashes about once every three builds (and I tend to have between a dozen and a score builds daily, so that's often enough to be incredibly annoying). It appears to be related to larger amounts of RAM/cache, so that 1.5GB is insufficient to cause it, whereas 2GB+ is enough.

To replicate, use a machine with >= 2GB RAM, and run a set of builds with pbuilder or sbuild. It can trigger faster with parallel builds (as this thrashes the open file cache faster).

[Sebastien Bacher (seb128)]

The comment about the bug not being frequent is due to the 0 duplicates

[William Pitcock (nenolod)]

An amd64 retrace is not needed. I have already fixed the bug locally
(and Emmet is also running my patch) and sent a patch upstream. The main
issue is fixing it in Ubuntu at this point, as this bug is unacceptable
for Hardy.

I've also sent the patch to Debian, so committing it there and syncing
would also do. Just as long as Hardy *does* *not* *ship* *with* *this*
*bug*.

On Mon, 2008-01-07 at 10:42 +0000, Sebastien Bacher wrote:
> The crash is not a frequent one apparentl so I would prefer to wait for
> upstream or debian to commit a fix so we don't have to get ubuntu
> specific changes to gtk
>
> ** Tags added: need-amd64-retrace
>

[Sebastien Bacher (seb128)]

The bug will be fixed before hardy, no worries. The retracing was just to get debug informations before removing the coredump attached to the bug. No need to add that much emphasis to the comments words, the bug has not been ignored

[Sebastien Bacher (seb128)]

Setting the milestone to hardy, the patch will be applied in Ubuntu later if there is no new upstream tarball or debian update including the change

[William Pitcock (nenolod)]

There are actually several probable duplicates. I've gone ahead and
marked them based on backtrace.

On Mon, 2008-01-07 at 12:32 +0000, Sebastien Bacher wrote:
> The comment about the bug not being frequent is due to the 0 duplicates
>

[Sebastien Bacher (seb128)]

The bug has been fixed upstream now

[Marco Rodrigues (gothicx)]

Nice. I also have that problem.. just for records :)

[Emilio Pozuelo Monfort (pochu)]

This is fixed in trunk, but not in the 2.12 branch (at least not yet)

[William Pitcock (nenolod)]

Indeed, but since they accepted the patch this means two things:

  * it is possible that it will be available in the next gtk2.12
release,
  * it is probably good enough for us to patch our gtk in the meantime.
(we already do!)

On Mon, 2008-01-14 at 18:56 +0000, Emilio Pozuelo Monfort wrote:
> This is fixed in trunk, but not in the 2.12 branch (at least not yet)
>

[William Pitcock (nenolod)]

To clarify, "we already do!" means patch GTK, not apply this particular
patch to our GTK.

On Mon, 2008-01-14 at 19:16 +0000, William Pitcock wrote:
> Indeed, but since they accepted the patch this means two things:
>
> * it is possible that it will be available in the next gtk2.12
> release,
> * it is probably good enough for us to patch our gtk in the meantime.
> (we already do!)
>
> On Mon, 2008-01-14 at 18:56 +0000, Emilio Pozuelo Monfort wrote:
> > This is fixed in trunk, but not in the 2.12 branch (at least not yet)
> >
>

[Sebastien Bacher (seb128)]

the bug has been fixed in hardy now