- 27 Jun, 2021 1 commit
-
-
Dridi Boukelmoune authored
On a loaded system the delay may not be enough, a barrier should.
-
- 24 Jun, 2021 2 commits
-
-
Dridi Boukelmoune authored
Spotted by flexelint.
-
Dridi Boukelmoune authored
Better diff with the --ignore-all-space option.
-
- 23 Jun, 2021 4 commits
-
-
Dridi Boukelmoune authored
-
Dridi Boukelmoune authored
With a non-deterministic `expect * * ...` the logexpect thread would never consider itself to be done if the vtc ends if one entry was not seen in the vsl.
-
Dridi Boukelmoune authored
A failing test may take up to the vtc timeout to effectively fail if a thread is waiting for a barrier to sync. Barriers now check every 100ms whether the vtc is done to bail out. The socket barriers were already polling for 1s, so now they poll for 100ms and leave the loop early when needed. The condvar barriers now loop over a timedwait, but critical sections were too wide. There were vtc_fatal() calls under barrier locks that would defeat the timedwait loop. Thus critical sections were more carefully laid, allowing multiple barrier commands to run simultaneously. This also means that besides initialization, socket barriers no longer touch the lock. Consider the following diff: --- bin/varnishtest/tests/v00056.vtc +++ bin/varnishtest/tests/v00056.vtc @@ -72,7 +72,7 @@ client c2 { } -run logexpect l2 -v v1 -g raw -q Backend_health { - expect 0 0 Backend_health "default Went healthy" + expect 0 0 Backend_health "default Went wrong" } -start barrier b3 sync With this change l2 would fail early, typically in less than 2s, but the barriers stuck in a condwait would prevent further progress.
-
Guillaume Quintard authored
-
- 22 Jun, 2021 3 commits
-
-
Dridi Boukelmoune authored
Latch the barrier _after_ reading resp.is_streaming.
-
Dridi Boukelmoune authored
It is possible to see the session close after the second request after timeout_linger triggered.
-
Dridi Boukelmoune authored
It started failing out of the blue and it's not obvious why.
-
- 21 Jun, 2021 3 commits
-
-
Dridi Boukelmoune authored
The probe timeout is irrelevant, especially under load. And to be certain, we can witness probe updates to ensure we are testing VCL with a system in the expected state.
-
Dridi Boukelmoune authored
Another case of non-deterministic log order.
-
Dridi Boukelmoune authored
-
- 18 Jun, 2021 2 commits
-
-
Guillaume Quintard authored
-
Dridi Boukelmoune authored
Errors may be logged out of order.
-
- 17 Jun, 2021 3 commits
-
-
Dridi Boukelmoune authored
See previous commit. Better diff with the --word-diff --word-diff-regex=. options.
-
Dridi Boukelmoune authored
I kept a variable called "s" to cut noise from the diff.
-
Dridi Boukelmoune authored
Except that we shouldn't start from expr0 since both use cases clearly need expr4 parsing. Instead of making assumptions based on the type in expr0, we split the final expression type check in its own function and use it to confirm that we are matching a regex or an acl. Fixes #3628
-
- 14 Jun, 2021 3 commits
-
-
Dridi Boukelmoune authored
It works like the hash_ignore_busy flag: it is disabled by default and survives a restart, but as the name implies will skip vary checks for object candidates.
-
Nils Goroll authored
When a regex match failed with a hard error (anything which is not just a "no match"), we would log a VCL_Error but otherwise just fail the match. Thus, such failures were likely go remain unnoticed, which could have serious implications in particular with negated matches. Ref 6c663836
-
Poul-Henning Kamp authored
Spotted by: Coverity
-
- 13 Jun, 2021 1 commit
-
-
Federico G. Schwindt authored
Fixes: In file included from vev.c:36: /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/pthread.h:328:6: error: macro expansion producing 'defined' has undefined behavior [-Werror,-Wexpansion-to-defined] #if !_PTHREAD_SWIFT_IMPORTER_NULLABILITY_COMPAT ^ /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/pthread.h:197:2: note: expanded from macro '_PTHREAD_SWIFT_IMPORTER_NULLABILITY_COMPAT' defined(SWIFT_CLASS_EXTRA) && (!defined(SWIFT_SDK_OVERLAY_PTHREAD_EPOCH) || (SWIFT_SDK_OVERLAY_PTHREAD_EPOCH < 1))
-
- 11 Jun, 2021 5 commits
-
-
Nils Goroll authored
We tweak down the defaults on 32bit platforms, restore them to the 64bit defaults
-
Nils Goroll authored
that was a stupid mistake
-
Nils Goroll authored
-
Nils Goroll authored
This test had been disabled before to reduce the maintenance burdon, but I think it really should be possible to find a regex & pattern to reliably run into PCRE_ERROR_RECURSIONLIMIT / PCRE_ERROR_JIT_STACKLIMIT. And it seems that the work to find such a regex & pattern had already been done for us. :) Looking after the test made me realize that we really should consider latching VCL failure for "hard" pcre errors. This commit is to have a diff in the git log, the next commit will activate the test.
-
Nils Goroll authored
-
- 10 Jun, 2021 13 commits
-
-
Nils Goroll authored
This is from before the introduction of workspace overflow detection. Since then we would never silently process failing string assembly.
-
Nils Goroll authored
we test chunked + streaming and gzip + streaming in a number of vtcs since the do_stream default has been changed to true. And, yes, these vtcs do succeed.
-
Nils Goroll authored
-
Nils Goroll authored
cc cannot -Wformat-y2k cc1: warning: -Wformat-y2k ignored without -Wformat [-Wformat-y2k] cc cannot -Wformat-zero-length cc1: warning: -Wformat-zero-length ignored without -Wformat [-Wformat-zero-length]
-
Dridi Boukelmoune authored
The two options can't be mixed together and we should ensure that only the options we decided to support can be passed along, preventing bit smuggling. For a full PCRE spectrum, VMODs can directly use a PCRE library through its API.
-
Nils Goroll authored
Fixes #3624
-
Nils Goroll authored
... to have a solid baseline
-
Nils Goroll authored
The explicit catch on CalledProcessError will be used in a follow up commit to ensure that python errors do not stay unnoticed. Ref #3624
-
Nils Goroll authored
... to make our SunOS vtest build happy again ld: fatal: file /opt/local/lib/libpcre.so: wrong ELF class: ELFCLASS64 ld: fatal: file processing errors. No output written to vjsn_test collect2: error: ld returned 1 exit status The issue here was order of the -L -l arguments when a (32bit) version of a library needs to be found first in an overridden LDPATH. Ref 12bbe31f Ref #3559
-
Dridi Boukelmoune authored
We might want to do something about it once pcre2 is in place, but it should be noted that concurrent matches on a vre_t could compete over the limits we can tweak. Refs #3559
-
Dridi Boukelmoune authored
It's more helpful than printing the invalid regular expression, that's how the spurious "\T" was spotted.
-
Dridi Boukelmoune authored
It is interpreted as "T" by pcre but pcre2 is stricter and treats it as a syntax error. While there may be a bit flag to ignore unknown escape sequences, it is probably worth hardening instead. Refs #3559
-
Dridi Boukelmoune authored
To make sure it is always readily available without an extra step, and that it doesn't rot away missing build flags or triggerring developer warnings like GCC's -Wtautological-constant-out-of-range-compare.
-