Quit browser while XUL dialog is showing causes seg fault




Extension Compatibility
11 years ago
7 years ago


(Reporter: Christopher Bare, Unassigned)


Firefox Tracking Flags

(Not tracked)


(Whiteboard: [CLOSEME 2010-11-15])



11 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv: Gecko/20070713 Firefox/
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv: Gecko/20070713 Firefox/

Open an XUL dialog (part of an add-on extension) and press command-Q to quit. Dialog closes, crash dialog appears, and this appears in the console:

[error occurred during error reporting, step 0, id 0xa]

/Applications/firefox.app/Contents/MacOS/run-mozilla.sh: line 424: 18640 Segmentation fault      "$prog" ${1+"$@"}

Reproducible: Always

Steps to Reproduce:
Reproduces consistently for me:

1. Install Firegoose extension
2. Select "more" in the target drop-down on the firegoose toolbar.
3. xul dialog pops up.
4. command-Q to quit browser
5. crash

Actual Results:  
segmentation fault during shutdown.

Expected Results:  
shut down browser normally

a javascript ondialogaccept handler is registered that accesses the preference service and the console output service. What the hell, here's the XUL file:

<?xml version="1.0"?>

<?xml-stylesheet href="chrome://global/skin/" type="text/css"?>
<?xml-stylesheet href="chrome://firegoose/skin/overlay.css" type="text/css"?>

<!DOCTYPE dialog SYSTEM "chrome://firegoose/locale/firegoose.dtd">

