310137 - Crash when using typedown in GTK2 File Picker [@ libgtk-x11-2.0.so.0 + 0x1f3ae3]

Status: VERIFIED FIXED

(Core :: Widget: Gtk, defect, P1)

Description

[Scott Gifford]

I can consistently crash Mozilla Firefox when using typedown in the GTK2 File
Picker.  This is with Firefox branch build 20050925 on Fedora Core 2, GTK2
2.4.14-2, glib2 glib2-2.4.8-1, libc 2.3.3, kernel 2.6.10-1.12_FC2.

If I select File|Open, go to a directory, then type the first few letters of a
filename until typedown appears, and finally select the file by hitting ENTER,
the file will seem to open correctly, but FF will crash a few seconds later.

gdb shows this in the stack trace:
#0  0x00c44ae3 in gtk_tree_view_get_type () from /usr/lib/libgtk-x11-2.0.so.0
#1  0x0086eccc in g_main_context_wakeup () from /usr/lib/libglib-2.0.so.0
#2  0x0086c252 in g_main_depth () from /usr/lib/libglib-2.0.so.0
#3  0x0086d348 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#4  0x0086d680 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#5  0x0086dcc3 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#6  0x00b60923 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#7  0x081ec420 in XmlInitUnknownEncodingNS ()
#8  0x086301ba in nsXPTCVariant::Init ()
#9  0x0807a848 in ?? ()
#10 0x094df6e0 in ?? ()
#11 0x004ca620 in ?? ()
#12 0x00000000 in ?? ()

I've filed talkback reports with these IDs: TB9772790K TB9773245X TB9773353Z
TB9773376E TB9773399H

Here's the stack from one of these:

libgtk-x11-2.0.so.0 + 0x1f3ae3 (0x003adae3)
libglib-2.0.so.0 + 0x26ccc (0x0086eccc)
libglib-2.0.so.0 + 0x24252 (0x0086c252)
libglib-2.0.so.0 + 0x25348 (0x0086d348)
libglib-2.0.so.0 + 0x25680 (0x0086d680)
libglib-2.0.so.0 + 0x25cc3 (0x0086dcc3)
libgtk-x11-2.0.so.0 + 0x10f923 (0x002c9923)
nsAppShell::Run() 
[/builds/tinderbox/Fx-Mozilla1.8/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/widget/src/gtk2/nsAppShell.cpp,
line 141]
nsAppStartup::Run() 
[/builds/tinderbox/Fx-Mozilla1.8/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/toolkit/components/startup/src/nsAppStartup.cpp,
line 146]
XRE_main() 
[/builds/tinderbox/Fx-Mozilla1.8/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/toolkit/xre/nsAppRunner.cpp,
line 2311]
main() 
[/builds/tinderbox/Fx-Mozilla1.8/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/browser/app/nsBrowserApp.cpp,
line 62]
libc.so.6 + 0x14ad4 (0x00c22ad4)

Comment 1

[Adam Guthrie]

Filed a bug in GNOME's bugzilla for this, too.
http://bugzilla.gnome.org/show_bug.cgi?id=317385

Comment 2

[Bertram Franz]

Using seamonkey trunk (2005-10-24), I get the stacktrace:

