gnu: patch inotify-race tests to use Rust gdb breakpoints #9908
Conversation
|
Oh, not upstreamable form... I hope that this hack is last 2 |
|
At least there's only three GDB tests in the whole GNU test suite, these two and rm/r-root.sh which is even more problematic because it uses LD_PRELOAD and gdb. I am not sure how you would approach coming up with an upstream test for this one since its testing for an architecture that we don't have. |
|
I wonder if to think outside the box for these ones, instead of patching, we could come up with a new criteria for these types of tests, instead of SKIP its a "INCOMPATIBLE". or something similar. Something to indicate to the organizations relying on the GNU test compatibility metric to understand that there's a difference between skipping because uutils doesn't support it and skipping because the tests are implementation specific and are not compatible with the uutils implementation. |
|
I think |
|
I still want to keep leaving not compatible tests to the log. Someone saw them might find actual bugs/security issues from them. |
2 participants
This GNU test is a tough one because it references the source code directly to use GDB to set up a race condition and it is testing a race condition that architecturally the Rust implementation doesn't have.
It appears that the reason this test exists is because the GNU implementation performs the read before setting up the watchers, and the uutils implementation sets up the watchers before performing the read so the race condition does not exist. I tried to come up with the best "Equivelant" for where to point the gdb source to break on and came up with the
watcher_rx.watch_with_parentline in watch.rs since its the same equivalent of breaking before setting up the watcher.Its not to say the test isn't useful for regressions, if we do change the architecture to perform the reads before the watches, this test will make sure that we handle race conditions in that scenario.