Last Comment Bug 766877 - EXCEPTION_BREAKPOINT crash in nsXPCWrappedJSClass::DelegatedQueryInterface @ GetContextFromObject with BabyFox.dll / Babylon Translation Firefox Extension
: EXCEPTION_BREAKPOINT crash in nsXPCWrappedJSClass::DelegatedQueryInterface @ ...
Status: VERIFIED FIXED
[startupcrash]
: crash, regression, topcrash
Product: Core
Classification: Components
Component: XPConnect (show other bugs)
: 16 Branch
: x86 Windows 7
: -- critical (vote)
: mozilla17
Assigned To: Jorge Villalobos [:jorgev]
:
Mentors:
Depends on: 721264
Blocks: Babylon
  Show dependency treegraph
 
Reported: 2012-06-21 00:42 PDT by Scoobidiver (away)
Modified: 2012-10-16 15:47 PDT (History)
10 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
+
verified
+
verified


Attachments

Description Scoobidiver (away) 2012-06-21 00:42:50 PDT
It first appeared in 16.0a1/20120620030535. The regression range is:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=373e6f9264e6&tochange=83369c1bb9af

Signature 	GetContextFromObject More Reports Search
UUID	1459f093-9c9e-4d1e-9055-01fad2120621
Date Processed	2012-06-21 07:20:53
Uptime	16
Last Crash	10.4 weeks before submission
Install Age	16 seconds since version was first installed.
Install Time	2012-06-21 07:20:20
Product	Firefox
Version	16.0a1
Build ID	20120620065138
Release Channel	nightly
OS	Windows NT
OS Version	6.1.7601 Service Pack 1
Build Architecture	x86
Build Architecture Info	GenuineIntel family 6 model 23 stepping 10
Crash Reason	EXCEPTION_BREAKPOINT
Crash Address	0x5e03ca8e
App Notes 	
AdapterVendorID: 0x8086, AdapterDeviceID: 0x2a42, AdapterSubsysID: 00051179, AdapterDriverVersion: 8.15.10.1749
D3D10 Layers? D3D10 Layers- D3D9 Layers? D3D9 Layers- 
EMCheckCompatibility	True
Adapter Vendor ID	0x8086
Adapter Device ID	0x2a42
Total Virtual Memory	2147352576
Available Virtual Memory	1859457024
System Memory Use Percentage	51
Available Page File	4123009024
Available Physical Memory	1499209728

Frame 	Module 	Signature 	Source
0 	xul.dll 	GetContextFromObject 	js/xpconnect/src/XPCWrappedJSClass.cpp:499
1 	xul.dll 	nsXPCWrappedJSClass::DelegatedQueryInterface 	js/xpconnect/src/XPCWrappedJSClass.cpp:622
2 	xul.dll 	nsXPCWrappedJS::QueryInterface 	js/xpconnect/src/XPCWrappedJS.cpp:129
3 	xul.dll 	nsQueryReferent::operator 	obj-firefox/xpcom/build/nsWeakReference.cpp:56
4 	xul.dll 	nsCOMPtr_base::assign_from_helper 	obj-firefox/xpcom/build/nsCOMPtr.cpp:117
5 	xul.dll 	nsDocLoader::GetListenerInfo 	uriloader/base/nsDocLoader.cpp:1515
6 	xul.dll 	nsDocLoader::AddProgressListener 	uriloader/base/nsDocLoader.cpp:956
7 	BabyFox.dll 	BabyFox.dll@0x176bd 	
8 	BabyFox.dll 	BabyFox.dll@0x176ee 	
9 	BabyFox.dll 	BabyFox.dll@0x2fd9 	
10 	BabyFox.dll 	BabyFox.dll@0x18ef7 	
11 	kernel32.dll 	BaseThreadInitThunk 	
12 	ntdll.dll 	__RtlUserThreadStart 	
13 	ntdll.dll 	_RtlUserThreadStart

More reports at:
https://crash-stats.mozilla.com/report/list?signature=GetContextFromObject
Comment 1 Scoobidiver (away) 2012-06-21 04:35:46 PDT
It's #2 top browser crasher in today's build with many dupes.

