Closed Bug 371387 Opened 17 years ago Closed 8 years ago

Segmentation faults on mail/link DnD, file-open "browse", save-as

Categories

(Core :: Widget: Gtk, defect)

Product:
Core
Component:
Widget: Gtk
Version:
1.8 Branch
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED INCOMPLETE

People

(Reporter: sambesselink, Unassigned)

Details

(Keywords: crash) 

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.9) Gecko/20070130 SeaMonkey/1.0.7
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.9) Gecko/20070130 SeaMonkey/1.0.7

When I'm surfing I sometimes get segmentation faults. They happen at moments where save-as dialog boxes and file-open dialog boxes ("browse local folder" for uploading) should be displayed. Also I sometimes get segmentation faults with drag n drop of mails in mail&newsgroups or (anchor) links in the navigator.

When I at a certain moment during a session for the first time of that session try to perform any of the above mentioned actions _and no segfault occurs_ I am not able to reproduce the segfault. There doesn't seem to be any other indication of a segfault occuring when I undertake one of the mentioned actions. One crashed session doesn't seem to influence the next.

Reproducible: Sometimes

Steps to Reproduce:
1. Open seamonkey
2. Try to save-as, upload, drag and drop mail or links.
3. Observe... and retry.
Actual Results:  
$ seamonkey 
No running windows found

(Gecko:17883): Gtk-WARNING **: Unable to locate theme engine in module_path: "clearlooks",

(Gecko:17883): Gdk-CRITICAL **: gdk_colormap_get_screen: assertion `GDK_IS_COLORMAP (cmap)' failed

(Gecko:17883): GLib-GObject-CRITICAL **: g_object_ref: assertion `G_IS_OBJECT (object)' failed

(Gecko:17883): Gdk-CRITICAL **: gdk_colormap_get_visual: assertion `GDK_IS_COLORMAP (colormap)' failed
/usr/libexec/mozilla-launcher: line 117: 17883 Segmentation fault      "$mozbin" "$@"
seamonkey-bin exited with non-zero status (139)

Expected Results:  
Depends on action taken:
- file-browser should open
- mousecursor should change indicating activated state of drag n drop

I do not have other crashes in programs and I can compile without a problem, so it doesn't seem to be a hardware problem. I have reinstalled my complete system from sources and the bug still occurs.

I am using Gentoo, but I am not aware of enabled 'ricer' options.. not completely sure though, so I'll include the following information:

Portage 2.1.1-r2 (default-linux/x86/2006.1/desktop, gcc-3.4.6, glibc-2.5-r0, 2.6.18-gentoo-r6 i686) on a mobile AMD Athlon(tm) XP-M 2500+
CBUILD="i686-pc-linux-gnu"
CFLAGS="-march=athlon-xp -O3 -pipe"
CXXFLAGS="-march=athlon-xp -O3 -pipe -fvisibility-inlines-hidden"
LDFLAGS="-Wl,-O1"
MAKEOPTS="-j2"
Summary: Segmentation faults on mail/link DnD, file-open "browse" (upload), save-as → Segmentation faults on mail/link DnD, file-open "browse", save-as
> (Gecko:17883): Gtk-WARNING **: Unable to locate theme engine in module_path:
> "clearlooks",

Sounds like gtk can't find your theme.  Do you see these messages when it doesn't crash?
Keywords: crash
Version: unspecified → 1.8 Branch
Yes. The message has nothing to do with the bug. I also get it when starting gimp:

(gimp-2.2:12025): Gtk-WARNING **: Unable to locate theme engine in module_path: "clearlooks",
OK, can you try out either an official 1.0.x build or a current trunk build?  Trunk comes with a crash reporting utility that can provide us with a stacktrace.

http://ftp.mozilla.org/pub/mozilla.org/seamonkey/releases/1.0.7/
http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/latest-trunk/
The official 1.0.7 also crashes, I'll try the nightly and see what happens.

$ seamonkey-bin --version
SeaMonkey 1.0.7, Copyright (c) 2003-2006 mozilla.org, build 2006121112

$ seamonkey-bin 
No running windows found

(Gecko:14027): Gtk-WARNING **: Unable to locate theme engine in module_path: "clearlooks",

(Gecko:14027): Gdk-CRITICAL **: gdk_colormap_get_screen: assertion `GDK_IS_COLORMAP (cmap)' failed

(Gecko:14027): GLib-GObject-CRITICAL **: g_object_ref: assertion `G_IS_OBJECT (object)' failed

(Gecko:14027): Gdk-CRITICAL **: gdk_colormap_get_visual: assertion `GDK_IS_COLORMAP (colormap)' failed
/usr/libexec/mozilla-launcher: line 117: 14027 Segmentation fault      "$mozbin" "$@"
seamonkey-bin exited with non-zero status (139)
I couldn't get the nightly to work at all. But I didn't try very hard at it either, as I don't have a lot of time at the moment. However, I am now using Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.2) Gecko/20070301 SeaMonkey/1.1.1 and can still produce this very, very annoying bug!

