587375 - Crash [@ GetFinalizableArenaTraceKind]

Status: RESOLVED FIXED

(Firefox Build System :: General, defect)

Description

[Mats Palmgren (inactive)]

Attachment: crash stack

My stack looks different from bug 573440/bug 572560 so I'm filing a new bug.

STEPS TO REPRODUCE
1. start Firefox (using a clean profile)

ACTUAL RESULT
within seconds, before the first window appears  ==>  crash

PLATFORMS AND BUILDS TESTED
local Firefox debug build on x86-64 Linux, built from rev 1604f5408616
which includes the TM merge from 2010-08-13: 
http://hg.mozilla.org/mozilla-central/pushloghtml?changeset=69cffc79d212
which has the fix for bug 585824, so it's not that bug either.

ADDITIONAL INFORMATION
must be a recent regression (last day or so), I would suspect the
TM merge on 2010-08-13.

Comment 1

[Mats Palmgren (inactive)]

rev 0ee09dea0911 (just before the TM merge) works fine

Comment 2

[Mats Palmgren (inactive)]

I tried a x86-64 Linux tinderbox-build and it seems to work correctly.
So, maybe something in my build environment is causing it...

Comment 3

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I also see this reliably on new profiles, and intermittent GC crashes on existing ones.

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(And I'm also on 64-bit Linux.)

Comment 5

[Mats Palmgren (inactive)]

For me the following mozconfig options makes it crash:
ac_add_options --disable-ipc
ac_add_options --disable-libxul

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

In my crashes, I always seem to be crashing tracing the scope property of an object whose class is "StatementParams".  The object looks ok, and the sprop looks ok other than its id, which looks like a pointer that was never in a GC arena.

Comment 7

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Could it be a regression from
http://hg.mozilla.org/mozilla-central/rev/b6c7ed5a2922 ?

Comment 8

[Mats Palmgren (inactive)]

It appears so - backing that out locally makes the crash go away.
Just to verify, I also tried a clean build with:
ac_add_options --disable-ipc
ac_add_options --disable-libxul
ac_add_options --enable-shared-js
and that also works.

Comment 9

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Probably just need to make --disable-libxul imply --enable-shared-js

Comment 10

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

Would it be naive of me to ask why the link difference causes a crash, and why this crash?

Comment 11

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

If I had to guess we're linking bits and pieces of js statically into a bunch of different shared libraries.

Comment 12

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

And then checking for function pointer equality across them, perhaps?

Comment 13

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Perhaps.  Whatever we're doing, it's certainly not good.

Comment 14

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Attachment: Patch

This should do it.  Somebody who is seeing the crash want to test?

Comment 15

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Attachment: Patch

Wrong patch.

Comment 16

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 466199 [details] [diff] [review]
Patch

a2.0=dbaron

Comment 17

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Going to be afk today.

Comment 18

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I'll land this shortly (and hope it doesn't also require changes to js/src/configure.in).

Comment 19

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

http://hg.mozilla.org/mozilla-central/rev/33ff08c153d4

Comment 20

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I can confirm that it's fixed for me with the patch.