Closed Bug 336432 Opened 19 years ago Closed 19 years ago

[FIX]Crash [@ nsScriptSecurityManager::SecurityCompareURIs] with Adblock Plus on haaretz.co.il

Categories

(Core :: Security: CAPS, defect, P1)

defect

Tracking

()

VERIFIED FIXED
mozilla1.9alpha1

People

(Reporter: uriber, Assigned: bzbarsky)

References

()

Details

(Keywords: crash, regression, topcrash)

Crash Data

Attachments

(1 file)

When Adblock Plus 0.7 is installed and enabled, I crash immediately when visiting the front page on Haaretz.

This regressed between 2006-05-02 and 2006-05-03. Based on the stacktrace (see below), I'm guessing this is a regression from bug 334407.

Steps to reproduce:
1. Install Adblock plus 0.7 from http://adblockplus.mozdev.org/installation.html
2. Visit http://www.haaretz.co.il/?from=hasot

Note that there's no need to define any filters in order to crash, but adblock must be enabled and active.

The Talkback reports I got are all blank/junk (which might be a separate bug): TB18248627M, TB18249515E.
Here's the top of the Problem Report I'm getting from OS X:

Date/Time:      2006-05-03 17:37:56.975 +0300
OS Version:     10.4.6 (Build 8I127)
Report Version: 4

Command: firefox-bin
Path:    /Users/urib/Desktop/Minefield 2006-05-03 copy.app/Contents/MacOS/firefox-bin
Parent:  launchd [1]

Version: 3.0a1 (3.0a1)

PID:    7816
Thread: 0

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at 0x00000000

Thread 0 Crashed:
0   org.mozilla.firefox      	0x00429ab0 nsScriptSecurityManager::SecurityCompareURIs(nsIURI*, nsIURI*, int*) + 112
1   org.mozilla.firefox      	0x0042b1dc nsScriptSecurityManager::CheckSameOriginPrincipalInternal(nsIPrincipal*, nsIPrincipal*, int) + 312
2   org.mozilla.firefox      	0x00293e24 nsGlobalWindow::SetTimeoutOrInterval(int, int*) + 1412
3   org.mozilla.firefox      	0x002938e4 nsGlobalWindow::SetTimeoutOrInterval(int, int*) + 68
4   libxpcom_core.dylib      	0x2c05447c _XPTC_InvokeByIndex + 216
5   org.mozilla.firefox      	0x00498c7c XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode) + 2524
6   org.mozilla.firefox      	0x0048bf98 XPC_WN_CallMethod(JSContext*, JSObject*, unsigned, long*, long*) + 220
7   libmozjs.dylib           	0x2302db20 js_Invoke + 1832
8   libmozjs.dylib           	0x23037994 js_Interpret + 35728
9   libmozjs.dylib           	0x2302db64 js_Invoke + 1900
Blocks: 326506
Assignee: dveditz → bzbarsky
OS: Mac OS X 10.4 → All
Priority: -- → P1
Hardware: Macintosh → All
Summary: Crash [@ nsScriptSecurityManager::SecurityCompareURIs] with Adblock Plus on haaretz.co.il → [FIX]Crash [@ nsScriptSecurityManager::SecurityCompareURIs] with Adblock Plus on haaretz.co.il
Target Milestone: --- → mozilla1.9alpha
Attached patch FixSplinter Review
Attachment #220656 - Flags: superreview?(jst)
Attachment #220656 - Flags: review?(dveditz)
*** Bug 336424 has been marked as a duplicate of this bug. ***
fyi: I also see this with my feed handling changes, on Mac and Linux only (strangely) when transitioning from my preview page (loaded from XUL from a jar) to a web handler. It would be great if we could get this fix on the branch before Friday!
Marking blocking-1.8.1, as long as this is in the critical path for feed handling
Flags: blocking1.8.1+
Comment on attachment 220656 [details] [diff] [review]
Fix

sr=jst
Attachment #220656 - Flags: superreview?(jst) → superreview+
Keywords: crash
(In reply to comment #1)
> Created an attachment (id=220656) [edit]
> Fix
FWIW, this bug also crashed today's thunderbird trunk, and 
your patch fixes it, thanks.  I submitted a Talkback report
before I saw this fix, so I hope no one spends any time on
it.  Is there a way for me to follow up on a Talkback report,
i.e. report it as 'already fixed'?

*** Bug 336388 has been marked as a duplicate of this bug. ***
Blocks: 329889
Ben, whatever you see on 1.8 branch is not this bug.  This bug is a trunk-only regression from a trunk-only checkin (bug 334407).  If you're hitting this code on the branch somehow, I'd dearly like to know how; please file a separate bug with steps to reproduce in a branch build?

Thomas, I don't know why you added bug 329889 to the dependency list.  It doesn't look related to this bug, so I'm removing it.

Walter, talkbacks are used for two things.  If you report a bug and cite a talkback incident ID it's used to look up the stack.  And the most-often-occuring stacks are looked into.  So one-off reports that no one follows up on are generally just sorta there.
No longer blocks: 329889
*** Bug 336480 has been marked as a duplicate of this bug. ***
(In reply to comment #8)

It was because bug 329889 depended on bug 336480 (see bug details).
But according to
> This is a very recent crash although this sounds familiar (crashed before when
> using this filter).
> Regression between 1.9a1_2006050209 and 1.9a1_2006050214.
> http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=2006-05-02+08%3A00&maxdate=2006-05-02+14%3A00
and the talkback report, there are more chances for it to be caused by bug 334407 checkin.
Comment on attachment 220656 [details] [diff] [review]
Fix

r=dveditz
Attachment #220656 - Flags: review?(dveditz) → review+
bz: I have not verified the feed parsing code on the branch yet due to lack of the xml stuff. I was using a trunk build. I'm pleased to hear that this is trunk only. I'll verify later this evening. Thanks for the info! This is still a blocker for getting the feed stuff turned on on the trunk, which I'd like to do before turning it on on the branch. 
*** Bug 336529 has been marked as a duplicate of this bug. ***
Fixed.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060503 Minefield/3.0a1 ID:2006050320 [cairo]

verified, all the horrible crashes from extensions have gone

tnx Boris
The crash is verified FIXED for me too with build 2006-05-03-21 of SeaMonkey trunk under Windows XP.  The additional testcase I used was to select some text, right-click it, and choose "Search Web for '___'"
Status: RESOLVED → VERIFIED
adding topcrash keyword for historical purposes
Keywords: topcrash
Any plans to land this on the 1.8 branch?  If so, please act fast; time is running out.
JST - can you craft/land a branch patch?
sending back for 1.8.1 triage, from all appearances (e.g. comment 8) this is a trunk-only regression that isn't wanted on the 1.8 branch.
Flags: blocking1.8.1+ → blocking1.8.1?
Yeah, this is absolutely trunk-only.
Flags: blocking1.8.1?
Crash Signature: [@ nsScriptSecurityManager::SecurityCompareURIs]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: