Death tests, sqlite exclusive locking, and best practices

[Daniel Cheng]

Recently, I learned about http://crbug.com/380903149: the tl;dr here is:

• Chrome uses some sqlite databases, ideally with exclusive locking for improved performance (I don't know the details here :)
• death tests internally fork
• but since the parent has the exclusive lock, the child process can't use the table and things go off the rails / tests fail due to action at a distance

The current workaround seems to be opening databases in non-exclusive mode, e.g. like cookies and history.

Unfortunately, it seems that exclusive locking and death tests are incompatible here, and I don't have a lot of good suggestions on how to resolve this. Fundamentally, a browser test hosts the browser process and the test logic in the same process, and a lot of the usual "browser stuff" is initialized/used by the time the test logic is running. So even something like lazily opening resources doesn't really work, because the resources in question are probably already in use by the time execution reaches EXPECT_DEATH(). Even "unit" tests are problematic for the same reason–by the time the actual test logic runs, a lot of stuff is initialized (and potentially opened in exclusive locking mode). This leaves a fairly limited set of options:

• Just don't support death tests. This seems infeasible; while we could ban death tests in browser tests, we use death tests a lot in unit tests and people generally expect that to work
• Just don't use exclusive locking: this is the current state of the world
• Only use exclusive locking outside tests, i.e. have some helper that can detect if we're in (death) tests and avoid exclusive locking in that mode.

All of these options seem a bit unpalatable. I suspect the last can probably be implemented with some coordination with the test runner :) jdh@ / rtarpine@ or any other sqlite experts: how much performance do we gain from using exclusive locking?

Daniel

[Elly]

Perhaps there is some nonsense one can do using pthread_atfork() to drop locks? However, the problem with that (and the "just don't use exclusive locking" / "just don't use exclusive locking in tests") approach is that the data might be in an inconsistent state if you do, which could be very bad.

I would lean towards not supporting death browser tests, because it's just not safe for the browser process to fork() like that and it seems like a huge nest of problems.

-- elly

--
You received this message because you are subscribed to the Google Groups "cxx" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cxx+uns...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CAF3XrKqt53cewEV5UWx0bCntPUebYYwqQZ5A90Yu7Z84OQt%2B8A%40mail.gmail.com.

[Ryan Tarpine]

(Resending from my chromium account so it actually reaches platform-architecture-dev)

On Wed, Mar 26, 2025 at 12:52 PM Ryan Tarpine <rtar...@google.com> wrote:

We haven't tested the performance ourselves, but the sqlite docs say:

There are three reasons to set the locking-mode to EXCLUSIVE.

1. The application wants to prevent other processes from accessing the database file.
2. The number of system calls for filesystem operations is reduced, possibly resulting in a small performance increase.
3. WAL databases can be accessed in EXCLUSIVE mode without the use of shared memory.

They don't seem to expect much of an improvement. (But we haven't tested it.)

But I want to suggest a fourth possible solution: can we modify the death test logic somehow to run the child process with a different user data dir? I played around with this a bit a few months ago, and realize it would need some upstream changes to GoogleTest to allow the test runner to modify the command line args passed to the child, but that seems ideal to me. If any tests depend on two Chrome processes using the same dir at the same time, that's presumably unintended and should be fixed anyway.

[Ryan Tarpine]

I believe our tests on Mac and Linux are also re-running the test from the beginning, not forking. This might be the line that makes that happen.

The problem is that the parent process and the child process are running at the same time with the same user data dir. The parent process doesn't exit when the child runs, so it has the exclusive lock when the child attempts to grab it.

It's a problem on all platforms.

On Wed, Mar 26, 2025 at 2:06 PM Joe Mason <joenot...@google.com> wrote:

Do the death test failures happen the same way on Mac/Linux and Windows? IIUC, Windows doesn't fork, it re-runs the test from the beginning in the child process and takes a different path through the test. So I don't think it would have the same problem unless death tests are running simultaneously.

https://crbug.com/380903149 suggests setting a different `--user-data-dir` in death test child processes, which might help with the Windows approach since the whole setup runs again in the child process.

