Debugging PRE_ browser tests and --single_process

[Lutz Justen]

How can browser tests with PRE_ tests be debugged?

The Debugging section in https://www.chromium.org/developers/testing/browser-tests suggests to use --single_process, but warns "Running more than one test will likely result in undefined behavior because the test fixture does not attempt to reinitialize any global state.". Now, tests that have PRE_ tests in fact consist of multiple tests. I guess I can pre-run the PRE_ tests without debugging and run the actual test separately, but can we do better than that?

Another issue is that running multiple tests with --single_process actually crashes (see this bug), so the wording "result in undefined behavior" is a bit weak.

[Alexei Svitkine]

For debugging renderers, we have a --renderer-startup-dialog - which allows you to attach a debugger to the renderer before going further.

It sounds like something similar could be useful to add for attaching to the browser process in browser tests?

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAFb54no%2Bvn878tvUso757Sr6U%2BwOT7b6cg6yxMCY9yhDd6BNxQ%40mail.gmail.com.

[Stefan Zager]

--single_process is bad news. It leads to subtle behavioral differences, and I don't think it's maintained.

I think there's another flag that prevents the test framework from forking the browser process; I can't remember what the flag is. If you do that, then you can just start gdb on the test binary and debug the browser right there.

For debugging a render process, you probably want to add:

--renderer-startup-dialog --no-sandbox --disable-hang-monitor --ui-test-action-max-timeout=99999999 --test-launcher-timeout=99999999

... and run the test executable normally (not in gdb). You should get a message to the console with a PID every time a render process forks. You can attach to that process in gdb, and then `kill -s SIGUSR1 <renderer pid>` to continue execution after attaching.

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.

[Scott Violet]

PRE_ basically means run the test *don't* delete the user-data-directory, and when starting the next test reuse the user-data-directory from the previous test. It should be possible to simulate this behavior yourself. That said, I think the easiest way for you to accomplish what you're after is to insert a WaitForDebugger() in the non-PRE test and then attach.

  -Scott

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAHOQ7J8tpWfo%2BVgB-XLpAhz5nOKBXGSiYwSeXjOQrNMYx2y0kw%40mail.gmail.com.

[Erik Chen]

+ isam...@google.com

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAKARY_mA2ch_LgMSkgZ1FXDKoydCC8tWdUC8%2BXWjuBM4bwkjXg%40mail.gmail.com.

[Lutz Justen]

Would it make sense to update the documentation to remove the mention of single_process and recommend WaitForDebugger() instead?

[Stefan Zager]

On Wed, Mar 27, 2019 at 9:14 AM Lutz Justen <lju...@chromium.org> wrote:

Would it make sense to update the documentation to remove the mention of single_process and recommend WaitForDebugger() instead?

I'm not sure there's consensus on the usefulness, or lack thereof, of --single_process. But the documentation should probably at least have a caveat along the lines of: "--single_process is known to occasionally cause side effects that may get in the way of debugging. In that case, try using WaitForDebugger() instead."

[Alexei Svitkine]

Given that --single_process has known problems, +1 to suggesting WaitForDebugger() instead.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAHOQ7J-kWCsUATL5asgQb%3D7Wfv_wex7TRMGofk6%2Bq71CcSWPYA%40mail.gmail.com.

[Peter Kasting]

On Wed, Mar 27, 2019 at 9:14 AM Lutz Justen <lju...@chromium.org> wrote:

Would it make sense to update the documentation to remove the mention of single_process and recommend WaitForDebugger() instead?

No.  I think people on this thread are confusing --single_process with --single-process.  (Understandably.)

--single_process just causes the browser tests to be run in the same process as the test harness.  It's a well-supported switch and a critical piece of debugging browser tests; please do not remove the instructions saying to use it.

--single-process runs Chrome itself in single process mode, and is the thing that's technically unsupported and can cause problems.  Luckily it's not usually necessary to debug browser tests.

If there is any change to be made here, it's in renaming one or both of these switches so they don't sound like they're the same.  I believe some places we use --single-process-tests instead of --single_process?

PK

[John Abd-El-Malek]

I think Stefan is referring to --single-process, not --single_process. Note we do have tests for this, but it wouldn't help in this case anyways because PRE_ tests need to run the browser process twice which can't happen in a single process.

--single_process wouldn't help the PRE_ tests, as we can't run more than one browser test in the same process.

Per Scott's comments, the way to debug a test that uses PRE_ is to first run the first part, e.g.

browser_tests --single_process --gtest_filter=Foo.PRE_BAR --user-data-dir=/tmp/foo

browser_tests --single_process --gtest_filter=Foo.BAR --user-data-dir=/tmp/foo

and you can attach to either one like a normal browser test.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAKFU2SBzovEHENVz4cVW2b-KGsJiL6hShF62H3KdnXE-6VOjbA%40mail.gmail.com.