485531 - --debugger=gdb doesn't work

Status: RESOLVED FIXED

(Testing :: Mochitest, defect)

Description

[Boris Zbarsky [:bzbarsky]]

STEPS TO REPRODUCE (on Mac):

1)  python ../obj-firefox/_tests/testing/mochitest/runtests.py --debugger=gdb
2)  At the gdb prompt, type "run"

EXPECTED RESULTS: Program starts under gdb

ACTUAL RESULTS:
(gdb) run
Starting program: /Users/bzbarsky/mozilla/vanilla/obj-firefox/dist/MinefieldDebug.app/Contents/MacOS/firefox-bin -foreground -no-remote -profile /Users/bzbarsky/mozilla/vanilla/obj-firefox/_tests/testing/mochitest/mochitesttestingprofile/ http://localhost:8888/tests/
Reading symbols for shared libraries ++++.++++++++++++............................................................................................. done
### XPCOM_MEM_BLOAT_LOG defined -- logging bloat/leaks to /Users/bzbarsky/mozilla/vanilla/obj-firefox/_tests/testing/mochitest/mochitesttestingprofile/leaks-report.log
*** Registering components in: Apprunner

Program exited with code 06.
(gdb) 

ADDITIONAL INFORMATION:

I put a breakpoint in _exit, and tried running.  After the "*** Registering components in: Apprunner" nothing happens.  GDB stops responding (no response to Ctrl-C or Ctrl-Z).  If I kill gdb from a different terminal, the Firefox process completes shutdown immediately.  A breakpoint in |exit| is never hit, so _exit is presumably being called directly.

Comment 1

[Ben Turner (not reading bugmail, use the needinfo flag!)]

Hm... WFM, on OS X.

Comment 2

[Boris Zbarsky [:bzbarsky]]

OK, so we must be doing something differently....  I wonder what.  It clearly doesn't WFM, on any of my builds.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Updating xcode did not help.

Comment 4

[Blake Kaplan (:mrbkap) (inactive)]

I don't fully understand the underlying cause here, I had a problem with the same symptoms that appears to be caused by gdb and the crash reporter somehow fighting over who gets what signal handlers.

I was able to work around it by using 'unset env MOZ_CRASHREPORTER' before 'r' in gdb.

Comment 5

[Peter Van der Beken [:peterv]]

(In reply to comment #4)
> I was able to work around it by using 'unset env MOZ_CRASHREPORTER' before 'r'
> in gdb.

Yeah, that seems to fix it for me too.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Attachment: Proposed fix

Comment 7

[(not currently active) Ted Mielczarek]

Comment on attachment 392952 [details] [diff] [review]
Proposed fix

   env['MOZ_CRASHREPORTER_NO_REPORT'] = '1'
-  env['MOZ_CRASHREPORTER'] = '1'
+  if crashreporter:
+    env['MOZ_CRASHREPORTER'] = '1'

Just stick both environment variable settings under the if block.

+  proc = Process([cmd] + args,
+                 env = environment(env, xrePath = xrePath,
+                                   crashreporter = not debuggerInfo),
           stdout = outputPipe, stderr = subprocess.STDOUT)


Can you make the indentation of the argument list consistent while you're here? I don't know if there's a similar example in this file to be consistent with, but make it internally consistent.

Comment 8

[Boris Zbarsky [:bzbarsky]]

Pushed http://hg.mozilla.org/mozilla-central/rev/496552354668 with those changes.

Tanks for the review and the help on finding the place to fix!

Comment 9

[Boris Zbarsky [:bzbarsky]]

Hmm.  This is failing for me again.  Did something break in the last month?

Comment 11

[Boris Zbarsky [:bzbarsky]]

Reopening, per comment 9.  :(  I'll see if I can figure out what's going on here.

Comment 12

[Boris Zbarsky [:bzbarsky]]

Pushed http://hg.mozilla.org/mozilla-central/rev/6282a369f3ec to fix the new breakage.

Comment 13

[Serge Gautherie (:sgautherie)]

(In reply to comment #12)
> Pushed http://hg.mozilla.org/mozilla-central/rev/6282a369f3ec to fix the new
> breakage.

That should be wanted for m-1.9.2 and m-1.9.1 too.

Comment 14

[Boris Zbarsky [:bzbarsky]]

If you want to try to get this in on those, go for it.  I don't end up debugging mochitests much on branches, so don't feel a strong need to do that.

Comment 15

[Adam Roach [:abr]]

We appear to have a regression here: I'm running into this exact problem on recent trees, and it's freezing in the exact spot as (and with the same symptoms as) described in Bug 500126 comment 1.