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

Status: VERIFIED FIXED

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

Description

[Uri Bernstein]

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

Comment 1

[Boris Zbarsky [:bzbarsky]]

Attachment: Fix

Comment 2

[Dennis Jacobfeuerborn]

*** Bug 336424 has been marked as a duplicate of this bug. ***

Comment 3

[Ben Goodger (use ben at mozilla dot org for email)]

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!

Comment 4

[Ben Goodger (use ben at mozilla dot org for email)]

Marking blocking-1.8.1, as long as this is in the critical path for feed handling

Comment 5

[Johnny Stenback (:jst)]

Comment on attachment 220656 [details] [diff] [review]
Fix

sr=jst

Comment 6

[walter]

(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'?

Comment 7

[Ria Klaassen (not reading all bugmail)]

*** Bug 336388 has been marked as a duplicate of this bug. ***

Comment 8

[Boris Zbarsky [:bzbarsky]]

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.

Comment 9

[Boris Zbarsky [:bzbarsky]]

*** Bug 336480 has been marked as a duplicate of this bug. ***

Comment 10

[Thomas Bertels]

(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 11

[Daniel Veditz [:dveditz]]

Comment on attachment 220656 [details] [diff] [review]
Fix

r=dveditz

Comment 12

[Ben Goodger (use ben at mozilla dot org for email)]

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. 

Comment 13

[:Gavin Sharp [email: [e-mail]]]

*** Bug 336529 has been marked as a duplicate of this bug. ***

Comment 14

[Boris Zbarsky [:bzbarsky]]

Fixed.

Comment 15

[Peter van der Woude [:Peter6]]

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

Comment 16

[Stephen Donner [:stephend] Not actively reading bugmail]

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 '___'"

Comment 17

[Tracy Walker [:tracy]]

adding topcrash keyword for historical purposes

Comment 18

[Darin Fisher]

Any plans to land this on the 1.8 branch?  If so, please act fast; time is running out.

Comment 19

[Mike Schroepfer]

JST - can you craft/land a branch patch?

Comment 20

[Daniel Veditz [:dveditz]]

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.

Comment 21

[Boris Zbarsky [:bzbarsky]]

Yeah, this is absolutely trunk-only.