Closed Bug 913173 Opened 8 years ago Closed 8 years ago
mach xpcshell-test --debugger doesn't work
Maybe this is a mac thing? It doesn't hit the breakpoint I set, and crashes. STR: mach xpcshell-test --debugger gdb js/xpconnect/tests/unit/test_want_components.js (GDB will fire up) (gdb) b xpc::CreateSandboxObject Breakpoint 1 at 0x51eb8519b9b1f3: file /files/mozilla/repos/h/js/xpconnect/src/Sandbox.cpp, line 878. (gdb) r Starting program: /files/mozilla/build/h/dist/bin/xpcshell -g /files/mozilla/build/h/dist/bin -a /files/mozilla/build/h/dist/bin -r /files/mozilla/build/h/dist/bin/components/httpd.manifest -m -n -s -e const\ _HTTPD_JS_PATH\ =\ \"/files/mozilla/build/h/dist/bin/components/httpd.js\"\; -e const\ _HEAD_JS_PATH\ =\ \"/files/mozilla/repos/h/testing/xpcshell/head.js\"\; -e const\ _TESTING_MODULES_DIR\ =\ \"/files/mozilla/build/h/_tests/modules/\"\; -f /files/mozilla/repos/h/testing/xpcshell/head.js -p /var/folders/dr/l_l5sx1x2w3dw7kwhlf1yg2r0000gn/T/tmprXtYY_ -e const\ _SERVER_ADDR\ =\ \"localhost\" -e const\ _HEAD_FILES\ =\ \[\]\; -e const\ _TAIL_FILES\ =\ \[\]\; -e const\ _TEST_FILE\ =\ \[\"/files/mozilla/build/h/_tests/xpcshell/js/xpconnect/tests/unit/test_want_components.js\"\]\; -e _execute_test\(\)\;\ quit\(0\)\; Reading symbols for shared libraries ++++++++++.............................................................................................................................................................................. done Program exited with code 06. When I ctrl-D to quit GDB, I get an odd crash: (gdb) 1:03.92 TEST-PASS | /files/mozilla/build/h/_tests/xpcshell/js/xpconnect/tests/unit/test_want_components.js | test passed (time: 63757.603ms) 1:03.92 >>>>>>> 1:03.92 <<<<<<< PROCESS-CRASH | /files/mozilla/build/h/_tests/xpcshell/js/xpconnect/tests/unit/test_want_components.js | application crashed [@ 0x7fff5fc0b26a] Crash dump filename: /var/folders/dr/l_l5sx1x2w3dw7kwhlf1yg2r0000gn/T/tmpQPBlOp/E194E385-ABE1-4F05-96A0-CEAC8E5B18A4.dmp Operating system: Mac OS X 10.7.5 11G63 CPU: amd64 family 6 model 42 stepping 7 8 CPUs Crash reason: EXC_BREAKPOINT / 0x00000002 Crash address: 0x7fff5fc0b26a Thread 0 (crashed) 0 0x7fff5fc0b26a rbx = 0x00000001 r12 = 0x5fc35110 r13 = 0x0f81abc0 r14 = 0x0f81abc0 r15 = 0x00000000 rip = 0x5fc0b26a rsp = 0x5fbf6e48 rbp = 0x5fbf6e60 Found by: given as instruction pointer in context ....
Could you post more of the crash dump? If it's an xpcshell crash dump, then that means that xpcshell crashed, and the crash dumper caught the problem, even though it's running under GDB. Perhaps it crashed before it hit your breakpoint. If it's a GDB crash dump, then... GDB sucks.
Oh, maybe this is just fallout from bug 717538? Try setting MOZ_CRASHREPORTER_DISABLE=1 in your environment, if that works then that's the issue.
(In reply to Ted Mielczarek [:ted.mielczarek] from comment #3) > Oh, maybe this is just fallout from bug 717538? Try setting > MOZ_CRASHREPORTER_DISABLE=1 in your environment, if that works then that's > the issue. Doesn't help.
It won't help, but I suspect this is in fact fallout from that bug. There's various places our automation sets MOZ_CRASHREPORTER=1. And in a _debug_ build, that env var now matters while MOZ_CRASHREPORTER_DISABLE is ignored. Case in point is http://hg.mozilla.org/mozilla-central/file/c7cc85e13f7a/testing/xpcshell/runxpcshelltests.py#l792 I assume mach xpcshell-test invokes that? I further assume that mach reftest invokes one of the other automation bits that assume you're running on a test slave and do something similar? :( If so, can we teach mach to do something different when --debugger is used here?
Assignee: nobody → mh+mozilla
Oh, actually, I bet this is fallout from bug 842728. I have a plan for a patch, will attach in a few.
bz: I think we're conflating two different issues here. The xpcshell brokenness is almost certainly due to my changes in bug 842728. Brokenness in Mochitest or Reftest are likely fallout from bug 717538. The fix would be pretty much the same, but needs to be fixed per-harness: when --debugger is specified, don't set MOZ_CRASHREPORTER=1, and set MOZ_CRASHREPORTER_DISABLE=1 for non-xpcshell harnesses.
I don't have an up-to-date mac build, so I haven't tested this, but this seems sensible. bholley: can you see if this fixes the problem for you?
Cameron, sounds like we need a separate bug on the reftest bits?
Comment on attachment 801647 [details] [diff] [review] fix xpcshell-test --debugger on OS X It works! \o/ Thanks ted.
Attachment #801647 - Flags: feedback+
Comment on attachment 801647 [details] [diff] [review] fix xpcshell-test --debugger on OS X A similar fix should fix the other harnesses: something like if self.debuggerInfo: self.env["MOZ_CRASHREPORTER_DISABLE"] = "1" else: self.env["MOZ_CRASHREPORTER"] = "1"
Attachment #801647 - Flags: review?(gps)
Comment on attachment 801647 [details] [diff] [review] fix xpcshell-test --debugger on OS X Review of attachment 801647 [details] [diff] [review]: ----------------------------------------------------------------- ::: testing/xpcshell/runxpcshelltests.py @@ +789,5 @@ > # Make assertions fatal > self.env["XPCOM_DEBUG_BREAK"] = "stack-and-abort" > + if not self.debuggerInfo: > + # Enable crash reporting > + self.env["MOZ_CRASHREPORTER"] = "1" I think the comment is obvious. Perhaps you should change the comment to note that the crash reporter interferes with debugging.
Attachment #801647 - Flags: review?(gps) → review+
Filed bug 914925 for reftest.
I got motivated and did a Mac build, and could reproduce the problem (with reftest and mochitest). This patch fixes it.
Comment on attachment 803177 [details] [diff] [review] fix --debugger for reftest/mochitest on OS X This was supposed to go on the other bug.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla26
You need to log in before you can comment on or make changes to this bug.