Closed Bug 467007 Opened 16 years ago Closed 15 years ago

TM: 100% Crash with Adblock Plus on specific URL [@ nanojit::LirBufWriter::insLink(nanojit::LOpcode, nanojit::LIns*) ]


(Core :: JavaScript Engine, defect)

1.9.1 Branch
Not set





(Reporter: Matti, Assigned: dvander)




(Keywords: crash, topcrash, verified1.9.1)

Crash Data


(2 files, 1 obsolete file)

Mozilla/5.0 (Windows; U; Windows NT 6.0; rv:1.9.1b3pre) Gecko/20081127 SeaMonkey/2.0a2pre
Adblock Plus

1) Install adblock plus with filter list, it doesn't crash without
2) Open URL
3) a 100% crash


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
Flags: blocking1.9.1?
Confirmed in Minefield build 20081123 on Windows XP (using Adblock Plus 1.0 release candidate):

Attached file Testcase
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 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 on specific URL [@ nanojit::LirBufWriter::insLink(nanojit::LOpcode, nanojit::LIns*) ] → TM: 100% Crash with Adblock Plus 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
I can reproduce this, will debug.
Assignee: general → danderson
Attached patch quick fix (obsolete) — Splinter Review
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.
Assignee: danderson → general
Depends on: deepbail
Attached patch quick fix, v2Splinter Review
Attachment #350837 - Attachment is obsolete: true
Attachment #350842 - Flags: review?(gal)
Attachment #350842 - Flags: review?(gal) → review+
Pushed changeset

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.
Flags: blocking1.9.1? → blocking1.9.1+
Blocks: abp
Assignee: general → danderson
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
Closed: 15 years ago
Resolution: --- → FIXED
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
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).
Keywords: topcrash
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
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.
Flags: in-testsuite-
Flags: in-litmus-
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.