--debugger=lldb doesn't work with xpcshell tests

REOPENED
Unassigned

Status

Testing
XPCShell Harness
REOPENED
4 years ago
3 years ago

People

(Reporter: Bobby Holley (parental leave - send mail for anything urgent), Unassigned)

Tracking

({leave-open})

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

STR (on OSX):

mach xpcshell-test --debugger lldb js/xpconnect/tests/unit/test_sandbox_metadata.js

This is the same issue as bug 943734, I think. Just need to figure out how to make it work for xpcshell tests as well.
I just played around with this a little bit. I had to escape the parentheses in the -e 'someCode();' parts. This got me a bit farther, but I was still foiled by quote escaping.
This happens for reftests too :-(
Dupe of bug 940930?
(In reply to Henrik Skupin (:whimboo) from comment #3)
> Dupe of bug 940930?

Depends if argument quoting is at fault or not.
(In reply to Bobby Holley (:bholley) from comment #1)
> I just played around with this a little bit. I had to escape the parentheses
> in the -e 'someCode();' parts. This got me a bit farther, but I was still
> foiled by quote escaping.

So I escaped the parens, and things would run for me, but xpcshell would always just exit with error code 3, which didn't seem correct.  Didn't try a specific test, though, should try that next.

Updated

4 years ago
Duplicate of this bug: 1002467

I had the same problem with lldb.
Before running it with lldb, i accidentally run the test with gdb without loaded symbols and it run without this error.
Yeah, this should really be fixed. In the mean time, my workaround is to run the tests interactively (-i) and attach a debugger from another shell.

Comment 9

3 years ago
Ted, can you please find someone to fix this?  The workarounds that I'm doing these days for debugging these tests is getting close to insane...  Thanks!
Component: General → XPCShell Harness
Flags: needinfo?(ted)
The last time I looked into this, it looked like LLDB was confused about how to escape quotes in its arguments.

Comment 11

3 years ago
Can we escape them before sending them to lldb?
If someone can figure out *what* we need to send to lldb to make it happy we can definitely get this fixed.
Flags: needinfo?(ted)
(In reply to :Ehsan Akhgari (not reading bugmail, needinfo? me!) from comment #11)
> Can we escape them before sending them to lldb?

ISTR that lldb still does dumb things with escaped quotes, but I'm compiling a build to actually document what I discover this time.

Possible workaround: make xpcshell understand @-file arguments, so we can invoke:

xpcshell @/tmp/arguments

where /tmp arguments contains:

--some-option
--script thing.js
--more-options
etc.

and then lldb (or other debuggers) don't have a chance to twaddle the arguments.
So this actually seemed to work for me today, using the test in comment 0.  I got a bunch of LOG/INFO lines, and then got dropped into an LLDB prompt.

(lldb) run
/bin/sh: -c: line 0: syntax error near unexpected token `('
/bin/sh: -c: line 0: `<ridiculously long command elided>'
error: process exited with status 2
'r' and 'run' are aliases that default to launching through a shell.
Try launching without going through a shell by using 'process launch'.
(lldb) process launch
Process 54413 launched: '/blah/blah/xpcshell' (x86_64)

<stuff that looks like xpcshell PASS messages>

Process 54413 exited with status = 0 (0x00000000)
(lldb)

Does the above match your experience today, bholley?
Flags: needinfo?(bobbyholley)
I still get failures:

https://pastebin.mozilla.org/8829480

My lldb version is lldb-320.4.156
Flags: needinfo?(bobbyholley)
Did you try the |process launch| bit?  Don't ask me why lldb feels it needs two different ways of launching the debuggee, but apparently |process launch| handles quoting correctly, and |run| doesn't.
Flags: needinfo?(bobbyholley)
oh hey yeah! process launch does the trick.

Still a terrible footgun though.
Flags: needinfo?(bobbyholley)
OK, I'm going to declare this WORKSFORMEBUTAWFUL.  I'd be curious whether |process launch| works in earlier versions of XCode/lldb, and they just didn't have the helpful "hey, the muscle memory thing didn't work, try this totally different thing!" message yet.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WORKSFORME
With this bug closed, it's less likely to be found by people searching for it, and everyone but the people CCed here are going to have a terrible time. Would it be possible to add some sort of message into mach that detects this case and tells people what to do?
Flags: needinfo?(nfroyd)

Comment 20

3 years ago
Is there an upstream bug for ensuring that "run" does the same escaping as "process launch" does?
(In reply to Bobby Holley (:bholley) from comment #19)
> With this bug closed, it's less likely to be found by people searching for
> it, and everyone but the people CCed here are going to have a terrible time.
> Would it be possible to add some sort of message into mach that detects this
> case and tells people what to do?

I dunno, I guess we could get mach to yell at people to remember to use |process launch|.  Given that lldb already tells you to do that, I'm not sure whether that's useful.  Maybe only if lldb is "old"?

Alternatively, maybe we should just redefine 'run' to invoke 'process launch' in Gecko's lldb scripts?  Can we even do that?

(In reply to :Ehsan Akhgari (not reading bugmail, needinfo? me!) from comment #20)
> Is there an upstream bug for ensuring that "run" does the same escaping as
> "process launch" does?

No idea.  I suspect |process launch| doesn't do any escaping, since it probably passes things directly to execve(2) or similar, whereas |run| needs to escape things so that the shell will unescape them before invoking execve(2).
Flags: needinfo?(nfroyd)

Comment 22

3 years ago
You can't redefine built-in lldb commands as alias unfortunately (how many software projects are going to make this mistake?!)

I have a patch to warn people about this.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---

Comment 23

3 years ago
Created attachment 8590444 [details] [diff] [review]
Print a warning about using 'run' when debugging an xpcshell test using lldb
Attachment #8590444 - Flags: review?(nfroyd)
Comment on attachment 8590444 [details] [diff] [review]
Print a warning about using 'run' when debugging an xpcshell test using lldb

Review of attachment 8590444 [details] [diff] [review]:
-----------------------------------------------------------------

I guess.  Have you actually tried this?  I have my doubts that people are going to see it in the storm of messages that already occur:

jeangray:m-c.hg froydnj$ mach xpcshell-test --debugger=lldb js/xpconnect/tests/unit/test_sandbox_metadata.js
From _tests: Kept 35097 existing; Added/updated 0; Removed 0 files and 0 directories.
 0:02.50 LOG: MainThread INFO Running tests sequentially.
 0:02.51 SUITE_START: MainThread 1
 0:02.81 TEST_START: Thread-1 js/xpconnect/tests/unit/test_sandbox_metadata.js
 0:02.81 LOG: Thread-1 INFO js/xpconnect/tests/unit/test_sandbox_metadata.js | full command: ['/usr/bin/lldb', '--', '/Users/froydnj/src/m-c.hg/obj-x86_64-apple-darwin14.1.0/dist/Nightly.app/Contents/MacOS/xpcshell', '-g', '/Users/froydnj/src/m-c.hg/obj-x86_64-apple-darwin14.1.0/dist/Nightly.app/Contents/Resources', '-a', '/Users/froydnj/src/m-c.hg/obj-x86_64-apple-darwin14.1.0/dist/Nightly.app/Contents/Resources', '-r', '/Users/froydnj/src/m-c.hg/obj-x86_64-apple-darwin14.1.0/dist/Nightly.app/Contents/Resources/components/httpd.manifest', '-m', '-s', '-e', 'const _HTTPD_JS_PATH = "/Users/froydnj/src/m-c.hg/obj-x86_64-apple-darwin14.1.0/dist/Nightly.app/Contents/Resources/components/httpd.js";', '-e', 'const _HEAD_JS_PATH = "/Users/froydnj/src/m-c.hg/testing/xpcshell/head.js";', '-e', 'const _TESTING_MODULES_DIR = "/Users/froydnj/src/m-c.hg/obj-x86_64-apple-darwin14.1.0/_tests/modules/";', '-f', '/Users/froydnj/src/m-c.hg/testing/xpcshell/head.js', '-p', '/var/folders/jb/9d5yt9v5701b_0qdpvh8bxkm0000gn/T/tmpt1goVn', '-e', 'const _SERVER_ADDR = "localhost"', '-e', 'const _HEAD_FILES = [];', '-e', 'const _TAIL_FILES = [];', '-e', 'const _JSDEBUGGER_PORT = 0;', '-e', u'const _TEST_FILE = ["/Users/froydnj/src/m-c.hg/obj-x86_64-apple-darwin14.1.0/_tests/xpcshell/js/xpconnect/tests/unit/test_sandbox_metadata.js"];', '-e', u'const _TEST_NAME = "js/xpconnect/tests/unit/test_sandbox_metadata.js"', '-e', '_execute_test(); quit(0);']
 0:02.81 LOG: Thread-1 INFO js/xpconnect/tests/unit/test_sandbox_metadata.js | current directory: u'/Users/froydnj/src/m-c.hg/obj-x86_64-apple-darwin14.1.0/_tests/xpcshell/js/xpconnect/tests/unit'
 0:02.81 LOG: Thread-1 INFO js/xpconnect/tests/unit/test_sandbox_metadata.js | environment: ['XPCOM_DEBUG_BREAK=stack-and-abort', 'MOZ_DISABLE_NONLOCAL_CONNECTIONS=1', 'XPCSHELL_TEST_TEMP_DIR=/var/folders/jb/9d5yt9v5701b_0qdpvh8bxkm0000gn/T/tmpBR9KwV', 'DYLD_LIBRARY_PATH=/Users/froydnj/src/m-c.hg/obj-x86_64-apple-darwin14.1.0/dist/Nightly.app/Contents/MacOS', 'MOZ_CRASHREPORTER_NO_REPORT=1', 'XPCSHELL_TEST_PROFILE_DIR=/var/folders/jb/9d5yt9v5701b_0qdpvh8bxkm0000gn/T/tmpN4CF1b']
(lldb) target create "/Users/froydnj/src/m-c.hg/obj-x86_64-apple-darwin14.1.0/dist/Nightly.app/Contents/MacOS/xpcshell"
Current executable set to '/Users/froydnj/src/m-c.hg/obj-x86_64-apple-darwin14.1.0/dist/Nightly.app/Contents/MacOS/xpcshell' (x86_64).
(lldb) settings set -- target.run-args  "-g" "/Users/froydnj/src/m-c.hg/obj-x86_64-apple-darwin14.1.0/dist/Nightly.app/Contents/Resources" "-a" "/Users/froydnj/src/m-c.hg/obj-x86_64-apple-darwin14.1.0/dist/Nightly.app/Contents/Resources" "-r" "/Users/froydnj/src/m-c.hg/obj-x86_64-apple-darwin14.1.0/dist/Nightly.app/Contents/Resources/components/httpd.manifest" "-m" "-s" "-e" 'const _HTTPD_JS_PATH = "/Users/froydnj/src/m-c.hg/obj-x86_64-apple-darwin14.1.0/dist/Nightly.app/Contents/Resources/components/httpd.js";' "-e" 'const _HEAD_JS_PATH = "/Users/froydnj/src/m-c.hg/testing/xpcshell/head.js";' "-e" 'const _TESTING_MODULES_DIR = "/Users/froydnj/src/m-c.hg/obj-x86_64-apple-darwin14.1.0/_tests/modules/";' "-f" "/Users/froydnj/src/m-c.hg/testing/xpcshell/head.js" "-p" "/var/folders/jb/9d5yt9v5701b_0qdpvh8bxkm0000gn/T/tmpt1goVn" "-e" 'const _SERVER_ADDR = "localhost"' "-e" "const _HEAD_FILES = [];" "-e" "const _TAIL_FILES = [];" "-e" "const _JSDEBUGGER_PORT = 0;" "-e" 'const _TEST_FILE = ["/Users/froydnj/src/m-c.hg/obj-x86_64-apple-darwin14.1.0/_tests/xpcshell/js/xpconnect/tests/unit/test_sandbox_metadata.js"];' "-e" 'const _TEST_NAME = "js/xpconnect/tests/unit/test_sandbox_metadata.js"' "-e" "_execute_test(); quit(0);"
(lldb)

Maybe log.warn would make it more visible by color-coding it differently.

Or can we make those (lldb) bits (which I didn't realize were there until I looked closely!) execute quietly?
Attachment #8590444 - Flags: review?(nfroyd) → review+

Comment 25

3 years ago
Yeah, log.warn outputs a couple of words in blue in my terminal, but I agree that this is not very discoverable.  Unfortunately I don't know how to make lldb not spew this stuff either. :/

Comment 26

3 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/862ac6c31d45

Leaving the bug open in the interest of people being able to find it later...
Keywords: leave-open
https://hg.mozilla.org/mozilla-central/rev/862ac6c31d45
https://hg.mozilla.org/mozilla-central/rev/7fa4c107be50
You need to log in before you can comment on or make changes to this bug.