Is it possible to force gtest on other platforms to use the Windows death test approach instead of fork-and-continue?

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CADpj5ozLQLgUvc6SSHq0AY7xqv129SVdB8qJZq5wEKL7SoA3Vg%40mail.gmail.com.

[Daniel Cheng]

If we want to change the --user-data-dir flag in the child process, we need some way of knowing if we were the child or parent process. Googletest does know that, but I don't think that information is publicly-exposed or easy to extract.

Another possibility that doesn't require upstream changes is to require the convention of having DeathTest as a suffix of the suite name or test name, and then our test launcher would provide hooks to do things differently in one mode vs another. Though I feel like I'd still prefer "just" relaxing the exclusive locking requirement in death tests rather than silently switching out the user data dir. That seems like a recipe for potential surprises...

Daniel

[John Admanski]

I believe the intended way to determine if you're the child process is that if you're in the statement that was given to the EXPECT_DEATH macro, you're in the child process. Otherwise it's indeterminate. I suspect that adding a mechanism to allow tests to "run differently" in the child process would elicit a "you're doing it wrong" response.

That doesn't mean you couldn't implement it such a thing directly. Instead of using EXPECT_DEATH, the test could do the fork+exec itself, adding/injecting additional arguments to the child process to adjust the behavior appropriately. I wouldn't personally recommend it as a solution, but if that was truly the behavior you needed then doing it directly yourself (and as a consequence making the subtlety of what's being done more obvious to anyone reading the test) is probably the way to go.

[Daniel Cheng]

Right—obviously `EXPECT_DEATH()` knows this, somehow. But I don't think varying behaviour between parent/child is the right path here (and not to mention, we can't really fork() anyway; I misspoke earlier), hence the suggestion of using naming convention to allow certain parts of the codebase to relax restrictions that would otherwise break tests.

Daniel

[John Admanski]

More generally, I suppose any solution that involves going through and reworking every death test is probably not something that scales well enough? None of the bugs and crs linked in the thread really make it clear the scale of the problem, e.g. are there 10 failing tests to deal with or 1000.

[Daniel Cheng]

There's a lot of random death tests in unit tests that probably run into these sorts of issues. I'm not proposing a fix for each test for the sqlite issue; just a sqlite helper somewhere that "opens with exclusive locks except when running a death test (whether parent or child)". There might be other classes of problems this doesn't help with of course, but it seems good enough for sqlite since exclusive locking seems more like a performance optimization than anything else.

Daniel

[Andrew Williams]

Note that there is a precedent for changing the behavior of code in the death test child process, specifically the following that makes death tests significantly faster and less flaky on most platforms: https://source.chromium.org/chromium/chromium/src/+/main:base/test/test_suite.cc;l=536-547;drc=c82cbc9792face8cc3fdd2d90330e4e07368f55b

-Andrew

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CAF3XrKroW4_MAb8%3Drus9q_PJGp44Jbvgu8jDL7X2Ex2_jLyHVg%40mail.gmail.com.

[David Benjamin]

Silly question: How does user-data-dir work in a browser test anyway? Naively I would have assumed that different runs of a test generate fresh user-data-dirs, or they would interfere with each other. In that case, why doesn't the child run (assuming we are indeed using the non-fork mode) end up with a different directory from the parent run?

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CAEa0%2BkWiL0s3i%2BdzrtEJZL0QoTOpg1HzUgksPx20GoKHtKnCVQ%40mail.gmail.com.

[Ryan Tarpine]

Every browser test is normally run with a fresh user-data-dir. But death tests are handled deep in GoogleTest which simply starts the child process with the exact same command line args as the parent.

To me, the ideal solution here is to let the parent modify the args used to start the child, so it can pass a new user-data-dir. That seems safe to me, does anyone have concerns with that?

I'm going to look into it.

Ryan

[David Benjamin]

Hmm. I guess what puzzles me is that we don't pass --user-data-dir to browser_tests or anything. I... assume *something* in the test fixture is setting up a profile directory in a temporary directory or something for each test. Would the gtest child not rerun that logic and get a new temporary directory?

On Fri, Mar 28, 2025, 11:53 Joe Mason <joenot...@google.com> wrote:

If it's hard to modify gtest, another option would be to detect the --test-child flag (or whatever exact flag death tests add) when parsing --user-data-dir and append a randomized nonce to the dirname.

[Peter Kasting]

I agree with Elly. We should just not support death browser tests. This is far from the only thing in the code that might break if multiple processes are simultaneously accessing the data dir. Working around by changing locking modes when testing means test and prod behavior silently diverge, which is a recipe for not catching subtle problems. If we must support these, we should do it by using different user data dirs for each process; but we use death tests rarely and they are really only appropriate at a unit test scope, so it seems easier and safer to just ban this (by not letting it compile, if possible).

PK

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CADpj5ozLQLgUvc6SSHq0AY7xqv129SVdB8qJZq5wEKL7SoA3Vg%40mail.gmail.com.

[Greg Thompson]

I pretty much agree. A browser death test doesn't make much sense to me. If we imagine that fork() was even possible, doing so takes us away from anything like a true browser process. If there is a need for a browser death test, then I think we should go to the drawing board and work out a way for the "parent" part of the test (the thing that launches the child, captures its output, and waits for it to crash) to do nothing more than launch the child. The child should *be* the browser proc that crashes. This wouldn't be very easy, but I think it's better than trying to make a regular browser test "just work" with a death expectation in it.

As for SQLite in death unit tests, I think this should be possible. We do have the smarts to know if we're running in the parent or the child.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CAAHOzFBRQ41xBsvv3mTosj6hh2XggeRjBJzhtfznqWiVHOPv8g%40mail.gmail.com.

[Ryan Tarpine]

I didn't write any of the existing browser death tests myself, but I think they are reasonable, as long as death_test_style is "threadsafe", which it is for Chromium -- except on Android. (I agree that the default forking behavior i.e. death_test_style=fast doesn't make sense for browser tests)

In the threadsafe mode, IIUC, the parent runs the test until it reaches the EXPECT/ASSERT_DEATH call, at which point it starts an independent child process which re-runs the test up to and then including that call. The parent then verifies that the child printed out something expected when it died.

I think this is exactly what we want?

The parent running the parts of the test outside of the expect/assert_death ensures that all other expectations/assertions pass.

Really I think the only problem is reusing the user data dir. And I have a draft CL to enable changing it in the upstream googletest framework -- with a followup CL to chromium, the parent can create a temporary dir for the child and clean it up after the test finishes.

Ryan

[Dave Tapuska]

Not to derail any conversation, but just want to add PSA... Please be sure to use EXPECT_DEATH_IF_SUPPORTED/ASSERT_DEATH_IF_SUPPORTED since GTEST can have death tests disabled or not supported on operating systems that don't support fork (like iOS).

You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to platform-architect...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CAJGRvUoRFxuo7HWEoWc80KNdm9Hm7%2Bw_T5tuCopahNLCg4%3DEvw%40mail.gmail.com.

[Greg Thompson]

Regarding "I think this is exactly what we want?" + "the only problem is reusing the user data dir": If I try to imagine why we would want to start browser A, do some work, then start browser B and expect it to crash, I guess it's because we want to do some setup work in browser A that will be used by browser B for the crash. If the two browsers use distinct user data dirs, then what sort of setup work could browser A really do for browser B? It seems to me that all of the work to start browser A is wasted, which slows down the tests. browser_tests runtime is a problem, so I think we should err on the side of reducing work.

How many browser death tests do we have? Is it small enough that they could reasonably be rewritten as unit tests?

[Ryan Tarpine]

You're right that the part of the test run twice is basically wasted time. Browser A can't do anything for Browser B. The main benefit is verifying that other assertions in the test do pass, though that would often be caught by the stderr output matcher anyway. It also lets you continue the test after the assert/expect_death call, though I don't see tests using that.

A quick search for "f:browsertest.cc$ case:yes DeathTest" finds just 6 tests. I don't know whether they can be rewritten as unit tests.

Ryan