Closed Bug 818301 Opened 7 years ago Closed 1 year ago

make JimDB work with C++ unit tests

Categories

(Firefox for Android :: JimDB, defect)

x86
macOS
defect
Not set

Tracking

()

RESOLVED INACTIVE

People

(Reporter: dmose, Assigned: jchen)

Details

(Whiteboard: [android-dev-pain])

Jim and I spent some time today trying to make JimDB debug a C++ unit test on Android, ultimately not (yet!) succeeding.  It'd be extremely nice if this could Just Work.

As a potential strategy, it appears that testing/xpcshell/remotexpcshelltests.py has undocumented hooks for gdb, and making JimDB work with them might be a good way to some infrastructure for free.

On a related note, there's a non-xpcshell C++ remote testing harness that's currently in progress in bug 811411, and once this works with the xpcshell tests, it shouldn't be hard for me or Ted or someone to incorporate over there.
Whiteboard: [android-dev-pain]
I updated the feninit script to include the ability to run C++ unit tests. The new version can be downloaded by running 'git pull' under the utils directory.

The script now asks the user to choose whether to debug Fennec or to debug a test. If debugging a test, the script first launches Fennec in extract libraries mode to get copies of .so files (libxul.so, etc.). It then pushes the test to the device and launches the test with gdbserver using the appropriate method. Symbol paths are set accordingly. Finally, any output from the test is redirected to the terminal running gdb.

So far I've only tested tests such as TestHashtables, TestAutoPtr, etc.
Status: NEW → ASSIGNED
OK, so far this is looking great!  It's now very simple to actually start debugging a unit test, which is a big change.

Two very minor wrinkles I ran across:

* I was expecting the path that feninit wanted to be relative to the top-level of the objdir.  For whatever reason, my build doesn't have tab completion, so it was hard to figure out what was desired.  I just ended up using the absolute path.

* Some of the tests we've got need a special magic environment variable to be set in order to run (MOZ_WEBRTC_TESTS=1).  I ended up just hand-hacking feninit.py to make that happen; it'd be less if there were an explicit hook (maybe via the gdbinit?) to set that.
s/less/nicer/
(In reply to Dan Mosedale (:dmose) from comment #2)
> OK, so far this is looking great!  It's now very simple to actually start
> debugging a unit test, which is a big change.

Thanks for testing and for the suggestions!

> Two very minor wrinkles I ran across:
> 
> * I was expecting the path that feninit wanted to be relative to the
> top-level of the objdir.  For whatever reason, my build doesn't have tab
> completion, so it was hard to figure out what was desired.  I just ended up
> using the absolute path.

The path is relative to $objdir/dist/bin, so you can just enter Test... I added a clearer explanation at the prompt. I'll look into why tab completion might not work.

> * Some of the tests we've got need a special magic environment variable to
> be set in order to run (MOZ_WEBRTC_TESTS=1).  I ended up just hand-hacking
> feninit.py to make that happen; it'd be less if there were an explicit hook
> (maybe via the gdbinit?) to set that.

I added the ability to specify environmental variables at the prompt and added an explanation. Also added a setting in gdbinit to specify default variables.

git pull and try it out!
I tried this out and it worked great -- good stuff!

One concern I have is that the jimdb support is entirely separate from remotecppunittests.py (bug 811411). remotecppunittests.py pushes files, sets environment variables, etc, and might do so in a slightly different way than jimdb. So people might use a make target or remotecppunittests.py to initially run a test, experience a problem, then run jimdb to debug and find that the test behaves differently. 

Would it be possible for jimdb to leverage remotecppunittests.py, so that the setup stays in sync?
Yes, this fix has been wonderful.  It's made the workflow so much nicer.

There is something to the setup-code sharing idea, as I'm seeing these sorts of spew when using JimDB on unit tests.  They'd be confusing to someone who didn't realize that they often don't matter:

out> WARNING: NS_ENSURE_TRUE(greD) failed: file ../../../dist/include/testing/TestHarness.h, line 231
out> Warning: MOZILLA_FIVE_HOME not set.
out> WARNING: NS_ENSURE_SUCCESS(rv, __null) failed with result 0x80004005: file ../../../dist/include/testing/TestHarness.h, line 176
out> WARNING: NS_ENSURE_TRUE(profD) failed: file ../../../dist/include/testing/TestHarness.h, line 218
out> WARNING: Error parsing GRE default preferences. Is this an old-style embedding app?: file /Users/dmose/r/inbound/src/modules/libpref/src/Preferences.cpp, line 1066

Given the existence of bug 822786 (make JimDB work with mochitests), perhaps this shared code actually wants to live somewhere else in mozbase?  Or is it unlikely to be shared "enough" across the different sorts of test suites?
Having JimDB invoked from remotecppunittests.py and the mochitest framework, similar to the way <http://mxr.mozilla.org/mozilla-central/source/testing/xpcshell/remotexpcshelltests.py#39> appears to work might also be a good solution here.
Status: ASSIGNED → RESOLVED
Closed: 1 year ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.