crash in uGlobalMenuDocListener::DoHandleMutations with GlobalMenu on Ubuntu

RESOLVED WORKSFORME

Status

()

--
critical
RESOLVED WORKSFORME
6 years ago
3 years ago

People

(Reporter: scoobidiver, Unassigned)

Tracking

({crash})

20 Branch
All
Linux
crash
Points:
---

Firefox Tracking Flags

(firefox20 affected)

Details

(crash signature)

Attachments

(1 attachment)

(Reporter)

Description

6 years ago
It's similar to bug 858670.

Signature 	uGlobalMenuDocListener::DoHandleMutations(nsIArray*) More Reports Search
UUID	f4b3a020-8517-41d6-9304-0867c2130405
Date Processed	2013-04-05 14:52:49
Uptime	10052
Last Crash	more than 3 months before submission
Install Age	2.8 hours since version was first installed.
Install Time	2013-04-05 12:04:56
Product	Firefox
Version	20.0
Build ID	20130329030832
Release Channel	release
OS	Linux
OS Version	0.0.0 Linux 3.2.0-39-generic #62-Ubuntu SMP Thu Feb 28 00:28:53 UTC 2013 x86_64
Build Architecture	amd64
Build Architecture Info	family 15 model 4 stepping 1
Crash Reason	SIGSEGV
Crash Address	0x0
App Notes 	
OpenGL: X.Org R300 Project -- Gallium 0.4 on ATI RV370 -- 2.1 Mesa 8.0.4 -- texture_from_pixmap
Processor Notes 	sp-processor06.phx1.mozilla.com_5882:2008; exploitablity tool: ERROR: unable to analyze dump
EMCheckCompatibility	True

Frame 	Module 	Signature 	Source
0 	libglobalmenu.so 	uGlobalMenuDocListener::DoHandleMutations 	uGlobalMenuDocListener.cpp:157
1 	libglobalmenu.so 	uGlobalMenuDocListener::HandleMutations 	uGlobalMenuDocListener.cpp:139
2 	libxul.so 	NS_InvokeByIndex_P 	xptcinvoke_x86_64_unix.cpp:164
3 	libxul.so 	XPCWrappedNative::CallMethod 	XPCWrappedNative.cpp:3086
4 	libxul.so 	XPC_WN_CallMethod 	XPCWrappedNativeJSOps.cpp:1488
5 	libxul.so 	js::InvokeKernel 	jscntxtinlines.h:373
6 	libxul.so 	js::Interpret 	jsinterp.cpp:2366
7 	libxul.so 	js::RunScript 	jsinterp.cpp:346
8 	libxul.so 	js::InvokeKernel 	jsinterp.cpp:404
9 	libxul.so 	js::Invoke 	jsinterp.h:112
10 	libxul.so 	js::BaseProxyHandler::call 	jsproxy.cpp:266
11 	libxul.so 	js::Wrapper::call 	jswrapper.cpp:298
12 	libxul.so 	js::CrossCompartmentWrapper::call 	jswrapper.cpp:631
13 	libxul.so 	proxy_Call 	jsproxy.cpp:2438
14 	libxul.so 	js::InvokeKernel 	jscntxtinlines.h:373
15 	libxul.so 	js::Invoke 	jsinterp.h:112
16 	libxul.so 	JS_CallFunctionValue 	jsapi.cpp:5817
17 	libxul.so 	mozilla::dom::MutationCallback::Call 	MutationObserverBinding.cpp:667
18 	libxul.so 	nsDOMMutationObserver::HandleMutation 	MutationObserverBinding.h:167
19 	libxul.so 	nsDOMMutationObserver::HandleMutationsInternal 	nsDOMMutationObserver.cpp:640
20 	libxul.so 	nsEventListenerManager::HandleEventSubType 	nsContentUtils.h:2289 

More reports at:
https://crash-stats.mozilla.com/report/list?signature=uGlobalMenuDocListener%3A%3ADoHandleMutations%28nsIArray*%29

Comment 1

6 years ago
This might be connected with bug 858670.

Comment 2

6 years ago
Bug 858670 is different, and one for which I have a trivial fix already. But I've got absolutely no idea what is going on with this one, and I can't reproduce it :(

Because most of this add on is binary, it contains a small JS XPCOM component in order to be able to use MutationObserver to capture changes from the menubar. All this component does is take the incoming MutationRecords, wrap each of these in another JS component, add them to a nsIMutableArray and pass it to the native code. Where it's failing on the native side is that these array elements are then failing to QI to an interface that they all implement, which shouldn't be possible :/

From looking at the comments, they all mention Google Docs. I had a colleague hit this a few times too, and it only occurred when Google Docs displayed a tab modal error alert.

Comment 3

6 years ago
Did any of the reporters leave any contact information?
(Reporter)

Comment 4

6 years ago
Based on comments, it's related to pasting in Google Drive/Docs.

Comment 5

6 years ago
I'm struggling with this. At this stage, it would be useful to ask anyone who has left an e-mail address to contact me. Is that possible?
(Reporter)

Updated

6 years ago
Keywords: qawanted

Comment 6

6 years ago
Created attachment 739678 [details]
Stack trace

I've managed to reproduce this once now whilst in a debugger, but it's taken me the entire week to do so.

Basically, when my addon calls QueryInterface from native code on one of the JS objects passed to it, the JS interpreter runs my objects QueryInterface function, but it fails in xpconnect when resolving the "equals" property on the nsJSID object (passed in as the first argument to QI). It's failing because it's hitting a stack recursion failure in the JS engine (the attached stacktrace shows exactly where it fails).

Sure enough, at the point it fails the stack space is almost fully exhausted:

(gdb) info registers 
eax            0x1a	26
ecx            0xafa1f000	-1348341760
edx            0xb66a8200	-1234533888
ebx            0xb75fc884	-1218459516
esp            0xbff7f770	0xbff7f770  <------------
ebp            0xbff7f978	0xbff7f978
esi            0xb7a50f40	-1213919424
edi            0xbff7f828	-1074268120
eip            0xb66a9409	0xb66a9409 <js_ReportOverRecursed(JSContext*)+57>
eflags         0x200282	[ SF IF ID ]
cs             0x73	115
ss             0x7b	123
ds             0x7b	123
es             0x7b	123
fs             0x0	0
gs             0x33	51

chr1s@sec-precise-i386:~$ cat /proc/`pidof firefox`/maps | grep "\[stack\]"
bff7b000-c0000000 rw-p 00000000 00:00 0          [stack]

The stack space is already almost fully exhausted by the first frame in my addons code:

(gdb) f 43
#43 0xb1515cfb in uGlobalMenuDocListener::DoHandleMutations (this=this@entry=0xa6c7c0d0, 
    aRecords=0xb44ea50)
    at /home/chr1s/src/globalmenu-extension/build/extensions/globalmenu/src/uGlobalMenuDocListener.cpp:168
168	/home/chr1s/src/globalmenu-extension/build/extensions/globalmenu/src/uGlobalMenuDocListener.cpp: No such file or directory.
(gdb) p &length
$98 = (uint32_t *) 0xbff80858

At this point, I'm not sure this is actually an addon bug tbh...
Chris, is there anything QA can do to assist you here? Maybe attempting to reproduce this outside of a debug environment? What sort of data would be useful to you?
Flags: needinfo?(chrisccoulson)
There are no crashes in the crashstats on Firefox > v20. I think it's safe to close this.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Keywords: qawanted
Resolution: --- → WORKSFORME
Clearing out old need-info request.
Flags: needinfo?(chrisccoulson)
You need to log in before you can comment on or make changes to this bug.