Running chunk 15 of 40 mochitest chrome under valgrind on Fedora 20 x86_64 using rm -f ./mochitest-chrome.log && /mozilla/builds/nightly/mozilla/firefox-debug/_virtualenv/bin/python _tests/testing/mochitest/runtests.py --autorun --close-when-done --console-level=INFO --log-file=./mochitest-chrome.log --file-level=INFO --failure-file=/mozilla/builds/nightly/mozilla/firefox-debug/_tests/testing/mochitest/makefailures.json --testing-modules-dir=/mozilla/builds/nightly/mozilla/firefox-debug/_tests/modules --extra-profile-file=dist/plugins --symbols-path=dist/crashreporter-symbols --debugger='valgrind' --debugger-args='--tool=memcheck --trace-children=yes --vex-iropt-register-updates=allregs-at-mem-access --smc-check=all-non-file --soname-synonyms=somalloc=NONE' --timeout=86400 --total-chunks=40 --this-chunk=15 --chrome 555 INFO TEST-START | chrome://mochitests/content/chrome/dom/ipc/tests/test_process_error.xul ==25411== Invalid read of size 4 ==25411== at 0x7B7029E: js::ctypes::ConvertToJS(JSContext*, JS::Handle<JSObject*>, JS::Handle<JSObject*>, void*, bool, bool, JS::Value*) (typedefs.h:78) ==25411== by 0x7B75AEC: js::ctypes::PointerType::ContentsGetter(JSContext*, JS::CallArgs) (CTypes.cpp:4144) ==25411== by 0x7B75B86: js::ctypes::Property<&js::ctypes::PointerType::IsPointer, &js::ctypes::PointerType::ContentsGetter>::Fun(JSContext*, unsigned int, JS::Value*) (CallNonGenericMethod.h:100) ==25411== by 0x7FC208F: js::CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), JS::CallArgs const&) (jscntxtinlines.h:239) ==25411== by 0x80014E0: js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct) (Interpreter.cpp:474) ==25411== by 0x800190C: js::Invoke(JSContext*, JS::Value const&, JS::Value const&, unsigned int, JS::Value const*, JS::MutableHandle<JS::Value>) (Interpreter.cpp:530) ==25411== by 0x8001BBA: js::InvokeGetterOrSetter(JSContext*, JSObject*, JS::Value, unsigned int, JS::Value*, JS::MutableHandle<JS::Value>) (Interpreter.cpp:602) ==25411== by 0x7EDC619: bool NativeGetInline<(js::AllowGC)1>(JSContext*, js::MaybeRooted<JSObject*, (js::AllowGC)1>::HandleType, js::MaybeRooted<JSObject*, (js::AllowGC)1>::HandleType, js::MaybeRooted<JSObject*, (js::AllowGC)1>::HandleType, js::MaybeRooted<js::Shape*, (js::AllowGC)1>::HandleType, js::MaybeRooted<JS::Value, (js::AllowGC)1>::MutableHandleType) (Shape-inl.h:46) ==25411== by 0x7F17DA6: bool GetPropertyHelperInline<(js::AllowGC)1>(JSContext*, js::MaybeRooted<JSObject*, (js::AllowGC)1>::HandleType, js::MaybeRooted<JSObject*, (js::AllowGC)1>::HandleType, js::MaybeRooted<jsid, (js::AllowGC)1>::HandleType, js::MaybeRooted<JS::Value, (js::AllowGC)1>::MutableHandleType) (jsobj.cpp:4544) ==25411== by 0x7F17E2A: js::baseops::GetProperty(JSContext*, JS::Handle<JSObject*>, JS::Handle<JSObject*>, JS::Handle<jsid>, JS::MutableHandle<JS::Value>) (jsobj.cpp:4554) ==25411== by 0x7B48516: JSObject::getGeneric(JSContext*, JS::Handle<JSObject*>, JS::Handle<JSObject*>, JS::Handle<jsid>, JS::MutableHandle<JS::Value>) (jsobj.cpp:4554) ==25411== by 0x7F500F4: js::DirectProxyHandler::get(JSContext*, JS::Handle<JSObject*>, JS::Handle<JSObject*>, JS::Handle<jsid>, JS::MutableHandle<JS::Value>) (jsproxy.cpp:593) ==25411== Address 0x8 is not stack'd, malloc'd or (recently) free'd ==25411== ==25411== ==25411== Process terminating with default action of signal 11 (SIGSEGV) ==25411== Access not within mapped region at address 0x8 ==25411== at 0x7B7029E: js::ctypes::ConvertToJS(JSContext*, JS::Handle<JSObject*>, JS::Handle<JSObject*>, void*, bool, bool, JS::Value*) (typedefs.h:78) ==25411== by 0x7B75AEC: js::ctypes::PointerType::ContentsGetter(JSContext*, JS::CallArgs) (CTypes.cpp:4144) ==25411== by 0x7B75B86: js::ctypes::Property<&js::ctypes::PointerType::IsPointer, &js::ctypes::PointerType::ContentsGetter>::Fun(JSContext*, unsigned int, JS::Value*) (CallNonGenericMethod.h:100) ==25411== by 0x7FC208F: js::CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), JS::CallArgs const&) (jscntxtinlines.h:239) ==25411== by 0x80014E0: js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct) (Interpreter.cpp:474) ==25411== by 0x800190C: js::Invoke(JSContext*, JS::Value const&, JS::Value const&, unsigned int, JS::Value const*, JS::MutableHandle<JS::Value>) (Interpreter.cpp:530) ==25411== by 0x8001BBA: js::InvokeGetterOrSetter(JSContext*, JSObject*, JS::Value, unsigned int, JS::Value*, JS::MutableHandle<JS::Value>) (Interpreter.cpp:602) ==25411== by 0x7EDC619: bool NativeGetInline<(js::AllowGC)1>(JSContext*, js::MaybeRooted<JSObject*, (js::AllowGC)1>::HandleType, js::MaybeRooted<JSObject*, (js::AllowGC)1>::HandleType, js::MaybeRooted<JSObject*, (js::AllowGC)1>::HandleType, js::MaybeRooted<js::Shape*, (js::AllowGC)1>::HandleType, js::MaybeRooted<JS::Value, (js::AllowGC)1>::MutableHandleType) (Shape-inl.h:46) ==25411== by 0x7F17DA6: bool GetPropertyHelperInline<(js::AllowGC)1>(JSContext*, js::MaybeRooted<JSObject*, (js::AllowGC)1>::HandleType, js::MaybeRooted<JSObject*, (js::AllowGC)1>::HandleType, js::MaybeRooted<jsid, (js::AllowGC)1>::HandleType, js::MaybeRooted<JS::Value, (js::AllowGC)1>::MutableHandleType) (jsobj.cpp:4544) ==25411== by 0x7F17E2A: js::baseops::GetProperty(JSContext*, JS::Handle<JSObject*>, JS::Handle<JSObject*>, JS::Handle<jsid>, JS::MutableHandle<JS::Value>) (jsobj.cpp:4554) ==25411== by 0x7B48516: JSObject::getGeneric(JSContext*, JS::Handle<JSObject*>, JS::Handle<JSObject*>, JS::Handle<jsid>, JS::MutableHandle<JS::Value>) (jsobj.cpp:4554) ==25411== by 0x7F500F4: js::DirectProxyHandler::get(JSContext*, JS::Handle<JSObject*>, JS::Handle<JSObject*>, JS::Handle<jsid>, JS::MutableHandle<JS::Value>) (jsproxy.cpp:593) This appears to be the same or similar to bug 982600 and perhaps bug 985845

Can you please break at the error and run DumpJSStack? The bug is likely in the JS code using ctypes, not in the ctypes implementation itself.

bsmedberg: sewardj has been helping me with the necessary gdb+valgrind foo. We've run into a bit of an issue but will hopefully be able to respond before too long. I'll get back to you when we have more info.

We've run ASAN over the same chunk of tests and not found anything, right? Usually both tools would spot this kind of thing (but valgrind seems to have a longer "memory")

bzip2d valgrind.log using updated valgrind trunk and new firefox build.

(In reply to Daniel Veditz [:dveditz] from comment #3) Well, it is exactly the same stack as found by ASAN, in comment 0 of bug 985845, as Bob observes.

(In reply to Benjamin Smedberg [:bsmedberg] from comment #1) > Can you please break at the error and run DumpJSStack? All I got was the following 2 lines: 0 <TOP LEVEL> ["chrome://mochitests/content/chrome/dom/ipc/tests/process_error_contentscript.js":7] this = [object ContentFrameMessageManager @ 0x15ed5340 (native @ 0x15e39b80)]

Comment on attachment 8407657 [details] valgrind.log.bz2 wrong bug.

I can't get valgrind to work with attaching to the child process. I tried --db-attach=yes and --vgdb=full --vgdb-error=0. You can run the single test with: /mozilla/builds/nightly/mozilla/firefox-debug/_virtualenv/bin/python _tests/testing/mochitest/runtests.py --autorun --close-when-done --console-level=INFO --log-file=./mochitest-chrome.log --file-level=INFO --failure-file=/mozilla/builds/nightly/mozilla/firefox-debug/_tests/testing/mochitest/makefailures.json --testing-modules-dir=/mozilla/builds/nightly/mozilla/firefox-debug/_tests/modules --extra-profile-file=dist/plugins --symbols-path=dist/crashreporter-symbols --debugger='valgrind' --debugger-args='--tool=memcheck --trace-children=yes --vex-iropt-register-updates=allregs-at-mem-access --smc-check=all-non-file --soname-synonyms=somalloc=NONE' --chrome --start-at tests/test_process_error.xul --end-at test_process_error.xul I now see the original valgrind issue @ js::ctypes::ConvertToJS(JSContext*, JS::Handle<JSObject*>, JS::Handle<JSObject*>, void*, bool, bool, JS::Value*) (typedefs.h:78) followed by a crash and now a new issue @nsContentUtils::GetCurrentJSContext() (nsContentUtils.cpp:5135) followed by a crash. I can reproduce the first crash in gdb using export MOZ_DEBUG_CHILD_PROCESS=1 /mozilla/builds/nightly/mozilla/firefox-debug/_virtualenv/bin/python _tests/testing/mochitest/runtests.py --autorun --close-when-done --console-level=INFO --log-file=./mochitest-chrome.log --file-level=INFO --failure-file=/mozilla/builds/nightly/mozilla/firefox-debug/_tests/testing/mochitest/makefailures.json --testing-modules-dir=/mozilla/builds/nightly/mozilla/firefox-debug/_tests/modules --extra-profile-file=dist/plugins --symbols-path=dist/crashreporter-symbols --debugger=gdb --debugger-interactive --chrome --start-at tests/test_process_error.xul --end-at test_process_error.xul Then attaching to the child process.

I'm confused about what you're asking. The crash in the content process is expected: this test intentionally crashes the content process to check whether the error handling is correct. This doesn't indicate any bug in ctypes or anything like that. If there are errors in the chrome process, those should be investigated and fixed.

I see. The Invalid read of size 4 at 0x7C7150E: js::ctypes::ConvertToJS(JSContext*, JS::Handle<JSObject*>, JS::Handle<JSObject*>, void*, bool, bool, JS::Value*) (typedefs.h:78) and the following crash are expected and noted in the log and are the result of privateNoteIntentionalCrash(); var zero = new ctypes.intptr_t(8); var badptr = ctypes.cast(zero, ctypes.PointerType(ctypes.int32_t)); var crash = badptr.contents; in process_error_contentscript.js. Is the other Invalid read of size 8 at 0x6A1DFBC: nsContentUtils::GetCurrentJSContext() (nsContentUtils.cpp:5135) and the following crash also an expected outcome? The first was a 32bit pointer which seems to match badptr, but the latter is different stack and a 64bit pointer? If these are the same issue, I guess this entire bug is invalid.

The nsContentUtils::GetCurrentJSContext crash looks different and doesn't seem obviously intentional. Need to see the stack of course.

I haven't been able to see the nsContentUtils::GetCurrentJSContext crash outside of valgrind and haven't been able to get a better stack than what valgrind provided originally.

I'm going to mark this as invalid as the original report was for an intentional crash. If I can get actionable steps and a stack for the nsContentUtils::GetCurrentJSContext issue I'll file a new bug.