Closed Bug 72043 Opened 24 years ago Closed 24 years ago

crash marking prop name atoms of rooted object after 'last' JSContext

Categories

(Core :: JavaScript Engine, defect, P2)

defect

Tracking

()

VERIFIED FIXED
mozilla0.9

People

(Reporter: jband_mozilla, Assigned: shaver)

Details

(Keywords: js1.5)

Attachments

(2 files)

Try the following... #include "jsapi.h" int main() { JSRuntime *rt; JSContext* cx; JSObject* glob; JSObject* obj; rt = JS_NewRuntime(8L * 1024L * 1024L); cx = JS_NewContext(rt, 8192); glob = JS_NewObject(cx, NULL, NULL, NULL); JS_InitStandardClasses(cx, glob); obj = JS_NewObject(cx, NULL, NULL, NULL); JS_AddRoot(cx, &obj); JS_DefineProperty(cx, obj, "foo", JSVAL_NULL, NULL, NULL, 0); JS_DestroyContext(cx); cx = JS_NewContext(rt, 8192); /* It crashes in this gc while trying to mark the atom of obj's * 'foo' prop. Well, sometimes it doesn't crash here and just corrupts * some memory instead. * * Turning on GC_MARK_DEBUG will assure a crash because js_MarkAtom then * will try to dereference the dangling JSString pointer rather than * just corrupting some memory. */ JS_GC(cx); JS_DestroyContext(cx); JS_DestroyRuntime(rt); return 0; } I belive that the cleanup in js_DestoryContext for the 'last' context is killing atoms that would be marked by the rooted JSObject.
Note that this is a follow up on the newsgroup thread from Ed Thomson... news://news.mozilla.org/3AB0139D.8000709%40sourcegear.com
I have an idea, hope to patch this today. /be
Status: NEW → ASSIGNED
Keywords: js1.5, mozilla0.9
Priority: -- → P2
Target Milestone: --- → mozilla0.9
I thought shaver took this already. /be
Assignee: brendan → shaver
Status: ASSIGNED → NEW
This was easier than I expected. Instead of counting interned atoms and deferring js_FreeAtomState's guts till js_FinishAtomState, the next patch simply counts live atoms after a mark/sweep GC, in the sweep phase. This liveAtoms count serves to defer js_FreeAtomState. I also fixed js_InitAtomState to cope with being called on the "first after last" new context on a JSRuntime that already hosted contexts. This case did not arise in the XPConnect shutdown case that motivated the interned atom counting and previous js_FreeAtomState deferral, but it will in any situation like the one reported here, where a runtime goes from context-full to -less to -full again. /be
Brendan cleans up after me again. sr=shaver, thanks. (And yes, ``screw the crays''.)
r=jband
Fix is in. /be
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
John, does this work OK for you now? I tried to verify the fix, but wasn't able to compile your example (I'm doing something wrong).
I verified with the testcase in this bug. I used this script to compile and link the foo.c program (cut and paste jband's excerpt of the newsgroup reporter's testcase) with libmozjs (Linux): gcc -o Linux_All_DBG.OBJ/foo.o -c -Wall -Wno-format -DGCC_OPT_BUG -g -DXP_UNIX -DSVR4 -DSYSV -D_BSD_SOURCE -DPOSIX_SOURCE -DX86_LINUX -DDEBUG -DDEBUG_brendan -DEDITLINE -ILinux_All_DBG.OBJ foo.c gcc -o Linux_All_DBG.OBJ/foo -Wall -Wno-format -DGCC_OPT_BUG -g -DXP_UNIX -DSVR4 -DSYSV -D_BSD_SOURCE -DPOSIX_SOURCE -DX86_LINUX -DDEBUG -DDEBUG_brendan -DEDITLINE -ILinux_All_DBG.OBJ Linux_All_DBG.OBJ/foo.o Linux_All_DBG.OBJ/libjs.a -lm -Lfdlibm/Linux_All_DBG.OBJ -lfdm -Leditline/Linux_All_DBG.OBJ -ledit /be
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: