-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Possible race condition with -j and lots of quick tests #98
Comments
Are you able to get a core-dump / backtrace for the crashing zeek process? What Zeek version is it? Is this a plugin or package being tested? Could you share the values of ZEEK_PLUGIN_PATH / ZEEKPATH used during testing and possibly the concrete directory layout when running the tests. The reason is the following (pure) speculation: If you have a liberal/open This doesn't fully align with the output you show, but I'd not read too much into the progress output when possibly intermingled. EDIT: May also need to consider existence of symlinks. |
Your speculation is on target. It's due to the default
If I change that to instead hardwire I really have to wonder about the wisdom of the unlimited directory traversal for locating plugins, this has bitten me in the past, too (when I had saved a previous I can easily fix this point-wise since this particular package doesn't even have any plugins, so no need for the fancier |
This is at least partially my fault :-) so let me chime in here. I feel bad because
|
I forgot to add: I see no reason for Zeek to traverse into dot directories, though. This would naturally exclude things like |
Cool, yes, let's get the template fixed for not generating that I like the idea of changing |
I don't really remember much about that choice, but yeah, somewhere in that ballpark; along probably with an early (naive) thinking of "how deep can directories holding plugins really get ...". At this point, I'd be mostly worried about breaking setups if we change how this works (but I agree on the dot directories; and in princinple also on the globs, though not sure if that's really worth the effort in the end). |
Dot directories rarely contain anything we would want to load as a dynamic plugin. Even worse, they likely contain files with externally controlled lifetimes which might be removed while we are using them (see e.g., zeek/btest#98). With this patch we do not search _discovered_ dot directories anymore. We continue to load from a user-specified `ZEEK_PLUGIN_PATH`, even if its name starts with a dot. Since this patch changes previous behavior it is a **BREAKING CHANGE**. Closes zeek/btest#98.
Dot directories rarely contain anything we would want to load as a dynamic plugin. Even worse, they likely contain files with externally controlled lifetimes which might be removed while we are using them (see e.g., zeek/btest#98). With this patch we do not search _discovered_ dot directories anymore. We continue to load from a user-specified `ZEEK_PLUGIN_PATH`, even if its name starts with a dot. Since this patch changes previous behavior it is a **BREAKING CHANGE**.
Closing after merging @bbannier PR to exclude dot directories from the recursive search. |
I'm using
btest
1.1 (on macOS Ventura) in a directory with a lot (~50) of quick-executing tests, each reading a PCAP. Most of the time they succeed, but every few runs there's a failure like this:Note that here test
FOO
is failing, but the actual .stderr complaint is about a different testBAR
. If I use-t
to keep all the temporary directories, theBAR
directory is in fact present, at least whenbtest
finishes.Across repeated runs, both
FOO
andBAR
vary, so this doesn't appear to be an issue with the actual tests. In addition, if I run serially, or with a low-j 5
setting, I'm unable to make the problem occur. Both of these point to some sort of race condition when creating the.tmp/
subdirectories.Let me know if there's more I can provide to help diagnose this.
The text was updated successfully, but these errors were encountered: