Closed Bug 913173 Opened 7 years ago Closed 7 years ago

mach xpcshell-test --debugger doesn't work


(Testing :: XPCShell Harness, defect)

Not set


(Not tracked)



(Reporter: bholley, Assigned: ted)




(2 files, 1 obsolete file)

Maybe this is a mac thing? It doesn't hit the breakpoint I set, and crashes.


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.
Attached file log.txt
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

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
Blocks: 717538
Flags: needinfo?(gps)
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?
Assignee: mh+mozilla → ted
Flags: needinfo?(gps)
Cameron, sounds like we need a separate bug on the reftest bits?
Flags: needinfo?(cam)
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"
    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/
@@ +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.
Flags: needinfo?(cam)
I got motivated and did a Mac build, and could reproduce the problem (with reftest and mochitest). This patch fixes it.
Attachment #803177 - Flags: review?(jmaher)
Comment on attachment 803177 [details] [diff] [review]
fix --debugger for reftest/mochitest on OS X

This was supposed to go on the other bug.
Attachment #803177 - Attachment is obsolete: true
Attachment #803177 - Flags: review?(jmaher)
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla26
You need to log in before you can comment on or make changes to this bug.