<dialog id="fgEnableWebsites"
        ondialogaccept="FG_dialogAccept();" >

  <script type="application/x-javascript" src="firegoose.js"/>

  <script type="application/x-javascript">
	var windowParams = window.arguments[0];

	window.addEventListener("load", function() { FG_dialogInit(); }, false);
	function FG_dialogInit() {
		FG_trace("preferences init");
		var prefs = Components.classes["@mozilla.org/preferences-service;1"].

		function isVisible(name) {
			try {
		    	return prefs.getBoolPref(FG_fixName(name));
		    catch (e) {
		    	return true;

		function createListItem(name, visible) {
		    var item = document.createElement("richlistitem");
		    var checkbox = document.createElement("checkbox");
		    checkbox.setAttribute("label", name);
		    checkbox.setAttribute("checked", visible);
		    return item;

        var websiteList = document.getElementById("websiteList");

		for (var name in windowParams.websiteHandlers) {
			if (!windowParams.websiteHandlers[name].dontDisplayInMenu)
		    	websiteList.appendChild(createListItem(name, isVisible(name)));

	function FG_dialogAccept() {

        function toBoolean(value) {
        	if ("true" == value)
				return true;
				return false;
		var prefs = Components.classes["@mozilla.org/preferences-service;1"].

        var websiteList = document.getElementById("websiteList");
        var children = websiteList.childNodes;

		for (var i=0; i &lt; children.length; i++) {
			var node = children.item(i).firstChild;
			var checked = toBoolean(node.getAttribute("checked"));
			var name = node.getAttribute("label");
			prefs.setBoolPref(FG_fixName(name), checked);
		windowParams["ok"] = true;

  <vbox flex="1">
	<label control="websiteList" class="dialogTitle" value="Enable Websites" />
	<description style="width: 30em;">
      Select the target websites that will be visible in the drop-down menu. Some
      targets listed here are experimental.
    <richlistbox id="websiteList" flex="1" tooltiptext="Enable or disable firegoose access to websites">



and here's FG_trace:

function FG_trace(msg) {

Comment 1

11 years ago
Forgot to say, Firegoose extension is here: http://gaggle.systemsbiology.org/docs/geese/firegoose/

Problem is likely not specific to this extension.

Comment 2

11 years ago
Can you reproduce the crash with any dialogs that are part of Firefox?

Does the crash still happen on trunk?

Comment 3

11 years ago
Does the <dialog ...> XUL tag get used within firefox? It looks like all the "dialogs" that are part of FF are actually separate windows. For example, if I open preferences and hit command-Q FF exits normally with no crash. But, the preferences dialog is it's own window whereas my dialogs slide down from the top bar like a alert box. I assume that's because the built-in dialogs aren't using the <dialog> XUL tag. Maybe I shouldn't either.

I was hoping the debugging output (which comes from FF not from me) would make it possible to figure out even w/out an easy repro:

[error occurred during error reporting, step 0, id 0xa]

Sometimes I get several of these and then:

[Too many errors, abort]


Comment 4

11 years ago
After a little more experimentation, it looks like the ondialogaccept callback never gets called.

I added some debugging output (dump("wtf\n"); to me FG_dialogAccept function), which appears if I press OK, but doesn't appear if I press command-Q causing the crash. That would seem to rule out the idea that something I'm doing in my ondialogaccept handler is the culprit, but ya never know.

I'm guessing the bug happens if you have an XUL <dialog> open and press command-Q.

Here's this, in case it helps:

Date/Time:      2007-07-25 11:10:54.260 -0700
OS Version:     10.4.10 (Build 8R218)
Report Version: 4

Command: firefox-bin
Path:    /Applications/firefox.app/Contents/MacOS/firefox-bin
Parent:  sh [19116]

Version: (

PID:    19122
Thread: 0

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_INVALID_ADDRESS (0x0001) at 0x2c0e4000

Thread 0 Crashed:
0   libxpcom_core.dylib 	0x2c01cbc0 nsVoidArray::IndexOf(void*) const + 44
1   libxpcom_core.dylib 	0x2c01d068 nsVoidArray::RemoveElement(void*) + 24
2   org.mozilla.firefox 	0x0061a760 nsMacEventDispatchHandler::SetWidgetHit(nsWindow*) + 56
3   org.mozilla.firefox 	0x0061c804 nsMacEventHandler::HandleMouseUpEvent(EventRecord&) + 212
4   org.mozilla.firefox 	0x0061aa70 nsMacEventHandler::HandleOSEvent(EventRecord&) + 108
5   org.mozilla.firefox 	0x0029d2e8 nsMacWindow::DispatchEvent(void*, int*) + 80
6   org.mozilla.firefox 	0x00616f10 nsMacMessagePump::DispatchOSEventToRaptor(EventRecord&, OpaqueWindowPtr*) + 96
7   org.mozilla.firefox 	0x00616e0c nsMacMessagePump::DoMouseUp(EventRecord&) + 76
8   org.mozilla.firefox 	0x00616794 nsMacMessagePump::DispatchEvent(EventRecord*) + 92
9   org.mozilla.firefox 	0x00617020 nsMacMessagePump::WNETransitionEventHandler(OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*) + 44
10  com.apple.HIToolbox 	0x93294934 DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*) + 692
11  com.apple.HIToolbox 	0x9329408c SendEventToEventTargetInternal(OpaqueEventRef*, OpaqueEventTargetRef*, HandlerCallRec*) + 372
12  com.apple.HIToolbox 	0x9329ae90 SendEventToEventTarget + 40
13  com.apple.HIToolbox 	0x93327224 HandleMouseEventForWindow(OpaqueWindowPtr*, OpaqueEventRef*, unsigned short) + 236
14  com.apple.HIToolbox 	0x9348a3dc HandleMouseEvent(OpaqueEventRef*) + 368
15  com.apple.HIToolbox 	0x9329b1fc ToolboxEventDispatcherHandler(OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*) + 496
16  com.apple.HIToolbox 	0x93294b84 DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*) + 1284
17  com.apple.HIToolbox 	0x9329408c SendEventToEventTargetInternal(OpaqueEventRef*, OpaqueEventTargetRef*, HandlerCallRec*) + 372
18  com.apple.HIToolbox 	0x9329ae90 SendEventToEventTarget + 40
19  com.apple.HIToolbox 	0x932dbc04 ToolboxEventDispatcher + 92
20  com.apple.HIToolbox 	0x932dbb90 HLTBEventDispatcher + 16
21  com.apple.HIToolbox 	0x932da148 RunApplicationEventLoop + 148
22  org.mozilla.firefox 	0x002964fc nsAppShell::Run() + 64
23  org.mozilla.firefox 	0x00334134 nsAppStartup::Run() + 60
24  org.mozilla.firefox 	0x00012a14 XRE_main + 4904
25  org.mozilla.firefox 	0x0000d768 start + 432
26  org.mozilla.firefox 	0x0000d5e8 start + 48

Comment 5

11 years ago
I also get this in the console log:

Jul 25 11:36:03 220Volt /Applications/firefox.app/Contents/MacOS/firefox-bin:


An unexpected Java error has been detected by HotSpot Virtual Machine.
Java VM: Java HotSpot(TM) Client VM (1.5.0_07-87 mixed mode)
Bus Error (0xa) at pc=0x2c01cbc0
Process ID: 19165, Current Thread: 33893888


Jul 25 11:36:06 220Volt crashdump[19167]: firefox-bin crashed
Jul 25 11:36:06 220Volt crashdump[19167]: crash report written to: /Users/cbare/Library/Logs/CrashReporter/firefox-bin.crash.log

and in JavaNativeCrash_pid19165.crash.log:

VM state:not at safepoint (normal execution)

My guess is that this is the JVM's way of complaining about not being shut down properly, but I can't say that's based on a lot of knowledge. It could be that FF crashes and takes the JVM with it, or maybe the other way around.

We use java in our toolbar, but not in the particular dialog in question.

What happens if you disable Java before running your test?

(Yes, I know that doing this will (partially?) disable your toolbar.
But if possible please try it anyway.)

Comment 7

11 years ago
I was able to try that. I unchecked "enable Java" and restarted FF. Then opened my dialog and pressed command-Q. I still get the crash. No Java error. Slightly different output in the terminal window:

I still get:

/Applications/firefox.app/Contents/MacOS/run-mozilla.sh: line 424: 19392 Segmentation fault      "$prog" ${1+"$@"}

The previous output about "[error occurred during error reporting, step 0, id 0xa]" does NOT appear. Nor does the "too many errors" thing.

Same trace appears in the crash log:

Version: (

PID:    19409
Thread: 0

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at 0x00000005

Thread 0 Crashed:
0   libxpcom_core.dylib 	0x2c01cb94 nsVoidArray::IndexOf(void*) const + 0
1   libxpcom_core.dylib 	0x2c01d068 nsVoidArray::RemoveElement(void*) + 24
2   org.mozilla.firefox 	0x0061a760 nsMacEventDispatchHandler::SetWidgetHit(nsWindow*) + 56

If you guys think it's worth while, I can try to create a minimal XPI that reproduces the problem. The only problem is, I doubt I'll have time right away, but I could try.

Thanks for the info.  I'm the author of the Java Embedding Plugin
bundled with Mac distros of Mozilla.org browsers ... so I breathe a
sigh of relief :-)

> I can try to create a minimal XPI that reproduces the problem.

I think this would be very useful.

And don't forget Jesse's questions from comment #2:

> Can you reproduce the crash with any dialogs that are part of
> Firefox?
> Does the crash still happen on trunk?
This bug was reported using Firefox 3.0 or older, which is no longer supported. The bug has also not been changed in over 500 days and is still in UNCO.
Reporter, please retest this bug in Firefox 3.6.10 or later using a fresh profile, http://support.mozilla.com/en-US/kb/managing+profiles. If you still see this problem, please update the bug. If you no longer see the bug, please set the resolution to RESOLVED, WORKSFORME.

This is a mass search of unconfirmed bugs that have no activity on them, so if you feel a bug was marked in error, just remove the CLOSEME comment in the whiteboard within the next month.
Whiteboard: [CLOSEME 2010-11-15]
No reply, INCOMPLETE. Please retest with Firefox 3.6.12 or later and a new profile (http://support.mozilla.com/kb/Managing+profiles). If you continue to see this issue with the newest firefox and a new profile, then please comment on this bug.
Last Resolved: 7 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.