Here are correlations per module version:
100% (33/33) vs.   2% (37/1556) BabyFox.dll
          3% (1/33) vs.   0% (1/1556) 8.0.8.2
         12% (4/33) vs.   0% (5/1556) 8.0.9.4
         15% (5/33) vs.   0% (7/1556) 8.1.0.16
         15% (5/33) vs.   0% (5/1556) 9.0.4.10
         36% (12/33) vs.   1% (12/1556) 9.0.4.13
         18% (6/33) vs.   0% (6/1556) 9.0.4.26
Comment 2 Benjamin Smedberg AWAY UNTIL 2-AUG-2016 [:bsmedberg] 2012-06-21 10:58:33 PDT
We slightly changed the behavior of MOZ_CRASH in this nightly in bug 761859 so that the aborts would show up with EXCEPTION_BREAKPOINT instead of EXCEPTION_INVALID_WRITE. I don't *think* that would change the signature, but is there a preexisting signature which might have morphed into this one?
Comment 3 Ben Turner (not reading bugmail, use the needinfo flag!) 2012-06-21 11:00:55 PDT
Also, seems pretty clear that this extension is running JS off the main thread...
Comment 4 Benjamin Smedberg AWAY UNTIL 2-AUG-2016 [:bsmedberg] 2012-06-21 11:22:49 PDT
Oh interesting, we need to highlight the non-mainthreadness of crashes in socorro more.

Anyway, I don't think they are intentionally running JS, but they are calling nsDocLoader::AddProgressListener off the main thread which is obviously verboten. It's a little strange that it's passing a JS-implemented progress listener, but that's just icing on the badness. So did we just become a little more anal about threading checks, which sounds like a good thing and this can just go over to Addon evangelization?
Comment 5 Jorge Villalobos [:jorgev] 2012-06-21 13:23:37 PDT
I'll ping the Babylon people about this problem.
Comment 6 Scoobidiver (away) 2012-06-22 15:13:03 PDT
The spike is gone until it comes back when 16.0 goes to Aurora.
Comment 7 Scoobidiver (away) 2012-06-25 00:42:01 PDT
The signature morphed to nsXPConnect::GetXPConnect from 16.0a1/20120623.
Comment 8 Jorge Villalobos [:jorgev] 2012-06-26 13:48:17 PDT
The Babylon people fixed the problem and and released an update. Maybe the updated version is the one causing the crashes in comment #7. Are those significant in number, and are they also startup crashes?
Comment 9 Scoobidiver (away) 2012-06-26 14:55:34 PDT
Here are crash reports related to the signature in comment 7 (66% on startup and more in the trunk):
https://crash-stats.mozilla.com/report/list?signature=nsXPConnect%3A%3AGetXPConnect%28%29
The cutoff build for the morphed signature is 16.0a1/20120623 so it's not correlated to a new Babylon version (it would have been a cutoff date).
Comment 10 Scoobidiver (away) 2012-07-06 05:59:29 PDT
It's #12 top browser crasher in 16.0a1 with the same correlations:
100% (18/18) vs.   1% (25/1988) BabyFox.dll
         11% (2/18) vs.   0% (2/1988) 8.0.8.2
         39% (7/18) vs.   0% (7/1988) 8.0.9.4
          6% (1/18) vs.   0% (1/1988) 8.1.0.16
          6% (1/18) vs.   0% (1/1988) 9.0.2.11
          6% (1/18) vs.   0% (1/1988) 9.0.3.12
         11% (2/18) vs.   0% (3/1988) 9.0.4.13
         22% (4/18) vs.   1% (10/1988) 9.0.4.26

Does Babylon have an automatic update feature (from 8 to 9 and from 9.0.4 to 9.0.5)?
Comment 11 Scoobidiver (away) 2012-07-23 14:53:04 PDT
It's #4 top browser crasher in 16.0a2 and #9 in 17.0a1.
Babylon's users who can't (don't pay for version 9) or don't upgrade won't be able to run Firefox from Fx 16.0.
Comment 12 Alex Keybl [:akeybl] 2012-07-23 15:08:15 PDT
(In reply to Jorge Villalobos [:jorgev] from comment #8)
> The Babylon people fixed the problem and and released an update. Maybe the
> updated version is the one causing the crashes in comment #7. Are those
> significant in number, and are they also startup crashes?

Scoobidiver is implying that there hasn't been a stability fix made for users on older versions (and an upgrade is paid). Can we ask them for clarification there?
Comment 13 Jorge Villalobos [:jorgev] 2012-07-23 16:17:16 PDT
Sent a message to Babylon.
Comment 14 Scoobidiver (away) 2012-07-23 23:55:29 PDT
Based on crash correlations per module version in 14.0.1, the Babylon version breakdown is as follow (captlib.dll):
 5.0.1.7	0.14%
 5.0.6.13	0.27%
 6.0.0.20	1.37%
 6.0.0.29	0.14%
 6.0.1.36	0.14%
 7.0.0.13	0.14%
 7.0.1.4	0.69%
 7.0.2.2	0.14%
 7.0.3.13	0.14%
 7.0.3.14	0.14%
 7.0.3.23	0.27%
 7.0.3.8	0.14%
 7.5.2.10	0.14%
 7.5.2.13	0.14%
 8.0.0.18	0.14%
 8.0.0.20	0.14%
 8.0.0.22	0.14%
 8.0.0.25	0.14%
 8.0.0.29	0.14%
 8.0.0.36	0.14%
 8.0.0.38	0.14%
 8.0.1.12	0.14%
 8.0.2.11	0.14%
 8.0.3.3	0.14%
 8.0.5.2	0.14%
 8.0.5.7	0.41%
 8.0.6.3	0.14%
 8.0.6.5	0.14%
 8.0.7.7	0.14%
 8.0.8.2	0.41%
 8.0.8.3	0.14%
 8.0.9.4	1.92%
 8.1.0.16	1.10%
 8.1.0.19	0.14%
 9.0.0.30	2.34%
 9.0.0.31	0.41%
 9.0.1.5	0.41%
 9.0.2.10	0.69%
 9.0.2.11	2.34%
 9.0.2.2	0.41%
 9.0.3.12	0.69%
 9.0.3.14	0.55%
 9.0.3.23	5.77%
 9.0.3.29	0.27%
 9.0.4.10	1.51%
 9.0.4.13	8.52%
 9.0.4.26	20.19%
 9.0.5.17	13.05%
 9.0.5.18	1.79%
 9.0.5.19	31.04%
It seems there's NOT an automatic update feature.

Based on crash correlations per module version in 16.0a2 and 17.0a1, only versions 9.0.5.x seem to contain the fix.
Comment 15 Jorge Villalobos [:jorgev] 2012-08-03 14:07:03 PDT
Last I spoke with Babylon, they were deploying a major update to all of their users. Has there been any change in the stats in comment #14?
Comment 16 Scoobidiver (away) 2012-08-03 14:57:03 PDT
(In reply to Jorge Villalobos [:jorgev] from comment #15)
> Last I spoke with Babylon, they were deploying a major update to all of their
> users.
Is this company that has software hijacking Firefox's user preferences trustworthy?

> Has there been any change in the stats in comment #14?
Based on captlib version in 14.0.1, it's almost identical:
 1.0.0.0	0,51%
 4.0.1.6	0,08%
 4.0.5.9	0,08%
 6.0.0.20	1,02%
 6.0.0.29	0,25%
 6.0.1.36	0,08%
 7.0.0.13	0,17%
 7.0.0.16	0,25%
 7.0.1.4	0,85%
 7.0.3.11	0,08%
 7.0.3.24	0,25%
 7.0.3.8	0,08%
 7.5.2.3	0,08%
 7.5.2.5	0,17%
 8.0.0.18	0,25%
 8.0.0.20	0,25%
 8.0.0.22	0,25%
 8.0.0.25	0,17%
 8.0.0.34	0,08%
 8.0.0.36	0,08%
 8.0.0.38	0,08%
 8.0.1.11	0,08%
 8.0.1.14	0,08%
 8.0.2.11	0,08%
 8.0.4.3	0,17%
 8.0.5.2	0,08%
 8.0.5.5	0,42%
 8.0.5.7	0,25%
 8.0.6.3	0,08%
 8.0.6.5	0,17%
 8.0.7.7	0,25%
 8.0.7.8	0,17%
 8.0.8.2	0,34%
 8.0.8.3	0,08%
 8.0.9.4	1,95%
 8.0.9.8	0,08%
 8.1.0.16	0,93%
 8.1.0.19	0,08%
 9.0.0.30	1,78%
 9.0.0.31	0,17%
 9.0.1.4	0,08%
 9.0.1.5	0,76%
 9.0.2.10	0,76%
 9.0.2.11	2,04%
 9.0.2.2	0,68%
 9.0.2.5	0,42%
 9.0.3.12	0,51%
 9.0.3.14	0,59%
 9.0.3.23	7,04%
 9.0.3.29	0,25%
 9.0.3.47	0,17%
 9.0.4.10	1,19%
 9.0.4.13	8,99%
 9.0.4.26	17,56%
 9.0.5.17	11,45%
 9.0.5.18	1,61%
 9.0.5.19	33,42%
Comment 17 Jorge Villalobos [:jorgev] 2012-08-06 08:21:54 PDT
(In reply to Scoobidiver from comment #16)
> (In reply to Jorge Villalobos [:jorgev] from comment #15)
> > Last I spoke with Babylon, they were deploying a major update to all of their
> > users.
> Is this company that has software hijacking Firefox's user preferences
> trustworthy?

They have been very cooperative and responsive ever since we began talking to them.

> 
> > Has there been any change in the stats in comment #14?
> Based on captlib version in 14.0.1, it's almost identical:

Thanks, I'll let them know.
Comment 18 Lukas Blakk [:lsblakk] use ?needinfo 2012-08-08 09:45:05 PDT
Assigning to Jorge since he's the one driving this.
Comment 19 Scoobidiver (away) 2012-08-20 08:18:55 PDT
It's #13 top browser crasher in 16.0a2 and still a startup crash so Babylon users with versions before 9.0.5 won't be able to use Firefox 16 and above.
Comment 20 Alex Keybl [:akeybl] 2012-08-22 09:12:47 PDT
Should be resolved in bug 721264, hopefully in time for our first FF16 beta.
Comment 21 Scoobidiver (away) 2012-08-24 03:36:26 PDT
(In reply to Alex Keybl [:akeybl] from comment #20)
> Should be resolved in bug 721264, hopefully in time for our first FF16 beta.
There are no crashes after 17.0a1/20120822 and 16.0a2/20120822.
Comment 22 Paul Silaghi, QA [:pauly] 2012-09-17 09:09:03 PDT
(In reply to Scoobidiver from comment #21)
> (In reply to Alex Keybl [:akeybl] from comment #20)
> > Should be resolved in bug 721264, hopefully in time for our first FF16 beta.
> There are no crashes after 17.0a1/20120822 and 16.0a2/20120822.

I still see 2 crashes on FF 16.0b3.
Comment 23 Scoobidiver (away) 2012-09-17 09:22:27 PDT
(In reply to Paul Silaghi [QA] from comment #22)
> I still see 2 crashes on FF 16.0b3.
There are 5 crashes from 2 users: bp-b6fe8217-0c5c-4f5b-940d-cd3502120916, bp-dd920c2f-1325-411f-a437-fa1212120916, bp-4b8643e4-1c60-41fc-a417-1a3652120915, bp-1fa88aa0-bee6-4648-b62e-876f52120915, bp-7c9bd43d-ffed-49fe-bfae-87b4b2120915.
The DLL blocklist is not something fully reliable depending on the way it's loaded.
Comment 24 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-10-16 15:47:59 PDT
Though we've not been able to directly verify this is fixed (due to lack of reproducible testcase) we've seen a dramatic reduction in this signature on Socorro. Based on this I am marking this bug verified.

Note You need to log in before you can comment on or make changes to this bug.