610119 - Crash [@ XPCWrappedNative::HasInterfaceNoQI ] [@ unmarkPurple]

Status: RESOLVED WORKSFORME

(Core :: General, defect)

Description

[Pablo Rodríguez]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.12) Gecko/20101027 Fedora/3.6.12-1.fc13 Firefox/3.6.12
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.12) Gecko/20101027 Fedora/3.6.12-1.fc13 Firefox/3.6.12

I was surfing the web and I experienced a crash when opening the links from http://gallir.wordpress.com at http://ciberderechos.barrapunto.com/ciberderechos/10/11/06/0918214.shtml in a background tab (backtrace attached at first crash).

I use Adblock Plus and HTTPS Everywhere, among others. HTTPS Everywhere redirects wordpress.com from HTTP to HTTPS. Just in case it helps, crash happened after redirection, already rendering the page.

The second crash happened when I tried to opening those links in the background in private mode (backtrace attached as second crash).

I opened a bug report, using firefox in private mode, and both pages from https://gallir.wordpress.com were loaded fine, but when I clicked on the blog title to go to the blog main page, firefox crashed again when it was rendering the page (backtrace attached as third crash).

And opening again a bug report and clicking on a link from barrapunto.com that pointed to http://ciberderechos.barrapunto.com/ciberderechos/10/11/06/0918214.shtml (if I'm not wrong) crashed firefox for the fourth time (backtrace attached as fourth crash).

Well, would you be so kind to fix these crashes? (I guess the bug might be the same.)

Many thanks for your help,


Pablo

Reproducible: Sometimes

Comment 1

[Pablo Rodríguez]

Attachment: First crash

Comment 2

[Pablo Rodríguez]

Attachment: Second crash

Comment 3

[Pablo Rodríguez]

Attachment: Third crash

Comment 4

[Pablo Rodríguez]

Attachment: Fourth crash

Comment 5

[Mats Palmgren (inactive)]

The "HTTPS Everywhere" extension has problems, see bug 548102.
Does the problem go away if you disable it? (and restart Fx)

Comment 6

[Pablo Rodríguez]

Thanks for your reply, Mats.

I don't actually know if the problems goes away, since it doesn't happen all the time.

If I have a new crash, I'll report it here.

Thanks again,

Pablo

Comment 7

[Pablo Rodríguez]

Attachment: Crash with HTTPS-Everywhere disabled

I disabled HTTPS-Everywhere and visiting http://www.frkncngz.com/, I clicked on the Shuffle button on the top bar (that links to http://frkncngz.com/random) and firefox crashed. Backtrace attached.

Would you be so kind to check this?

Thanks,


Pablo

Comment 8

[timeless]

please don't use thread apply all bt. rather, feel free to save such a log, but don't attach it unless asked.

it wastes a lot of space and makes it much harder to find the part that actually matters which is here:

#2  0x0241aa61 in nsProfileLock::FatalSignalHandler (signo=11, info=
    0xbfa61e7c, context=0xbfa61efc) at nsProfileLock.cpp:213
        unblock_sigs = {__val = {1024, 0 <repeats 31 times>}}
        oldact = <value optimized out>
#3  <signal handler called>
No symbol table info available.
#4  0x02882491 in unmarkPurple (this=0x3758ec0, s=0x8b0e7b60)
    at ../../dist/include/nsISupportsImpl.h:214
        refcount = Cannot access memory at address 0x4

It's totally unhelpful since you have only one useful frame (#4).

Basically, at best it says "we were doing GC/CC work and ran across something which was probably a null pointer at an unexpected point", precisely how we got there is lost because there's no frame #5.

It doesn't match your other random stacks, but we do have general bugs for GC/CC not being perfect...

Comment 9

[Mats Palmgren (inactive)]

I can reproduce the crash quite easily by clicking the "shuffle" link
at the URL.  It crashes after 5 clicks or so.  This profile has a few
extensions, Adblock Plus being one of them.
bp-2f1a72b5-0088-489c-a3a3-831122101107
bp-61cf93da-c427-4f7c-874c-3352d2101107

Comment 10

[Mats Palmgren (inactive)]

I can reproduce the crash with Firebug (1.5.4) only, but it's a lot
harder to reproduce.  Adding Adblock Plus (1.2.2) makes it easier
to reproduce.  I can't reproduce it with just Adblock Plus.

Comment 11

[Mats Palmgren (inactive)]

Possibly related to bug 606316?

Comment 12

[Pablo Rodríguez]

(In reply to comment #8)
> please don't use thread apply all bt. rather, feel free to save such a log, but
> don't attach it unless asked.

Thanks for your help and sorry for attaching all the backtrace.

> it wastes a lot of space and makes it much harder to find the part that
> actually matters which is here:

I'm an average user, I don't code and I don't know what might be relevant.

Should I only attach the first thread? (Consider that the log it's almost Greek to me.)

Thanks again for your help,

Pablo

Comment 13

[timeless]

the debugger will automatically select the crashed thread, it may or may not be the first thread. simply using 'bt' without talking about 'thread...' will do the right thing (tm) in almost all cases (excluding deadlock, aborts due to potential deadlock, races which you wouldn't be able to catch anyway).

Comment 14

[Marcia Knous [:marcia]]

Both of these signatures are no longer seen in crash stats. Resolving this as WFM. Please reopen if crashes resurface.