704302 - Crash in JS_DeepFreezeObject on PPC64

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, defect)

Description

[Colin Walters]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20100101 Firefox/7.0.1
Build ID: 20110930134335

Steps to reproduce:

Build js-185 on Fedora 16/PPC64 with --enable-threadsafe --with-system-nspr.


Actual results:

The test suite crashes in jsapi-tests/testDeepFreeze.cpp:testDeepFreeze_deep


Expected results:

I think this has something to do with freezing the object corrupting it, and then when the GC starts walking the object set it encounters the corrupted object.

Comment 1

[Colin Walters]

See also bugzilla.redhat.com/749604

Comment 2

[Colin Walters]

To clarify, commenting out both deep freeze tests, all the other tests then pass.  I'll try to attach a stack trace.

Comment 3

[Colin Walters]

Attachment: GDB session

Comment 4

[David Mandelin [:dmandelin]]

Program received signal SIGSEGV, Segmentation fault.
0x00000000101df4c8 in js::gc::MarkId (trc=0x0, id=0) at jsgcinlines.h:540

Based on the above, and the huge number of stack frames, I'm thinking maybe the deep freeze is recurring infinitely, then OOMing, putting a NULL somewhere because of the OOM, and then crashing when marking that.

Comment 5

[Jeff Walden [:Waldo]]

JS_DeepFreezeObject is a fundamentally dangerous API that I don't think we should have, because it necessarily consumes stack proportional to the "depth" of the object being frozen.  It seems better to me for applications to freeze objects one at a time, and to handle freezing the values of properties in a separate pass, in whatever way makes most sense to the application.

I'm pretty sure I expressed this when changing JS_SealObject to JS_FreezeObject, but someone(ish) objected to the removal because we already provided a broken API and should keep providing it even if broken.

Comment 6

[Jeff Walden [:Waldo]]

Well, I shouldn't say "necessarily".  What I mean is that there's risk of a partially-frozen-tree that only the application can really know how to handle, and the way it seems likely to handle it requires knowledge of when such freezing failed.  So having the user write the recursion and freezing logic seems best.

Comment 7

[Marcela (Please NI request to Brindusa Tot)]

Hi! I am closing this issue with Resolved-Worksforme since there were no changes made in the past 10 years. If the issue is still available please feel free to reopen it.
Thanks!