- 07 Jan, 2021 9 commits
-
-
Dridi Boukelmoune authored
In practice, we only tweak vmod_debug's build for coverage purposes. Another option could be to have a VTC running vmodtool.py with various VCC inputs but we currently don't have test coverage for our python scripts.
-
Dridi Boukelmoune authored
That will hopefully not break macos this time. Refs 8b791930
-
Dridi Boukelmoune authored
We can't have more than one test suite if we put all VMODs in the same directory.
-
Dridi Boukelmoune authored
This would otherwise prevent VMODs from leaving in the same directory.
-
Poul-Henning Kamp authored
Now the TCP|UDS simply returns a conn_pool, which then becomes the primary handle.
-
Poul-Henning Kamp authored
-
Poul-Henning Kamp authored
-
Poul-Henning Kamp authored
-
Poul-Henning Kamp authored
-
- 06 Jan, 2021 4 commits
-
-
Nils Goroll authored
cache/cache_vrt.c 916 Warning 438: Last value assigned to variable 'berr' (defined at line 849) not used berr is intentionally NULLed to clarify that no dynamic value must stay alive after the BAN_Abandon() Ref 6eee0074
-
Nils Goroll authored
Ref https://github.com/varnishcache/varnish-cache/pull/3486#issuecomment-754019262 roadmap: v/ add std.ban*(), add implicit import std vcc aliases ban() to std.ban() (some concerns raised) v/ deprecated ban() without std. remove ban() without std.
-
Nils Goroll authored
from https://github.com/varnishcache/varnish-cache/pull/3486#pullrequestreview-561662742 as that ticket is closed now
-
Nils Goroll authored
The ban() vcl action adds bans like the ban CLI command, but has no facility for in-band error reporting. Errors are only reported to VSL. We add std.ban() as a replacement for ban() with identical semantics, but returning if the ban was successfully added. std.ban_error() is added to report the error, if any. We add v00009.vtc mirroring v00011.vtc, but with std.ban() replacing ban(). The test number was chosen to fill a gap close to v00011.vtc. Implementation: We change VRT_ban_string() to return any error or NULL for success. Where the error is not a constant string, we need to format it on the workspace. For workspace overflows, we need to fall back to canned constant error strings to ensure that the error case never appears as success.
-
- 05 Jan, 2021 6 commits
-
-
Poul-Henning Kamp authored
-
Poul-Henning Kamp authored
-
Poul-Henning Kamp authored
-
Nils Goroll authored
Pull out determining the privs head Re-use will come with a PR
-
Nils Goroll authored
pointed out by Dridi in #3486 introduced by /me in 6cf1138f
-
Poul-Henning Kamp authored
-
- 03 Jan, 2021 1 commit
-
-
Nils Goroll authored
Ref Coverity CIDs 1362617, 1362618, 1362624, 1362626
-
- 02 Jan, 2021 2 commits
-
-
Nils Goroll authored
Spotted by local Flexelint install on Linux
-
Nils Goroll authored
cache_varnishd.h already includes: - sys/socket.h - string.h Spotted by local Flexelint install on Linux
-
- 30 Dec, 2020 1 commit
-
-
Federico G. Schwindt authored
Apple's clang calls dsymutil(1) when -g is used, creating a <binary>.dSYM directory which breaks this test. As I haven't found a way to disable it just ignore this check if the directory is present.
-
- 29 Dec, 2020 3 commits
-
-
Nils Goroll authored
Ref CID 1400491
-
Nils Goroll authored
Ref CID 1430127, CID 1430118
-
Nils Goroll authored
3a5af972 enabled flexelint to complain about copying many bytes into a struct member declared as a single byte array (which it never was). warning addressed: proxy/cache_proxy_proto.c 469 Warning 669: Possible data overrun for function 'memcpy(void *, const void *, unsigned long)', argument 3 (size=988) exceeds argument 1 (size=1) [Reference: file proxy/cache_proxy_proto.c: lines 340, 348, 392, 401, 410, 439, 469]
-
- 28 Dec, 2020 5 commits
-
-
Nils Goroll authored
ref. coverity CID 1430125
-
Nils Goroll authored
-
Nils Goroll authored
We reported any PROXY connection failure as JUNK. Now we report the same reasons as for failing HTTP1 connections. Implmentation: SES_DeleteHS() asserts that the hs argument be negative (one of JUNK, CLOSE, TIMEOUT, OVERFLOW, EOF). HTC_RxStuff() may return OVERFLOW, JUNK, COMPLETE, EOF or TIMEOUT (or, instead of TIMEOUT, IDLE if the callback returned EMPTY). Because vpx_complete() only returns JUNK, OVERFLOW or MORE, using the HTC_RxStuff() return value for SES_DeleteHS() is safe if different from COMPLETE.
-
Nils Goroll authored
adds handling of HTC_S_JUNK
-
Nils Goroll authored
Coverity CID 1099620
-
- 23 Dec, 2020 2 commits
-
-
Nils Goroll authored
reported by coverity
-
Nils Goroll authored
This is to chase a new case of the watchdog off the leash
-
- 21 Dec, 2020 1 commit
-
-
Nils Goroll authored
more re-use coming up in a PR
-
- 16 Dec, 2020 3 commits
-
-
Nils Goroll authored
seen in vtest: ** l1 Waiting for logexp **** dT 1.477 **** l1 match| 1016 BogoHeader c Missing header name: : Header *** l1 expecting| expect * 1018 VCL_Error Bad header foo: /9 overtook /8
-
Nils Goroll authored
seen in vtest: ** top === server s1 -repeat 5 { ** s1 Starting server ---- s1 Server listen address (127.0.0.1 58150) cannot be resolved: bind(2) NB: I am not sure about this attempt
-
Nils Goroll authored
false negatives reported by vtest: ** top === logexpect l1 -wait ** l1 Waiting for logexp **** l1 match| 1005 VCL_use c vcl1 *** l1 expecting| expect 0 = ReqURL struct **** l1 err | 1005 ReqURL c /encode ---- l1 bad| expectation failed
-
- 15 Dec, 2020 1 commit
-
-
Nils Goroll authored
fixes #3485
-
- 11 Dec, 2020 2 commits
-
-
Nils Goroll authored
they are revealed by vbe_dir_event() on a warm event Fixes #3358
-
Nils Goroll authored
VBP_Control() asserts that, when the vcl is warm, probes are scheduled to run (that is, exist on the probe scheduling binheap) and not so when the VCL is cold. This is correct because any VCL events are guaranteed to be serialized by mgt. vbp_thread(), however, momentarily left probes removed from the binheap while scheduling a probe not holding vbp_mtx, which left a window for VBP_Control() to find an active probe not on the binheap. Both vbp_thread() and vbp_task() re-schedule the probe at hand. The former in case scheduling the task fails, and the latter to reschedule it at the right interval relative to the probe having finished. We now re-schedule the probe in vbp_thread() before adding a task to run it, which does not change anything about the above, and, in particular, keeps vbp_mtx free while adding the probe task. Yet it closes the race and thus fixes #3362 survived varnishtest -t 90 -n 10000 -j 200 -i tests/v00003.vtc
-