- 02 Jan, 2021 1 commit
-
-
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 4 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
-
Nils Goroll authored
it does not need many worker threads and runs for >30s. This helps being able to run this test with more concurrency to test #3362
-
Guillaume Quintard authored
-
- 10 Dec, 2020 3 commits
-
-
Nils Goroll authored
... thinks this statement is confusing. Ref: 15f94d33
-
Nils Goroll authored
VRT_new_backend_clustered() is the only caller of VBP_Insert(). There, VBP_Update_Backend() needs to be called after the director is created in order to update the director status for a cold VCL. For a warm VCL, VBP_Update_Backend() is called via VRT_AddDirector() -> VDI_Event() -> vbe_dir_event() -> VBP_Control() Thus, the additonal call before the director is added to the backend, does not do anything but update the poll bits. Somehow related to #3362
-
Dridi Boukelmoune authored
We don't need to assert the integrity of the VSB after every single byte, it can become very expensive depending on the workload.
-
- 09 Dec, 2020 3 commits
-
-
Guillaume Quintard authored
-
Nils Goroll authored
Ref 001485e6
-
Dridi Boukelmoune authored
Going back to lowercase, and aligning code blocks to 4 spaces to match the rest of the code snippets.
-
- 07 Dec, 2020 6 commits
-
-
Nils Goroll authored
Ref #3470
-
Nils Goroll authored
Ref #3470
-
Nils Goroll authored
Fixes #3478
-
Nils Goroll authored
When resolve requests race, we were not guaranteed to consider all backends because we updated a shared nxt variable. Fixes #3474
-
Nils Goroll authored
-
Nils Goroll authored
... also (C)ompleted bans. The previous code made a lot of sense in light of the performance issue due to too many bans, but would not work to prune a long ban list due to (R)equest bans at the tail, as in this example: Present bans: 1607346873.538879 354304 C 1607346873.532313 0 C ... lots of (C)ompleted bans 1607083561.980118 0 - req.http.Host ~ foo 1607083561.972629 15 C The documentation does not mention the previous behavior (that only "active" bans are being counted), so this changes aligns code to documentation.
-
- 03 Dec, 2020 5 commits
-
-
Nils Goroll authored
-
Nils Goroll authored
-
Nils Goroll authored
-
Poul-Henning Kamp authored
This introduces a `PAN_dump_struct` function to do the standard up-front checks for NULL, bad magic & already dumped.
-
Poul-Henning Kamp authored
vtc_haproxy: VTCP_listen_on 127.0.0.1 instead of localhost Always bind vtc_haproxy with 127.0.0.1 instead of binding on ::1 or 127.0.0.1 depending on the environment. This is related to bug https://github.com/haproxy/haproxy/issues/937 here the ipv6 and ipv4 are randomly mixed which can't work with socks4.
-
- 02 Dec, 2020 2 commits
-
-
Nils Goroll authored
-
Dridi Boukelmoune authored
And wrap the logic in a macro to reduce duplication.
-