#0  IA__g_type_check_instance (type_instance=0x1562f90e) at gtype.c:3223
#1  0x40577231 in IA__g_signal_handler_disconnect (instance=0x1562f90e, handler_id=4211578619) at gsignal.c:1776
#2  0x403b36df in gtk_tree_view_search_dialog_hide (search_dialog=0xf8030ef7, tree_view=0x92dfef8) at gtktreeview.c:12267
#3  0x403b3a70 in gtk_tree_view_search_entry_flush_timeout (tree_view=0x92dfef8) at gtktreeview.c:8859
#4  0x405b69d4 in g_timeout_dispatch (source=0x9a53290, callback=0x403b3a40 <gtk_tree_view_search_entry_flush_timeout>, user_data=0x92dfef8) at gmain.c:3306
#5  0x405b5fee in IA__g_main_context_dispatch (context=0x80919e8) at gmain.c:1947
#6  0x405b830b in g_main_context_iterate (context=0x80919e8, block=1, dispatch=1, self=0x81399e8) at gmain.c:2578
#7  0x405b91c8 in IA__g_main_loop_run (loop=0x83ee518) at gmain.c:2782
#8  0x402f56eb in IA__gtk_main () at gtkmain.c:963
#9  0x414c5b8e in nsAppShell::Run () from /home/bertram/mozilla.2005-10-24/objects/dist/bin/components/libwidget_gtk2.so
#10 0x41485be9 in nsAppStartup::Run () from /home/bertram/mozilla.2005-10-24/objects/dist/bin/components/libappcomps.so
#11 0x0804e8a0 in main1 ()
#12 0x0804f17f in main ()
#0  0xffffe410 in ?? ()

The crash seems to be the same, but the stack is quite different - is that the same bug?

I run SuSE9.2, gtk2-2.4.9-10.1, glib2-2.4.6-5, glibc-2.3.3-118, kernel-smp-2.6.8-24.17

Comment 3

[Adam Guthrie]

Scott, can you reproduce this in other GNOME apps., say gedit? Also, if you still crash, could you grab the gtk debugging packages (or recompile them with debug enabled) and get a more useful stacktrace? I can't reproduce this in gtk 2.8.6 (the filepicker widget is different, I think), so I'm willing to be this got fixed somewhere along the way.

Comment 4

[Scott Gifford]

Adam,

I don't see this bug in gedit, and I still see it in Mozilla.  I'm running Fedora Core 2, and I don't see a convenient way to install versions of GTK with debug symbols; do you know of a way to get better debug info without compiling GTK?

Comment 5

[Andrew Schultz]

if you install the debuginfo RPMs, gdb will pull in the symbols.  Fedora Core 2 debuginfo files are

ftp://download.fedora.redhat.com/pub/fedora/linux/core/2/i386/debug/
and/or
ftp://download.fedora.redhat.com/pub/fedora/linux/core/updates/2/i386/debug/

also, if you rebuild from an SRPM, you'll get debuginfo RPMs.

BTW, I see this on RHEL3 as well (which is FC3ish) but not FC4 at home.  Scott, have you filed a bug with Red Hat?  That's often more effective than going to Gnome, especially if Gnome has already fixed the bug (which seems probable).

Comment 6

[Andrew Schultz]

> Scott, have you filed a bug with Red Hat?

err, actually, FC2 is unsupported so no point in that.  :(

Valgind seems to give useful info here.  I'll post comments when I get it sorted out.

Comment 7

[Andrew Schultz]

Attachment: valgrind log

This is what valgrind sees.  I tried to get more callers, but without effect.

Comment 8

[Scott Gifford]

Thanks Andrew, I didn't know about the debuginfo RPMs!

Here's a backtrace with debug symbols.

#0  0x00908ae3 in gtk_tree_view_search_entry_flush_timeout (
    tree_view=0xa527548) at gtktreeview.c:8671
#1  0x0032cccc in g_timeout_dispatch (source=0xa092dc8,
    callback=0x908ad0 <gtk_tree_view_search_entry_flush_timeout>,
    user_data=0x529e719e) at gmain.c:3301
#2  0x0032a252 in g_main_dispatch (context=0x99329f8) at gmain.c:1942
#3  0x0032b348 in g_main_context_dispatch (context=0x99329f8) at gmain.c:2492
#4  0x0032b680 in g_main_context_iterate (context=0x99329f8, block=1,
    dispatch=1, self=0x99d1c60) at gmain.c:2573
