436211 - Stack corruption crash while traversing bookmark hierarchy

Status: RESOLVED DUPLICATE of bug 434673

(Core :: XPConnect, defect, P1)

Description

[Todd Agulnick]

Attachment: Console output for crash session

We've been seeing a crash that looks like a stack corruption while traversing the bookmark hierarchy in Firefox 3. The bug is tricky to reproduce, but its frequency seems to increase with larger data sets; the smallest set for which we have been able to reproduce the problem has about 1500 bookmarks in it.

The nature of the problem is that after the Javascript engine returns successfully from a call to getFaviconForPage, the browser subsequently crashes while handling a throw command. In repeated attempts, the crash always seems to occur in precisely this location.

Skipping the call to getFaviconForPage causes the same error to manifest after a call to hasMicrosummary. Repeated attempted here, too, show the crash happening in exactly the same location.

The crash reports themselves reveal almost nothing: the crashing thread shows a single random address with no symbolic information. The crash address appears to be completely random and changes with each subsequent crash.

We have run with a debug build of Firefox and produced the same crash. Console output is attached. One potentially relevant bit is this warning:

WARNING: EndUpdateBatch without a begin: file c:/mozilla/toolkit/components/plac
es/src/nsNavHistoryResult.cpp, line 4075

... but in offline discussion with Dietrich we've judged this to be likely innocuous.

Example crash reports are here:

http://crash-stats.mozilla.com/report/index/f8db12f8-2ce5-11dd-9f02-001cc45a2ce4
http://crash-stats.mozilla.com/report/index/a79a8c4a-2ce5-11dd-a221-001cc4e2bf68

To reproduce this problem:

(1) Download and install Foxmarks 2.0.46.x into a profile with lots of bookmarks.
(2) Repeatedly sync your bookmarks (essentially a null operation if nothing has changed).

Eventually (typically within 20 - 25 sync attempts) you should see the crash.

Comment 1

[timeless]

http://developer.mozilla.org/en/docs/How_to_get_a_stacktrace_with_WinDbg

!analyze -v -f

Comment 2

[Dietrich Ayala (:dietrich)]

Attachment: windbg output per comment #1

Comment 3

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

3.1a1pre in the crash reports sounds like you're working from a mozilla-central build and not CVS trunk, and mozilla-central doesn't yet have all the fixes from CVS trunk yet.  Do you see this with a nightly as of today (or rc2 candidate)?  It looks like this might be bug 434673, for which the fix isn't on m-c yet, specifically.  How old is your debug build's tree?

(Unlikely to be a core:JS bug, since it would have to be a bug in GetResolvedSlot rather than its caller or other maintainer of the object graph.)

Comment 4

[timeless]

the only reason i sent it to js instead of xpconnect was because of the array join / marksharpobjects. although it indeed is more likely a bug in xpconnect.

Comment 5

[Todd Agulnick]

Can someone please offer some advice to a poor extension developer that wants to understand more about what kind of operation is happening during the crash? I'd really like to figure out whether there's a way that I can temporarily work around the problem, especially if a real fix is not forthcoming until the end of the year.

Any advice would be greatly appreciated...

Comment 6

[Mike Schroepfer]

Todd did you see comment 3?

Comment 7

[Todd Agulnick]

Mike, thanks for following up.

We last reproduced the crash with Build 2008052804; it's unclear whether that build would have had the fix from bug 434673, so we'll try to reproduce ASAP with RC2 and post our results here as soon as we have 'em.

While we're doing that, one other question for those who might know: does the presence of "array_toSource" in the stack frame suggest that the JS code that was executing when the crash occurred was calling toSource on an array object? That might point at a work-around for us if the crash persists in RC2.

Comment 8

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

(In reply to comment #7)
> Mike, thanks for following up.
> While we're doing that, one other question for those who might know: does the
> presence of "array_toSource" in the stack frame suggest that the JS code that
> was executing when the crash occurred was calling toSource on an array object?
> That might point at a work-around for us if the crash persists in RC2.

Yes, that's exactly what array_toSource means, indeed.

Comment 9

[Todd Agulnick]

(In reply to comment #8)

> Yes, that's exactly what array_toSource means, indeed.

Thanks.

We've been unable thus far to reproduce the crash under RC2, so we're tentatively happy to call this a dup of bug 434673. We're going to run some additional automated testing overnight; if that doesn't turn up a crash, it's a done deal. (Phew!)