Mozilla/5.0 (Windows; U; Windows NT 6.0; rv:1.9.1b3pre) Gecko/20081127 SeaMonkey/2.0a2pre Adblock Plus 0.7.5.5 STR: 1) Install adblock plus with filter list, it doesn't crash without 2) Open URL 3) a 100% crash bp-fed9fed6-72f8-4341-a7ea-b6dff2081127 bp-0777843b-d2e9-427d-9ac3-479bf2081127 0 js3250.dll nanojit::LirBufWriter::insLink js/src/nanojit/LIR.cpp:423 1 js3250.dll nanojit::LirBufWriter::ensureReferenceable js/src/nanojit/LIR.cpp:252 2 js3250.dll nanojit::LirBufWriter::ins2 js/src/nanojit/LIR.cpp:329 3 js3250.dll nanojit::CseFilter::insLoad js/src/nanojit/LIR.cpp:1956 4 js3250.dll js3250.dll@0xac773
Confirmed in Minefield build 20081123 on Windows XP (using Adblock Plus 1.0 release candidate): bp-bf6cff00-2f8b-4e9d-8e14-0a3f62081128 bp-ad787bd9-6d78-40da-b233-eea262081128
Managed to minimize that page, more or less. I didn't dig into jQuery but the crash also happens with the standard jQuery version that I linked from the testcase. If your browser didn't crash you might need to refresh a few times.
On the Adblock Plus side minimizing is more difficult - removing filter matching "fixes" the crash which makes pretty little sense because that's the one part that doesn't interact with the web page in any way (also, it had major changes between Adblock Plus 0.7.5.5 and 1.0).
I don't know if it matters but the stack in bp-ad787bd9-6d78-40da-b233-eea262081128 is a little bit different.
If you put "TM:" in the title for JIT crashes I can find them easier.
Summary: 100% Crash with Adblock Plus 0.7.5.5 on specific URL [@ nanojit::LirBufWriter::insLink(nanojit::LOpcode, nanojit::LIns*) ] → TM: 100% Crash with Adblock Plus 0.7.5.5 on specific URL [@ nanojit::LirBufWriter::insLink(nanojit::LOpcode, nanojit::LIns*) ]
I have seen this in the top crashes too. The test case looks promising. I will try to reproduce.
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b3pre) Gecko/20081130 SeaMonkey/2.0a2pre - Build ID: 20081130000511 Crash immediately after opening the "details" view of the testcase (and Breakpad told me it "had a problem" transmitting my crash data). I believe bug 460272 is a dupe of this one.
OS: Windows Vista → All
Hardware: PC → All
Duplicate of this bug: 460272
I can reproduce this, will debug.
Assignee: general → danderson
We're re-entering the interpreter via a resolve hook which causes a deep abort. This is really nasty since it means the recorder continues with complete garbage. Jason is working on a larger solution to this problem in bug 462027. Attached patch is a quick fix in case something is needed right away.
11 years ago
Assignee: danderson → general
Depends on: deepbail
Pushed changeset http://hg.mozilla.org/tracemonkey/rev/213728a95a5c This is a really common crash that can produce wildly varying stack traces, so it's probably best to get the quick fix in early. Once the general fix is available this patch can be stripped out.
Assignee: general → danderson
Status: NEW → ASSIGNED
Version: unspecified → 1.9.1 Branch
I just tried it with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20081201 Minefield/3.1b3pre ID:20081201035224 and it didn't trigger a crash. For the record, I also have NoScript installed, and didn't allow whatever was trying to run, so it was likely a script.
This got merged to m-c
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
bp-5922a9dd-e10e-4572-8f24-1f3252081211 bp-97ce37cb-7c9c-43c7-b6fd-b34342081211 Crash with above testcase and Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a1pre) Gecko/20081211 Minefield/3.2a1pre, with ABP 1
sure, because your build doesn't contain the fix because it got merged into m-c 2 hours ago. As we have a fix we don't need more information that it crashes, where it crashes and why it crashes because if we have a fix, the cause of this has been identified by the developers. You should of course reopen this bug if you get this with a build that should contain this fix.
Sorry matti, need to check the build info. Does not crash with todays trunk
Status: RESOLVED → VERIFIED
This is a top crasher for Firefox 3.1 Beta 2. Robert, has the patch already been landed on mozilla1.9.1 branch? I ask because I'm not able to get the latest branch nightly to crash on the given URL (as comment 14 also pointed out).
Target Milestone: --- → mozilla1.9.2a1
I just crashed Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081212 Shiretoko/3.1b3pre, supposed to be built after checkin, on http://quicksilver.en.softonic.com/mac
Thanks Daniel. I'm also able to reproduce the crash with the latest 1.9.1b3pre. Slightly updating the URL to a crashing one. I think it need some baking on trunk until it will be checked into 1.9.1 branch?
We should land this on 1.9.1 as soon as we know it doesn't regress performance or break builds. It's a blocker, and a crasher, so sooner is better.
Not sure if it matters here, but Adblock Plus is on a new version, 1.0.
No, it doesn't matter - see comment 1.
anyone spot regressions? is it time to move that patch to the branch?
Verified fixed on 1.9.1 with the given URL and testcase: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081221 Shiretoko/3.1b3pre ID:20081221020430 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20081222 Shiretoko/3.1b3pre ID:20081222041930 No more crash reports listed for Firefox3.1b3 after the 2008121900 build.
Crash Signature: [@ nanojit::LirBufWriter::insLink(nanojit::LOpcode, nanojit::LIns*) ]
You need to log in before you can comment on or make changes to this bug.