Crash at every shutdown with completely blank stack trace

RESOLVED FIXED

Status

()

Core
Widget: Gtk
P3
critical
RESOLVED FIXED
9 years ago
9 years ago

People

(Reporter: dolphinling, Unassigned)

Tracking

({crash, regression})

Trunk
x86
Linux
crash, regression
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9.1 -
wanted1.9.1 +

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

9 years ago
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1a2pre) Gecko/20080824021213 Minefield/3.1a2pre ID:20080824021213

Every time I quit firefox, I get the crash reporter coming up. This happens in a completely new profile, and with a completely new installation.

The stack trace is completely blank. There is a correct time, build id, any comments I entered, and a few other things, but no stack trace at all.

Example trace: http://crash-stats.mozilla.com/report/index/cb9e24de-7217-11dd-8257-001cc45a2ce4?p=1

Other crashes do give a stack trace, so it's not a problem with submission.

This is a regression from between 2008-07-13-02 and 2008-07-14-02.
(Reporter)

Comment 1

9 years ago
http://hg.mozilla.org/mozilla-central/index.cgi/log/98d39d1a3246 regression range. (If there's a better way to do that with the hg changelog, sorry).

I don't see anything at all that looks suspicious.
You can enter dates for a regression range at http://hg.mozilla.org/mozilla-central/pushloghtml

Do you have either content or chrome jit enabled?
(Reporter)

Comment 3

9 years ago
Regression range: http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=July+13+2008+00%3A00%3A00&enddate=July+14+2008+03%3A00%3A00

There is nothing in there that jumps out at me, though a few things that look possible.

Neither content nor chrome jit is enabled (and the problem started before they were even available, even).
Hmm...  there are various gtk changes there....
(Reporter)

Comment 5

9 years ago
I am planning to work on bisecting this. So far, I have verified that it does crash on my own builds as well as the official builds. The crash reporter does not appear (do I need to configure that in?) but I get the following terminal output:

./run-mozilla.sh: line 131: 19334 Segmentation fault      "$prog" ${1+"$@"}

Also, I should note that I see this on two systems, both Gentoo Linux, one x86 and one x86_64 with no 32-bit libraries (and therefore self-compiled 64-bit firefox).
(Reporter)

Comment 6

9 years ago
Using hg bisect, I get

The first bad revision is:
changeset:   15923:8be867e8b341
user:        L. David Baron <dbaron@dbaron.org>
date:        Sun Jul 13 20:20:27 2008 -0700
summary:     Don't leak the result of PR_LoadLibrary for the xinerama library.  (Bug 403706)  r+sr=roc
Blocks: 403706
Component: General → Widget: Gtk
Product: Firefox → Core
QA Contact: general → gtk
Flags: blocking1.9.1?
If you run firefox inside gdb (./firefox -g, then type "run"), what stack does gdb show you when it crashes (type "bt" at the "(gdb)" prompt)?
(Reporter)

Comment 8

9 years ago
Done three times with the following three results:

#0  0xb23031b2 in ?? ()
#1  0xb74e54ea in snd_seq_delete_port () from /usr/lib/libasound.so.2
#2  0xb6b23800 in ?? ()
#3  0xafba6884 in ?? ()
#4  0xb6b3f100 in ?? ()
#5  0xb77f8ff4 in gdk_drag_get_selection () from /usr/lib/libgdk-x11-2.0.so.0
#6  0x00000004 in ?? ()
#7  0x00000001 in ?? ()
#8  0xbfa48a48 in ?? ()
#9  0xb77af859 in ?? () from /usr/lib/libgdk_pixbuf-2.0.so.0
#10 0xb6b23800 in ?? ()
#11 0xb75f3a54 in ?? () from /usr/lib/libX11.so.6
#12 0x00000000 in ?? ()

#0  0xafd041b2 in ?? ()
#1  0xb75364ea in _XimGetAttributeID () from /usr/lib/libX11.so.6
#2  0xb6b23800 in ?? ()
#3  0xafca4884 in ?? ()
#4  0xb6b3f100 in ?? ()
#5  0xb7849ff4 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#6  0x00000004 in ?? ()
#7  0x00000001 in ?? ()
#8  0xbff99f98 in ?? ()
#9  0xb7800859 in ?? () from /usr/lib/libatk-1.0.so.0
#10 0xb6b23800 in ?? ()
#11 0xb7644a54 in ?? () from /usr/lib/libglib-2.0.so.0
#12 0x00000000 in ?? ()

#0  0xb02e71b2 in ?? ()
#1  0xb75674ea in ?? ()
#2  0xb6b23800 in ?? ()
#3  0xb04a4884 in ?? ()
#4  0xb6b3f100 in ?? ()
#5  0xb787aff4 in ?? () from /usr/lib/libgdk-x11-2.0.so.0
#6  0x00000004 in ?? ()
#7  0x00000001 in ?? ()
#8  0xbfccacc8 in ?? ()
#9  0xb7831859 in gdk_gc_set_rgb_fg_color () from /usr/lib/libgdk-x11-2.0.so.0
#10 0xb6b23800 in ?? ()
#11 0xb7675a54 in g_intern_static_string () from /usr/lib/libglib-2.0.so.0
#12 0x00000000 in ?? ()
If there's some bad interaction with the xinerama lib unloading, can we just leak it anyway?  That seems like the simplest fix..
Flags: wanted1.9.1+
Flags: blocking1.9.1?
Flags: blocking1.9.1-
Priority: -- → P3
Yeah.  That's fine with me, assuming it's been observed on released versions of software (i.e., more than gentoo-if-built-on-particular-day).
I think the patch in bug 448512 should fix this.
Depends on: 448512
(Reporter)

Comment 12

9 years ago
Indeed, it did.

Thanks!
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.