Nobody any idea on what direction I might have to look myself?
> $ seamonkey-bin 

Ah, well, you should run "seamonkey" and not "seamonkey-bin", but I don't think that's the problem.

What version of gtk do you have?

You could grab the source and build that so you'd have symbols.

Did SeaMonkey ever work?  Does a gtk2 of Mozilla 1.7.x work?
http://releases.mozilla.org/pub/mozilla.org/mozilla/releases/mozilla1.7.12/contrib/mozilla-i686-pc-linux-gnu-1.7.12-gtk2+xft.tar.gz
Assignee: general → nobody
Component: General → Widget: Gtk
Product: Mozilla Application Suite → Core
QA Contact: general → gtk
(In reply to comment #6)
> > $ seamonkey-bin 
> 
> Ah, well, you should run "seamonkey" and not "seamonkey-bin", but I don't think
> that's the problem.
> 
> What version of gtk do you have?
> 
> You could grab the source and build that so you'd have symbols.
> 
> Did SeaMonkey ever work?  Does a gtk2 of Mozilla 1.7.x work?
> http://releases.mozilla.org/pub/mozilla.org/mozilla/releases/mozilla1.7.12/contrib/mozilla-i686-pc-linux-gnu-1.7.12-gtk2+xft.tar.gz
> 

Yes, I have used Seamonkey since 1.0 and it worked. It started to fail from 1.0.7

Same problem in:
http://bugs.gentoo.org/show_bug.cgi?id=162780
(In reply to comment #6)
> > $ seamonkey-bin 
> 
> Ah, well, you should run "seamonkey" and not "seamonkey-bin", but I don't think
> that's the problem.

I was trying to test the official build, I was asked to test, but it didn't help, so it indeed wasn't the problem.


> What version of gtk do you have?

GTK+ 2.10.6


> You could grab the source and build that so you'd have symbols.

It's already built from source, but I'll try 2.10.9


> Did SeaMonkey ever work?  Does a gtk2 of Mozilla 1.7.x work?

Yep, a long time ago. It actually is gtk2...

Marking as duplicate of pacho's bug.
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → DUPLICATE
Woops, Pacho's bug was on Gentoo. I wasn't paying close attention.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Same symptoms with an install (from sources) of GTK+ 2.10.9. I hadn't recompiled seamonkey, so I'm doing that atm.

It might not matter, but for the sake of it, I checked Firefox (2.0.0.1) and it shows the same symptoms.
Rebuilt seamonkey with gtk+ 2.10.9, same symptoms....
FYI, this happens in Komodo as well, based on the 1.8.1 branch dated on the FX 2.0 release.  

http://bugs.activestate.com/show_bug.cgi?id=64037

There are two other bugs that I think are the same:

https://bugzilla.mozilla.org/show_bug.cgi?id=371908
https://bugzilla.mozilla.org/show_bug.cgi?id=248388

The problem persists :-(
We've attached a stack dump from Komodo in our bug (see Comment #12) which very closely matches the traceback in https://bugzilla.mozilla.org/show_bug.cgi?id=359870

My browser wasn't run from a terminal when it happened, so I can't say for certain, but I wonder if this crash was caused by the same problem:

http://talkback-public.mozilla.org/search/start.jsp?search=2&type=iid&id=TB30467328Y

So, in our bug (comment #12) there is a patch that prevents the crash from happening.  No apparent side effects.  However, it doesn't seem like a good way to fix the problem.  It would be nice if someone on the moz side with good knowledge of the moz gtk layer could comment on this.
(Gecko:17883): Gdk-CRITICAL **: gdk_colormap_get_screen: assertion
`GDK_IS_COLORMAP (cmap)' failed

This sounds really bad. Can you get a stack trace or otherwise debug this message?
Those criticals are indicative of bug 359870 .
The talkback in bug 359870 is similar to our tracebacks.

The full traceback is at https://bugzilla.mozilla.org/show_bug.cgi?id=359870

But below is the part that is most interesting (note the below is based on MOZILLA_1_8_BRANCH from the release date of fx 2.0).  

   	Repro scenario:

1) Start komodo
2) Open a file in Komodo (or have one open from previous session)
3) Close the file
4) Go to open a new file through File Open Dialog (Ctrl-O).
5) GDK_IS_COLORMAP tracebacks appear as file open dialog is instantiated.
6) Soon after Komodo will crash (not immediately, but usually upon some widget creation or resetting it crashes).


GDB traceback from Komodo:

[New Thread -1382495328 (LWP 19965)]
[New Thread -1395033184 (LWP 19966)]

(Gecko:19819): Gdk-CRITICAL **: gdk_colormap_get_screen: assertion `GDK_IS_COLORMAP (cmap)' failed

(Gecko:19819): GLib-GObject-CRITICAL **: g_object_ref: assertion `G_IS_OBJECT (object)' failed

(Gecko:19819): Gdk-CRITICAL **: gdk_colormap_get_visual: assertion `GDK_IS_COLORMAP (colormap)' failed

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1220438352 (LWP 19819)]
0xb7c6fc24 in gtk_style_ref () from /usr/lib/libgtk-x11-2.0.so.0
(gdb) where
#0 0xb7c6fc24 in gtk_style_ref () from /usr/lib/libgtk-x11-2.0.so.0
#1 0xb7c731f0 in gtk_style_attach () from /usr/lib/libgtk-x11-2.0.so.0
#2 0xb7d19fe2 in gtk_widget_set_usize () from /usr/lib/libgtk-x11-2.0.so.0
#3 0xb7d1a13a in gtk_widget_set_usize () from /usr/lib/libgtk-x11-2.0.so.0
#4 0xb6685818 in moz_container_forall ()
   from /home/toddw/main/Apps/Mozilla-devel/build/cvs1.8-ko4.11/mozilla/kodevel-rel-ns-shared-tools_07Mar2007/dist/bin/components/libwidget_gtk2.so
#5 0xb7b6b5fb in gtk_container_forall () from /usr/lib/libgtk-x11-2.0.so.0
#6 0xb7d1a129 in gtk_widget_set_usize () from /usr/lib/libgtk-x11-2.0.so.0
#7 0xb7b2c49f in gtk_button_box_set_child_size ()
   from /usr/lib/libgtk-x11-2.0.so.0
#8 0xb7b6b5fb in gtk_container_forall () from /usr/lib/libgtk-x11-2.0.so.0
#9 0xb7d1a129 in gtk_widget_set_usize () from /usr/lib/libgtk-x11-2.0.so.0
#10 0xb7d1a18d in gtk_widget_reset_rc_styles ()
   from /usr/lib/libgtk-x11-2.0.so.0
#11 0xb7c42e40 in gtk_rc_get_theme_dir () from /usr/lib/libgtk-x11-2.0.so.0
#12 0xb7bc9bb1 in gtk_icon_info_get_type () from /usr/lib/libgtk-x11-2.0.so.0
#13 0xb7799aa1 in g_source_is_destroyed () from /usr/lib/libglib-2.0.so.0
#14 0xb779b802 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#15 0xb779e7df in g_main_context_check () from /usr/lib/libglib-2.0.so.0
#16 0xb779eb89 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#17 0xb7b7cdfb in gtk_dialog_run () from /usr/lib/libgtk-x11-2.0.so.0
#18 0xb6697b2f in nsFilePicker::Show ()
   from /home/toddw/main/Apps/Mozilla-devel/build/cvs1.8-ko4.11/mozilla/kodevel-rel-ns-shared-tools_07Mar2007/dist/bin/components/libwidget_gtk2.so

I don't think it has anything to do directly with NPPVpluginKeepLibraryInMemory, as we do not use that in our plugin.  Our plugin is XEMBED based.  I do agree it could have something to do with plugins, our repro above (#2 open file, #3 close file) creates and destroy's an instance of our editor plugin.  One thing I do know, GC does not release the plugin for some period of time after removing the plugin from DOM, usually when we create a new plugin.  Our plugin is also never removed from memory because our main window contains a couple instances of it that cannot be closed.
and here's another potential hint about the cause...it seems (only seems because we cannot force the crash with this) we might be able to avoid the crash by setting the pref:

ui.allow_platform_file_picker=false

I got curious about this due to a comment by one of the other komodo devs, that the crash happened on showing any file dialog, which all are now pure gtk dialogs and not the old xul dialogs.  

The trace from comment 19 definitely points to bug 359870 . Note that that bug's summary was only recently changed to include NPPVpluginKeepLibraryInMemory since that appeared to be one of the causes of the plugin window not being destroyed correctly; but there seem to be other causes too.
Comment 21 is only partially correct. Opening the gtk filepicker for the first time causes a style reset in gtk which triggers the this bug; disabling the native filepicker will work around that but you'll still get the crash when the something else triggers a style reset, e.g. installing/uninstalling a theme engine or installing/uninstalling some icons which rebuild the gtk icon cache.
I was also experiencing random firefox (2.0.0.14) crashes when I do "Save Link As..." on a link to a file. I set ui.allow_platform_file_picker=false and the crashes have disappeared.

I'm using gnome 2.16.0 on RHEL 5, update 1.
Do you still see the problem when using newer versions?
Flags: needinfo?(uokrent)
Flags: needinfo?(sambesselink)
Flags: needinfo?(pachoramos1)
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago → 8 years ago
Flags: needinfo?(uokrent)
Flags: needinfo?(sambesselink)
Flags: needinfo?(pachoramos1)
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.