#5  0x0032bcc3 in g_main_loop_run (loop=0x9c1f020) at gmain.c:2777
#6  0x00824923 in gtk_main () at gtkmain.c:1173
#7  0x081edfd0 in XmlInitUnknownEncodingNS ()
#8  0x08636308 in nsXPTCVariant::Init ()
#9  0x0807adb2 in ?? ()
#10 0x099f3db8 in ?? ()
#11 0x00e8bd7c in ?? () from ./libnspr4.so
#12 0x00000000 in ?? ()

Comment 9

[Andrew Schultz]

Backing out bug 301004 makes the crash go away.
This smells like a gtk bug, but the net effect is that a good chunk of the population will crash (if they use typedown)

Comment 10

[Christian Persch (GNOME) (away; not receiving bug mail)]

(In reply to comment #9)
> Backing out bug 301004 makes the crash go away.
> This smells like a gtk bug, but the net effect is that a good chunk of the
> population will crash (if they use typedown)

Looks like this might be http://bugzilla.gnome.org/show_bug.cgi?id=143829 , which is fixed since gtk+ 2.6.3.

Comment 11

[Ilya Voyager Schurov]

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

Comment 12

[Boris Zbarsky [:bzbarsky]]

Perhaps we should just bump our min version for this filepicker to 2.6.3 then?  Using the filepicker on FC3 is a little unfortunate due to this bug.  :(

Comment 13

[Boris Zbarsky [:bzbarsky]]

Note that bug 333653 is trying to add a pref for using the XUL filepicker instead; users may want to toggle that if they're on FC2 or FC3.

Comment 14

[Robert O'Callahan (:roc) (email my personal email if necessary)]

(In reply to comment #12)
> Perhaps we should just bump our min version for this filepicker to 2.6.3 then? 
> Using the filepicker on FC3 is a little unfortunate due to this bug.  :(

Sounds good to me.

Comment 15

[Boris Zbarsky [:bzbarsky]]

Mike, any objections to comment 12 on the Firefox end?

Comment 16

[Boris Zbarsky [:bzbarsky]]

Attachment: Just do it

Comment 17

[Boris Zbarsky [:bzbarsky]]

Fixed, trunk and 1.8.1 branch.

Comment 18

[Scott Gifford]

Any chance of a backport to the 1.8.0 branch?  It looks like 1.8.1 isn't going to be stable enough for daily use for a while longer, and the fix looks very simple and safe.  I would be extremely happy to stop living in fear of the filepicker!

Comment 19

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 218714 [details] [diff] [review]
Just do it

Could try, for sure.  ;)

Comment 20

[Daniel Veditz [:dveditz]]

Comment on attachment 218714 [details] [diff] [review]
Just do it

approved for 1.8.0 branch, a=dveditz for drivers

Comment 21

[Boris Zbarsky [:bzbarsky]]

Fixed on 1.8.0 branch.

Comment 22

[Andrew Schultz]

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

Comment 23

[Scott Gifford]

I see this fix in the copy of FF 1.5.0.4 I just installed.  Great work, and thanks!

Comment 24

[Christian Arnold]

(In reply to comment #23)
> I see this fix in the copy of FF 1.5.0.4 I just installed.  Great work, and
> thanks!
> 

I'm new to the Firefox Bugzilla, so sorry if this is not the right place to post...

However, with RHEL 4 using the Mozilla.com install of 1.5.0.4, the old standard Gnome file picker has been replaced with a very basic file picker on my machine.  This basic picker is missing the very useful "Favorites" feature from the standard Gnome file picker.

Any thoughts/advice (should this be a new bug)?

Thanks for your help, and keep up the great work!

Comment 25

[Adam Guthrie]

Christian, the patch in this bug made it so if you're using a version of GTK less than 2.6.3 Firefox will use the XUL filepicker instead of the native, GNOME one.

The reason this was done was because the native file picker was crashing a lot, and was pretty unusable.

And yes, if you feel this change was unwarranted, please do file a new bug and mark it blocking this one.

Comment 26

[Christian Arnold]

(In reply to comment #25)

Thanks for the explanation, Adam!

Sounds like the fix was a good idea, and I'll just have to look forward to my later version of GTK.