Closed Bug 1192532 Opened 4 years ago Closed 4 years ago

With august 8, 2015 nightly, google plus main page cannot be fully loaded. Refreshing leads to a crash in void DoMarking<T>(js::GCMarker*, js::jit::JitCode*)

Categories

(Core :: JavaScript: GC, defect)

x86_64
Linux
defect
Not set

Tracking

()

RESOLVED DUPLICATE of bug 1193541
Tracking Status
firefox42 --- affected

People

(Reporter: fredbezies, Unassigned)

References

()

Details

(Keywords: crash)

Attachments

(1 file)

I noticed this "crashy" behavior on august 8, 2015 nightly. I was trying to load my main google plus main page. It wasn't fully loaded. I try to refresh 4 or 5 times, then nightly crashed.

Crash ID: bp-e6b6f949-b56a-46d9-b823-428952150808

I cleaned up my profile before getting this crash to be sure it wasn't related to any 3rd party extension.

I'm pretty sure this crash do not happened with older nightlies. I will try and report.
Summary: With august 8, 2015 nightly, google plus main page cannot be fully loaded. Refreshing leads to a crash → With august 8, 2015 nightly, google plus main page cannot be fully loaded. Refreshing leads to a crash in void DoMarking<T>(js::GCMarker*, js::jit::JitCode*)
Keywords: crash
Tried yesterday (august 7) nightly ? Cannot reproduce the crash.

https://hg.mozilla.org/mozilla-central/rev/91de9c670800 -> August 7, OK
https://hg.mozilla.org/mozilla-central/rev/943b79d9c65f -> August 8, busted.

Tried again with today (august 8) nightly : another crash, ID : bp-bdadbc65-8706-4bfd-81b6-f66812150808

Last time js/src/vm/Runtime.h was modified (it is the first "file" listed in crash reports), it was with this commit : http://hg.mozilla.org/mozilla-central/annotate/943b79d9c65f/js/src/vm/Runtime.h#l1029

Just guessing, of course !
Comment on attachment 8645773 [details]
Screenshot of the google plus page

I use noscript but every script on the page is activated. So NoScript don't change nothing in this case.
Looks like I have a regression window :

Last working build : https://hg.mozilla.org/mozilla-central/rev/91de9c670800 => Fri, 07 Aug 2015 11:52:29 +0200
First broken build : https://hg.mozilla.org/mozilla-central/rev/3e51753a099f => Fri, 07 Aug 2015 13:13:06 +0200

Or, these two builds are just one after another in tinderbox tree.

Really weird :(
Here is the commit list between these two builds :

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=91de9c670800&tochange=3e51753a099f

There is a lot of it. Any idea ?!
A really not educated guess : could it be either bug 1181392 or bug 1180125 ?
Frederic, thanks for the report. Can you still reproduce this with the latest Nightlies?
Component: JavaScript Engine: JIT → JavaScript: GC
Flags: needinfo?(fredbezies)
If you have the time and patience, it'd be great if you could use mozregression to bisect :) It will also test the inbound builds, so we can hopefully narrow it down to a single (or a few) commit(s).

http://mozilla.github.io/mozregression/
I have a "brother" bug like this one reported here. https://bugzilla.mozilla.org/show_bug.cgi?id=1192785

Copying / paste last comment I made :

Using mozregression :

mozregression --good 2015-08-06 --bad 2015-08-08

MainThread Bisector INFO Narrowed nightly regression window from [2015-08-06, 2015-08-08] (2 days) to [2015-08-07, 2015-08-08] (1 days) (~0 steps left)

Inbounds :

Last good revision: 91de9c670800
First bad revision: 943b79d9c65f

Getting inbound builds between 32712cd01159 and 943b79d9c65f

But I cannot reproduce the bug with any of these inbound builds :(

By the way, *I have to block* any update since august 7 nightly build. I'm kinda "fed up" with this bug.
Flags: needinfo?(fredbezies)
(In reply to Frederic Bezies from comment #9)
> By the way, *I have to block* any update since august 7 nightly build. I'm
> kinda "fed up" with this bug.

I understand your frustration. Thanks for the reports.

Hm your first report has ICStub::trace on the stack, that could be bug 1192988.
Blocks: 1192988
Flags: needinfo?(terrence)
Just an educated guess. In my first bug report, I can see that bug 1149352, part 6 is listed as the last modification for js/src/jit/SharedIC.cpp in line 129.

In the second crash report, again for js/src/vm/ObjectGroup.cpp in line 1473, this time is bug 1149352 but in part 5.

Is it the culprit or not ?
But it will be strange as this bugfix was commit back in april 2015.
I'd guess that this is a dupe of bug 1191465. Bug 1181908, which caused it, is in the regression range in comment 4.
See Also: → 1192785
(In reply to Andrew McCreight [:mccr8] from comment #13)
> I'd guess that this is a dupe of bug 1191465. Bug 1181908, which caused it,
> is in the regression range in comment 4.

I opened also bug 1192785.

I'll try to apply revert patch from but 1181908 to see if it fix this bug.
Well, reverting patch for bug 1181908 nailed this bug down. Not perfectly, but at least, my google plus main is loading nearly completely ! :)
(In reply to Frederic Bezies from comment #15)
> Well, reverting patch for bug 1181908 nailed this bug down. Not perfectly,
> but at least, my google plus main is loading nearly completely ! :)

Please ignore this comment. It did nothing :(

Looks like I did not closed my previous firefox session :(
There is still bad behavior on all Google website with the latest Nightly (20150813030208): need to reload several times pages like Google Plus, Google Search, Google Drive otherwise they get loaded only partly. Also, it's nearly impossible to perform any file transfer from/to Google Drive: upload constantly fails and needs to be restarted from the beginning. Download also fails so to transfer completely a file you have to retry it dozen of times depending on the file size.
(In reply to Alexandre LISSY :gerard-majax from comment #17)
> There is still bad behavior on all Google website with the latest Nightly
> (20150813030208): need to reload several times pages like Google Plus,
> Google Search, Google Drive otherwise they get loaded only partly. Also,
> it's nearly impossible to perform any file transfer from/to Google Drive:
> upload constantly fails and needs to be restarted from the beginning.
> Download also fails so to transfer completely a file you have to retry it
> dozen of times depending on the file size.

This sounds like bug 1193796 (which got duped to bug 1193541). The Nightly you reported with is from the same day that the regressing patch was backed out, so I think the next Nightly should behave better.
Is the problem fixed on recent nightlies?
Flags: needinfo?(fredbezies)
I think so. I am on the latest nightly and everything is back to normal again. I think the offending code was backed out (Bug 1193541). Not sure of the ETA of the functioning code.
I can confirm everything it going right now.
Flags: needinfo?(fredbezies)
\o/

Great! I'll go ahead and close this bug, then.
Status: NEW → RESOLVED
Closed: 4 years ago
Flags: needinfo?(terrence)
Resolution: --- → DUPLICATE
Duplicate of bug: 1193541
You need to log in before you can comment on or make changes to this bug.