var a = new WeakMap(); var b = new WeakMap(); a.set(b, null); valgrind ./js q.js > ==13533== Mismatched free() / delete / delete  > ==13533== at 0x4C2806F: operator delete(void*) (vg_replace_malloc.c:387) > ==13533== by 0x592892: js::WeakMap::finalize(JSContext*, JSObject*) (jsweakmap.cpp:300) > ==13533== by 0x4AC5A8: JSObject::finalize(JSContext*) (jsobjinlines.h:141) > ==13533== by 0x4B5CDE: js::gc::Arena<JSObject>::finalize(JSContext*) (jsgc.cpp:231) > ==13533== by 0x4AB442: void js::gc::FinalizeArenas<JSObject>(JSContext*, js::gc::ArenaHeader**) (jsgc.cpp:278) > ==13533== by 0x4B0D2E: void js::gc::ArenaList::finalizeNow<JSObject>(JSContext*) (jsgc.cpp:1231) > ==13533== by 0x4A9A86: JSCompartment::finalizeObjectArenaLists(JSContext*) (jsgc.cpp:2016) > ==13533== by 0x4AA491: MarkAndSweep(JSContext*, JSCompartment*, JSGCInvocationKind) (jsgc.cpp:2404) > ==13533== by 0x4AA802: GCCycle(JSContext*, JSCompartment*, JSGCInvocationKind) (jsgc.cpp:2682) > ==13533== by 0x4AA9D8: js_GC(JSContext*, JSCompartment*, JSGCInvocationKind) (jsgc.cpp:2753) > ==13533== by 0x45D9F3: js_DestroyContext(JSContext*, JSDestroyContextMode) (jscntxt.cpp:643) > ==13533== by 0x4278F7: JS_DestroyContext (jsapi.cpp:1032) > ==13533== Address 0x5eb71f0 is 0 bytes inside a block of size 104 alloc'd > ==13533== at 0x4C2901C: malloc (vg_replace_malloc.c:236) > ==13533== by 0x417F29: js_malloc (jsutil.h:239) > ==13533== by 0x435B4A: JSRuntime::malloc_(unsigned long, JSContext*) (jscntxt.h:724) > ==13533== by 0x436026: JSContext::malloc_(unsigned long) (jscntxt.h:1283) > ==13533== by 0x592BA1: js::WeakMap* JSContext::new_<js::WeakMap, JSContext*>(JSContext* const&) (in /home/jruderman/tm-dbg-vg/shell/js) > ==13533== by 0x592419: js::WeakMap::set(JSContext*, unsigned int, js::Value*) (jsweakmap.cpp:204) > ==13533== by 0x4C75C9: js::CallJSNative(JSContext*, int (*)(JSContext*, unsigned int, js::Value*), unsigned int, js::Value*) (jscntxtinlines.h:277) > ==13533== by 0x6F075A: js::Interpret(JSContext*, js::StackFrame*, unsigned int, js::InterpMode) (jsinterp.cpp:4664) > ==13533== by 0x4C2C0F: js::RunScript(JSContext*, JSScript*, js::StackFrame*) (jsinterp.cpp:603) > ==13533== by 0x4C3FB9: js::Execute(JSContext*, JSObject&, JSScript*, js::StackFrame*, unsigned int, js::Value*) (jsinterp.cpp:964) > ==13533== by 0x43113F: JS_ExecuteScript (jsapi.cpp:4940) > ==13533== by 0x4051D9: Process(JSContext*, JSObject*, char*, int) (js.cpp:451)
There are several other "delete table;" lines in jsweakmap.cpp, fwiw.
To be clear, I requested tracking because this looks like a memory-safety bug in a new feature...
Created attachment 531655 [details] [diff] [review] Patch
bz, this is not a bug with our current allocator on aurora. Do you agree?
I don't know... esp. for Linux distros that build with a separate (system) Spidermonkey.
If the fix is safe and standalone, you can just make an approval request David. Or if you believe it doesn't affect aurora (#3), just change the status to unaffected for 6.
Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20100101 Firefox/6.0 I was trying to see if this is fixed for Fx6 since the flag "status-firefox6" is set on "fixed", but I couldn't. Is there a test case or any steps / guidelines for this bug that can be used to verify the fix? Thanks
AndreiD, comment 0 contains a testcase and steps to reproduce. You'll need to install valgrind (a memory debugger) and then build a js shell with "./configure --enable-valgrind". http://valgrind.org/ https://developer.mozilla.org/En/SpiderMonkey/Build_Documentation