The default bug view has changed. See this FAQ.

crash in mozilla::AndroidGeckoLayerClient::SetFirstPaintViewport

RESOLVED FIXED in Firefox 15

Status

()

Core
Widget: Android
--
critical
RESOLVED FIXED
5 years ago
3 years ago

People

(Reporter: Scoobidiver (away), Assigned: kats)

Tracking

(4 keywords)

15 Branch
mozilla17
ARM
Android
crash, intermittent-failure, regression, topcrash
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox15+ fixed, firefox16+ verified, firefox17 fixed)

Details

(Whiteboard: [native-crash][startupcrash], crash signature)

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

5 years ago
There are only two crashes in 14.0b5 but there's a spike in startup crashes beginning from 16.0a1/20120606. The regression range for the spike is:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=a7a905fd70d5&tochange=6338a8988917
It's likely a regression from bug 758361 which was uplifted to Aurora.

Signature 	_JNIEnv::CallVoidMethod | mozilla::AndroidGeckoLayerClient::SetFirstPaintViewport More Reports Search
UUID	4a54c3c6-09ec-4376-b96b-87aa02120608
Date Processed	2012-06-08 21:40:28
Uptime	28
Last Crash	3.7 weeks before submission
Install Age	9.2 minutes since version was first installed.
Install Time	2012-06-08 21:31:13
Product	FennecAndroid
Version	16.0a1
Build ID	20120608030525
Release Channel	nightly
OS	Linux
OS Version	0.0.0 Linux 3.0.8+ #9 SMP PREEMPT Wed May 2 18:19:29 CEST 2012 armv7l
Build Architecture	arm
Build Architecture Info	
Crash Reason	SIGSEGV
Crash Address	0x0
App Notes 	
AdapterVendorID: archos, AdapterDeviceID: ARCHOS 80G9.
AdapterDescription: 'Model: 'ARCHOS 80G9', Product: 'G9A80', Manufacturer: 'archos', Hardware: 'archos''.
archos ARCHOS 80G9
archos/G9A80/A80:4.0.3/MR1/20120420.190002:user/release-keys
EMCheckCompatibility	True

Frame 	Module 	Signature 	Source
0 	libdvm.so 	libdvm.so@0x57a70 	
1 	libdvm.so 	libdvm.so@0x57a4f 	
2 	libxul.so 	_JNIEnv::CallVoidMethod 	jni.h:631
3 	libxul.so 	mozilla::AndroidGeckoLayerClient::SetFirstPaintViewport 	widget/android/AndroidJavaWrappers.cpp:664
4 	libxul.so 	mozilla::AndroidBridge::SetFirstPaintViewport 	widget/android/AndroidBridge.cpp:2047
5 	libxul.so 	mozilla::layers::CompositorParent::SetFirstPaintViewport 	gfx/layers/ipc/CompositorParent.cpp:429
6 	libxul.so 	mozilla::layers::CompositorParent::TransformShadowTree 	gfx/layers/ipc/CompositorParent.cpp:374
7 	libxul.so 	mozilla::layers::CompositorParent::Composite 	gfx/layers/ipc/CompositorParent.cpp:260
8 	libxul.so 	RunnableMethod<mozilla::layers::CompositorParent, void , Tuple0>::Run 	ipc/chromium/src/base/tuple.h:383
9 	libxul.so 	MessageLoop::RunTask 	ipc/chromium/src/base/message_loop.cc:318
10 	libxul.so 	MessageLoop::DeferOrRunPendingTask 	ipc/chromium/src/base/message_loop.cc:326
11 	libxul.so 	MessageLoop::DoWork 	ipc/chromium/src/base/message_loop.cc:426
12 	libxul.so 	base::MessagePumpDefault::Run 	ipc/chromium/src/base/message_pump_default.cc:23
13 	libxul.so 	MessageLoop::RunInternal 	ipc/chromium/src/base/message_loop.cc:208
14 	libxul.so 	MessageLoop::Run 	ipc/chromium/src/base/message_loop.cc:201
15 	libxul.so 	base::Thread::ThreadMain 	ipc/chromium/src/base/thread.cc:156
16 	libxul.so 	ThreadFunc 	ipc/chromium/src/base/platform_thread_posix.cc:31
17 	libc.so 	libc.so@0x12c4e 	
18 	libc.so 	libc.so@0x127a2 	
19 	libEGL.so 	libEGL.so@0x23e82 

More reports at:
https://crash-stats.mozilla.com/report/list?signature=_JNIEnv%3A%3ACallVoidMethod+|+mozilla%3A%3AAndroidGeckoLayerClient%3A%3ASetFirstPaintViewport
https://crash-stats.mozilla.com/report/list?signature=_JNIEnv%3A%3ACallVoidMethod
https://crash-stats.mozilla.com/report/list?signature=JNI_CreateJavaVM+|+_JNIEnv%3A%3ACallVoidMethod+|+mozilla%3A%3AAndroidGeckoLayerClient%3A%3ASetFirstPaintViewport
(Reporter)

Comment 1

5 years ago
As 15.0a2 is unaffected, it's not caused by bug 758361.
No longer blocks: 758361
Version: 15 Branch → 16 Branch
Given that this crash seems like a race condition on startup, I would guess that this change was the one that caused the spike in 16.0:

d945ae198516	Mike Hommey — Bug 760152 - Start library decompression earlier. r=blassey

Just a guess, though.
Setting as top crash : 6th on nightly, does not seem to appear in aurora, or beta
status-firefox14: --- → unaffected
status-firefox15: --- → unaffected
status-firefox16: --- → affected
Keywords: topcrash
CC'ing :glandium. Does bug 760152 only do library decompression earlier? Does it do any other gecko startup earlier?
(In reply to Kartikaya Gupta (:kats) from comment #4)
> CC'ing :glandium. Does bug 760152 only do library decompression earlier?
> Does it do any other gecko startup earlier?

Gecko's actual initialization has not moved. Only decompression did.
This crash is showing up a lot on tbpl; a lot of the android mochitest oranges are due to this. For example:

https://tbpl.mozilla.org/php/getParsedLog.php?id=12739494&tree=Firefox&full=1#error0
https://tbpl.mozilla.org/php/getParsedLog.php?id=12741230&tree=Firefox&full=1#error0
https://tbpl.mozilla.org/php/getParsedLog.php?id=12751669&tree=Firefox&full=1#error0
Blocks: 747787
https://tbpl.mozilla.org/php/getParsedLog.php?id=12817015&tree=Mozilla-Inbound
https://tbpl.mozilla.org/php/getParsedLog.php?id=12817062&tree=Mozilla-Inbound
https://tbpl.mozilla.org/php/getParsedLog.php?id=12818266&tree=Mozilla-Inbound
Whiteboard: [native-crash][startupcrash] → [native-crash][startupcrash][orange]

Updated

5 years ago
Blocks: 438871
https://tbpl.mozilla.org/php/getParsedLog.php?id=12834383&tree=Try
https://tbpl.mozilla.org/php/getParsedLog.php?id=12836079&tree=Mozilla-Inbound
https://tbpl.mozilla.org/php/getParsedLog.php?id=12838579&tree=Mozilla-Inbound
(Reporter)

Updated

5 years ago
Crash Signature: [@ _JNIEnv::CallVoidMethod | mozilla::AndroidGeckoLayerClient::SetFirstPaintViewport] [@ _JNIEnv::CallVoidMethod] [@ JNI_CreateJavaVM | _JNIEnv::CallVoidMethod | mozilla::AndroidGeckoLayerClient::SetFirstPaintViewport] → [@ _JNIEnv::CallVoidMethod | mozilla::AndroidGeckoLayerClient::SetFirstPaintViewport ] [@ _JNIEnv::CallVoidMethod ] [@ JNI_CreateJavaVM | _JNIEnv::CallVoidMethod | mozilla::AndroidGeckoLayerClient::SetFirstPaintViewport ]
https://tbpl.mozilla.org/php/getParsedLog.php?id=12956003&tree=Mozilla-Inbound
https://tbpl.mozilla.org/php/getParsedLog.php?id=12956240&tree=Mozilla-Inbound
https://tbpl.mozilla.org/php/getParsedLog.php?id=12957995&tree=Mozilla-Inbound#error1
https://tbpl.mozilla.org/php/getParsedLog.php?id=12958548&tree=Mozilla-Inbound#error1
https://tbpl.mozilla.org/php/getParsedLog.php?id=12969732&tree=Mozilla-Inbound#error1
https://tbpl.mozilla.org/php/getParsedLog.php?id=12973240&tree=Mozilla-Inbound#error1
https://tbpl.mozilla.org/php/getParsedLog.php?id=12999356&tree=Mozilla-Inbound
https://tbpl.mozilla.org/php/getParsedLog.php?id=13032476&tree=Fx-Team
tracking-fennec: --- → ?
https://tbpl.mozilla.org/php/getParsedLog.php?id=13066386&tree=Firefox
https://tbpl.mozilla.org/php/getParsedLog.php?id=13074544&tree=Mozilla-Inbound
https://tbpl.mozilla.org/php/getParsedLog.php?id=13098308&tree=Mozilla-Inbound
https://tbpl.mozilla.org/php/getParsedLog.php?id=13154543&tree=Ionmonkey
Assignee: nobody → bugmail.mozilla
Created attachment 641598 [details] [diff] [review]
Add a GetJNIForCompositorThread and make the compositor JNI invocations use it

This should be sufficient to fix this crash, assuming the problem is in fact the GetJNIForThread call. I can kill the GetJNIForThread() more in a separate bug.
Attachment #641598 - Flags: review?(blassey.bugs)
Comment on attachment 641598 [details] [diff] [review]
Add a GetJNIForCompositorThread and make the compositor JNI invocations use it

Review of attachment 641598 [details] [diff] [review]:
-----------------------------------------------------------------

::: widget/android/AndroidBridge.h
@@ +132,5 @@
> +    static JNIEnv* GetJNIForCompositorThread() {
> +        if (NS_LIKELY(sBridge)) {
> +            if (sBridge->mCompositorThread) {
> +                if ((void*)pthread_self() != sBridge->mCompositorThread) {
> +                    __android_log_print(ANDROID_LOG_ERROR, "AndroidBridge", "Non-compositor thread calling GetJNIForCompositorThread!");

this should probably be a NS_ABORT_IF_FALSE()

@@ +145,5 @@
> +            MutexAutoLock lock(sBridge->mCompositorJNICreationMutex);
> +
> +            if (sBridge->mCompositorThread) {
> +                // this means that another thread executed this function between the time we started executing
> +                // it and the time we acquired the mutex. fail.

this also means we have two threads that claim to be the compositor thread, which sounds like a disaster. Let's abort here too
Attachment #641598 - Flags: review?(blassey.bugs) → review+
Landed with NS_ABORT()s in the relevant places.

https://hg.mozilla.org/integration/mozilla-inbound/rev/083d36bafbc8
Backed out on suspicion of making all the android talos tests go red. Nothing useful in the log though.

https://hg.mozilla.org/integration/mozilla-inbound/rev/f3215d2dc286
(In reply to comment #27)
> Backed out on suspicion of making all the android talos tests go red. Nothing
> useful in the log though.
> 
> https://hg.mozilla.org/integration/mozilla-inbound/rev/f3215d2dc286

The backout seems to have fixed it.
Created attachment 642940 [details] [diff] [review]
patch to actually use tls
Assignee: bugmail.mozilla → blassey.bugs
Attachment #641598 - Attachment is obsolete: true
Attachment #642940 - Flags: review?(bugmail.mozilla)
Comment on attachment 642940 [details] [diff] [review]
patch to actually use tls

Review of attachment 642940 [details] [diff] [review]:
-----------------------------------------------------------------

r+ with changing the if (status < 0) to if (status) as well.
Attachment #642940 - Flags: review?(bugmail.mozilla) → review+
https://hg.mozilla.org/integration/mozilla-inbound/rev/2ee313f65ccf
Target Milestone: --- → mozilla17
https://hg.mozilla.org/mozilla-central/rev/2ee313f65ccf
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
(Reporter)

Comment 33

5 years ago
There are still crashes. See https://crash-stats.mozilla.com/report/list?version=FennecAndroid%3A17.0a1&signature=_JNIEnv%3A%3ACallVoidMethod%20|%20mozilla%3A%3AAndroidGeckoLayerClient%3A%3ASetFirstPaintViewport and https://crash-stats.mozilla.com/report/list?version=FennecAndroid%3A17.0a1&signature=JNI_CreateJavaVM%20|%20_JNIEnv%3A%3ACallVoidMethod%20|%20mozilla%3A%3AAndroidGeckoLayerClient%3A%3ASetFirstPaintViewport
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Reporter)

Comment 34

5 years ago
14.0.1 and 15.0 Beta are affected.
status-firefox14: unaffected → affected
status-firefox15: unaffected → affected
tracking-firefox15: --- → ?
tracking-firefox16: --- → ?
Version: 16 Branch → 15 Branch
(Reporter)

Comment 35

5 years ago
Let's restrict this bug to top crashers.
It's #3 top crasher in 15.0b2. The Beta regression range is:
http://hg.mozilla.org/releases/mozilla-beta/pushloghtml?fromchange=695042299ec9&tochange=166ba24e4239
Bug 760152 is the only bug that belongs to the two regression windows.
Blocks: 760152
status-firefox14: affected → ---
https://tbpl.mozilla.org/php/getParsedLog.php?id=13961381&tree=Mozilla-Beta

Updated

5 years ago
tracking-firefox15: ? → +
tracking-firefox16: ? → +
(In reply to Mike Hommey [:glandium] from comment #5)
> (In reply to Kartikaya Gupta (:kats) from comment #4)
> > CC'ing :glandium. Does bug 760152 only do library decompression earlier?
> > Does it do any other gecko startup earlier?
> 
> Gecko's actual initialization has not moved. Only decompression did.

actually, one thing moved: static initialization. Is there any static initialization that calls back into java?
https://tbpl.mozilla.org/php/getParsedLog.php?id=14003992&tree=Mozilla-Inbound
Blocks: 778954
https://tbpl.mozilla.org/php/getParsedLog.php?id=14003992&tree=Mozilla-Inbound
(In reply to Mike Hommey [:glandium] from comment #37)
> actually, one thing moved: static initialization. Is there any static
> initialization that calls back into java?

I'm not aware of any offhand, but it's quite possible that there is. Looking at the code again, I found something that might be the problem here. Patch coming in a sec.
Created attachment 647566 [details] [diff] [review]
Remove race condition from AndroidBridge initialization

Pushed this to try at https://tbpl.mozilla.org/?tree=Try&rev=b40d1422b1cb, will request review if it comes back green.
I think I'd rather we just backed out bug 760152 on branches at this point, since it didn't have any obvious perf gains. Is that riskier?
Doing the backout is probably the better option. I don't know if my patch will actually fix this or not yet. If it does we can re-land it with the fix.
(In reply to Kartikaya Gupta (:kats) from comment #43)
> Doing the backout is probably the better option. I don't know if my patch
> will actually fix this or not yet. If it does we can re-land it with the fix.

Thanks, sending over to glandium in that case.
Assignee: blassey.bugs → mh+mozilla
Comment on attachment 647566 [details] [diff] [review]
Remove race condition from AndroidBridge initialization

New try run is at https://tbpl.mozilla.org/?tree=Try&rev=e3e0e2f7ec4f (old one failed to build because i used a busted inbound changeset as a base). It looks about as green as android usually does, so requesting review.
Attachment #647566 - Flags: review?(snorp)
Attachment #647566 - Flags: review?(snorp) → review+
https://hg.mozilla.org/integration/mozilla-inbound/rev/87736e458d15
Attachment #642940 - Flags: checkin+
Attachment #647566 - Flags: checkin+
https://hg.mozilla.org/mozilla-central/rev/87736e458d15
Status: REOPENED → RESOLVED
Last Resolved: 5 years ago5 years ago
Resolution: --- → FIXED
(Reporter)

Comment 48

5 years ago
Fixed in Aurora by the backout of bug 760152:
http://hg.mozilla.org/releases/mozilla-aurora/rev/e670dfc55dc8
status-firefox16: affected → fixed
(Reporter)

Comment 49

5 years ago
There are still crashes in the trunk.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(In reply to Scoobidiver from comment #49)
> There are still crashes in the trunk.

Do you have evidence of that? There are no crashes I can see with a build id from a build after the landing:
https://crash-stats.mozilla.com/report/list?range_value=7&range_unit=days&date=2012-08-02&signature=_JNIEnv%3A%3ACallVoidMethod%20|%20mozilla%3A%3AAndroidGeckoLayerClient%3A%3ASetFirstPaintViewport&version=FennecAndroid%3A17.0a1
(Reporter)

Comment 51

5 years ago
(In reply to Mike Hommey [:glandium] from comment #50)
> Do you have evidence of that?
Of course: https://crash-stats.mozilla.com/query/query?product=FennecAndroid&version=FennecAndroid%3A17.0a1&range_value=1&range_unit=weeks&query_search=signature&query_type=contains&query=mozilla%3A%3AAndroidGeckoLayerClient%3A%3ASetFirstPaintViewport&reason=&do_query=1
(Reporter)

Comment 52

5 years ago
There are no crashes after 16.0a2/20120801, i.e. the backout of bug 760152.
status-firefox16: fixed → verified
Crash on 8/3
https://crash-stats.mozilla.com/report/index/0e11bda2-b749-4f1f-944b-7430f2120806
https://crash-stats.mozilla.com/report/index/1fd05d7b-0f24-4063-9a84-ee7782120806
https://crash-stats.mozilla.com/report/index/e4673839-1a8f-4f07-ab22-956902120806

Note to clarify.. that's only 3 report that shows on/after 8/1 out of 2,838+634+1 Crash Reports.  Only 1 report after 8/1.

Should we close this out?  Or keep this and mark as a lower priority?  People just need to update it seems.
(Reporter)

Comment 55

5 years ago
(In reply to Naoki Hirata :nhirata from comment #54)
> Should we close this out?  Or keep this and mark as a lower priority? 
No. When 17 Branch will go to Aurora, it will be #3 top crasher in 17.0a2 like it was in 16.0a2.
https://tbpl.mozilla.org/php/getParsedLog.php?id=14195251&tree=Mozilla-Inbound
Bug 760152 was backed out of Beta 15 yesterday.
(Reporter)

Updated

5 years ago
status-firefox15: affected → fixed
https://tbpl.mozilla.org/php/getParsedLog.php?id=14198783&tree=Mozilla-Inbound
https://tbpl.mozilla.org/php/getParsedLog.php?id=14196700&tree=Mozilla-Inbound
https://tbpl.mozilla.org/php/getParsedLog.php?id=14196485&tree=Mozilla-Inbound
https://tbpl.mozilla.org/php/getParsedLog.php?id=14200983&tree=Mozilla-Inbound
https://tbpl.mozilla.org/php/getParsedLog.php?id=14206103&tree=Mozilla-Inbound
https://tbpl.mozilla.org/php/getParsedLog.php?id=14216916&tree=Mozilla-Inbound
(In reply to Naoki Hirata :nhirata from comment #54)
> Should we close this out?  Or keep this and mark as a lower priority? 
> People just need to update it seems.

No. This is still occurring on trunk.
https://tbpl.mozilla.org/php/getParsedLog.php?id=14220243&tree=Mozilla-Inbound
https://tbpl.mozilla.org/php/getParsedLog.php?id=14223602&tree=Mozilla-Inbound
status-firefox17: --- → affected
https://tbpl.mozilla.org/php/getParsedLog.php?id=14233827&tree=Mozilla-Inbound
https://tbpl.mozilla.org/php/getParsedLog.php?id=14236155&tree=Mozilla-Inbound
https://tbpl.mozilla.org/php/getParsedLog.php?id=14236751&tree=Mozilla-Inbound
https://tbpl.mozilla.org/php/getParsedLog.php?id=14239805&tree=Mozilla-Inbound
https://tbpl.mozilla.org/php/getParsedLog.php?id=14247039&tree=Mozilla-Inbound
https://tbpl.mozilla.org/php/getParsedLog.php?id=14234586&tree=Services-Central
https://tbpl.mozilla.org/php/getParsedLog.php?id=14255283&tree=Mozilla-Inbound
Assigning to kats after speaking to glandium.
Assignee: mh+mozilla → bugmail.mozilla
https://tbpl.mozilla.org/php/getParsedLog.php?id=14256436&tree=Firefox
https://tbpl.mozilla.org/php/getParsedLog.php?id=14257033&tree=Mozilla-Inbound
https://tbpl.mozilla.org/php/getParsedLog.php?id=14257721&tree=Mozilla-Inbound
It looks like all of the recent logs are from mochitest runs -- why would that be?
https://tbpl.mozilla.org/php/getParsedLog.php?id=14262419&tree=Mozilla-Inbound
https://tbpl.mozilla.org/php/getParsedLog.php?id=14262377&tree=Mozilla-Inbound
https://tbpl.mozilla.org/php/getParsedLog.php?id=14263452&tree=Mozilla-Inbound
https://tbpl.mozilla.org/php/getParsedLog.php?id=14276541&tree=Mozilla-Inbound
https://tbpl.mozilla.org/php/getParsedLog.php?id=14280678&tree=Firefox
https://tbpl.mozilla.org/php/getParsedLog.php?id=14287661&tree=Firefox
https://tbpl.mozilla.org/php/getParsedLog.php?id=14287387&tree=Mozilla-Inbound
https://tbpl.mozilla.org/php/getParsedLog.php?id=14287593&tree=Mozilla-Inbound
https://tbpl.mozilla.org/php/getParsedLog.php?id=14292095&tree=Mozilla-Inbound
https://tbpl.mozilla.org/php/getParsedLog.php?id=14292084&tree=Mozilla-Inbound
https://tbpl.mozilla.org/php/getParsedLog.php?id=14287818&tree=Mozilla-Inbound
https://tbpl.mozilla.org/php/getParsedLog.php?id=14293607&tree=Mozilla-Inbound
https://tbpl.mozilla.org/php/getParsedLog.php?id=14297906&tree=Mozilla-Inbound
https://tbpl.mozilla.org/php/getParsedLog.php?id=14308165&tree=Ionmonkey
https://tbpl.mozilla.org/php/getParsedLog.php?id=14318134&tree=Mozilla-Inbound
https://tbpl.mozilla.org/php/getParsedLog.php?id=14324223&tree=Firefox
https://tbpl.mozilla.org/php/getParsedLog.php?id=14327702&tree=Try
https://tbpl.mozilla.org/php/getParsedLog.php?id=14330324&tree=Mozilla-Inbound
https://tbpl.mozilla.org/php/getParsedLog.php?id=14331823&tree=Mozilla-Inbound
https://tbpl.mozilla.org/php/getParsedLog.php?id=14332284&tree=Mozilla-Inbound
https://tbpl.mozilla.org/php/getParsedLog.php?id=14337705&tree=Mozilla-Inbound
https://tbpl.mozilla.org/php/getParsedLog.php?id=14346280&tree=Build-System
https://tbpl.mozilla.org/php/getParsedLog.php?id=14347355&tree=Firefox
Kats, do you have any ideas for this?
Unfortunately, no. I've looked through the code multiple times and don't see any other problems that could cause this.
https://tbpl.mozilla.org/php/getParsedLog.php?id=14340005&tree=Ionmonkey
https://tbpl.mozilla.org/php/getParsedLog.php?id=14359828&tree=Mozilla-Inbound
https://tbpl.mozilla.org/php/getParsedLog.php?id=14361228&tree=Mozilla-Inbound
https://tbpl.mozilla.org/php/getParsedLog.php?id=14361928&tree=Fx-Team
https://tbpl.mozilla.org/php/getParsedLog.php?id=14361872&tree=Fx-Team
https://tbpl.mozilla.org/php/getParsedLog.php?id=14365222&tree=Mozilla-Inbound
https://tbpl.mozilla.org/php/getParsedLog.php?id=14369939&tree=Mozilla-Inbound
(In reply to Ed Morley [:edmorley] from comment #101)
> Kats, do you have any ideas for this?

Actually, we should back out bug 760152 on 17 as well. Backing that out seems to have fixed the error completely on 15 and 16, so it should help significantly on 17. Note that this error was happening even before bug 760152 landed (albeit at a very low crash volume) so I don't expect it to disappear completely, unless one of the other patches on this bug did actually fix something. (i.e. bug 760152 might have masked the original problem, which was fixed by one of the patches on this bug).

I posted a comment on bug 760152 requesting it be backed out on 17 as well.
Thank you :-)
https://tbpl.mozilla.org/php/getParsedLog.php?id=14392746&tree=Mozilla-Inbound
https://tbpl.mozilla.org/php/getParsedLog.php?id=14396667&tree=Fx-Team
https://tbpl.mozilla.org/php/getParsedLog.php?id=14405469&tree=Firefox
https://tbpl.mozilla.org/php/getParsedLog.php?id=14388556&tree=Try
https://tbpl.mozilla.org/php/getParsedLog.php?id=14415209&tree=Mozilla-Inbound
https://tbpl.mozilla.org/php/getParsedLog.php?id=14417380&tree=Mozilla-Inbound
https://tbpl.mozilla.org/php/getParsedLog.php?id=14416658&tree=Mozilla-Inbound
https://tbpl.mozilla.org/php/getParsedLog.php?id=14419680&tree=Mozilla-Inbound
https://tbpl.mozilla.org/php/getParsedLog.php?id=14421092&tree=Mozilla-Inbound
I pushed the backout of bug 760152 to inbound so hopefully this should stop happening as that propagates to the various trees. *fingers crossed*
https://tbpl.mozilla.org/php/getParsedLog.php?id=14423258&tree=Mozilla-Inbound (from before)
https://tbpl.mozilla.org/php/getParsedLog.php?id=14421893&tree=Firefox
https://tbpl.mozilla.org/php/getParsedLog.php?id=14430775&tree=Fx-Team
https://tbpl.mozilla.org/php/getParsedLog.php?id=14429953&tree=Ionmonkey
(Reporter)

Updated

5 years ago
status-firefox17: affected → fixed

Comment 126

5 years ago
This has stopped after the build from the 16th, so the backout worked. Should we mark this bug fixed?
Sounds good to me.
Status: REOPENED → RESOLVED
Last Resolved: 5 years ago5 years ago
Resolution: --- → FIXED
Keywords: intermittent-failure
Whiteboard: [native-crash][startupcrash][orange] → [native-crash][startupcrash]
tracking-fennec: ? → ---
You need to log in before you can comment on or make changes to this bug.