- 26 Nov, 2019 2 commits
-
-
Nils Goroll authored
This originates from a3d47c25, but was overlooked in 4e333597: When there is insufficient space to fulfil the reservation request, we must not leave the workspace reserved. Fixes #3131
-
Nils Goroll authored
-
- 25 Nov, 2019 1 commit
-
-
Poul-Henning Kamp authored
-
- 22 Nov, 2019 5 commits
-
-
Dridi Boukelmoune authored
-
Dridi Boukelmoune authored
It's only ever used by base64.c, so we might as well put it there.
-
Dridi Boukelmoune authored
-
Dridi Boukelmoune authored
Better diff with the --ignore-all-space option.
-
Dridi Boukelmoune authored
This is a mechanical change that hides the const and restrict details of the codec contract in vmod_blob and makes the function signatures more manageable.
-
- 20 Nov, 2019 1 commit
-
-
Dridi Boukelmoune authored
Refs b0c0eaea
-
- 19 Nov, 2019 2 commits
-
-
Dridi Boukelmoune authored
I started suspecting that we need this clarification during the review of #3123 [1] and was able to verify it with a simple test case. First I needed a function I put in vmod_debug: $Function STRANDS hoard_strands(PRIV_TASK, STRANDS s) Return the first value of s for the rest of the task. The implementation is very straightforward: struct hoarder { VCL_STRANDS s; }; VCL_STRANDS xyzzy_hoard_strands(VRT_CTX, struct vmod_priv *priv, VCL_STRANDS s) { struct hoarder *h; CHECK_OBJ_NOTNULL(ctx, VRT_CTX_MAGIC); AN(priv); if (priv->priv == NULL) { h = malloc(sizeof *h); AN(h); h->s = s; priv->priv = h; priv->free = free; } return (priv->priv); } And then the following test case results in a panic on my system, but I suspect this is generally undefined behavior and other nasty results may occur under different circumstances: varnishtest "Beware of STRANDS" varnish v1 -vcl { import debug; backend be none; sub vcl_recv { debug.hoard_strands("recv: " + req.url); } sub vcl_miss { debug.hoard_strands("miss: " + req.url); return (synth(200)); } sub vcl_synth { set resp.body = debug.hoard_strands("synth: " + req.url); return (deliver); } } -start client c1 { txreq rxresp expect resp.body ~ recv } -run This also begs the following question: can it ever be safe to let a VMOD function return a STRANDS? Maybe it should be banned from return types. [1] https://github.com/varnishcache/varnish-cache/pull/3123#discussion_r345617108
-
Dridi Boukelmoune authored
Is it because German capitalizes so many words that his shift keys have become hit or miss?
-
- 18 Nov, 2019 10 commits
-
-
Nils Goroll authored
as suggested by @Dridi with reference to @bsdphk in https://github.com/varnishcache/varnish-cache/pull/3130#pullrequestreview-316916213
-
Nils Goroll authored
we ensure that only backends on the director_list receive events. Because events happen in the cli thread, we do not need another level of serialization. There is no explicit vtc, the test case has been added to vmod_debug and runs with every invocation of that vmod. Fixes #3094
-
Nils Goroll authored
-
Nils Goroll authored
we are going to need to check a temperature on its own
-
Nils Goroll authored
Ref #3094
-
Nils Goroll authored
-
Dridi Boukelmoune authored
-
Dridi Boukelmoune authored
-
Martin Blix Grydeland authored
Fix a small memory leak when failing to spawn a new thread.
-
Martin Blix Grydeland authored
When getidleworker signals the pool herder to spawn a thread, it increases the dry counter, and the herder resets dry again when spawning a single thread. This will in many cases only create a single thread even though the herder was signaled dry multiple times, and may cause a situation where the cache acceptor is queued and no new thread is created. Together with long lasting tasks (ie endless pipelines), and all other tasks having higher priority, this will prevent the cache acceptor from being rescheduled. c00096.vtc demonstrates how this can lock up. To fix this, spawn threads if we have queued tasks and we are below the thread maximum level.
-
- 17 Nov, 2019 1 commit
-
-
Deepjyoti Mondal authored
Fixed the typos in the files mentioned in the corresponding issue.
-
- 16 Nov, 2019 3 commits
-
-
Nils Goroll authored
-
Nils Goroll authored
Fixes #3135
-
Emmanuel Hocdet authored
-
- 15 Nov, 2019 2 commits
-
-
Dridi Boukelmoune authored
Otherwise you might run into this: Message from VCC-compiler: Unused backend nil, defined: ('<vcl.inline>' Line 4 Pos 17) backend nil none; ----------------###------ (That was just a warning) Message from C-compiler: vgc.c:1476:20: error: unused variable 'vgc_backend_nil' [-Werror,-Wunused-variable] static VCL_BACKEND vgc_backend_nil; ^ 1 error generated. Running C-compiler failed, exited with 1 VCL compilation failed This is done in both init and discard code to maintain the balance.
-
Dridi Boukelmoune authored
This reverts commit 1d23a733.
-
- 14 Nov, 2019 4 commits
-
-
Emmanuel Hocdet authored
Fixes #3131
-
Dridi Boukelmoune authored
-
Dridi Boukelmoune authored
Because someone brought a suncc to a vtest party.
-
Dridi Boukelmoune authored
Now that vtc.typesize() is a bit more reliable, it's easier to deal with architecture differences for the sizeof struct vrt_blob. For a much more reliable failure check, it now looks at logs. There may also have been a time when depending on the error we trigger we could fail with a 500 or a 503, this is no longer the case. For the nitty-gritty of the new test case, there are some comments to hopefully help (at least my future self) decipher this beast. This new test case remains stable even with the changes from #3123.
-
- 13 Nov, 2019 9 commits
-
-
Dridi Boukelmoune authored
And start adding some coverage, certainly not exhaustive.
-
Dridi Boukelmoune authored
-
Dridi Boukelmoune authored
-
Dridi Boukelmoune authored
-
Dridi Boukelmoune authored
-
Nils Goroll authored
-
Nils Goroll authored
added by @lkarsten as suggested by @Driri in #3122
-
Lasse Karstensen authored
This adds another vim-style key binding to varnishstat. Couldn't find any good way to extend u00008.vtc to test it. The cursor is always at column 22 and page-downing to the bottom will break the test case when we add another counter.
-
Dridi Boukelmoune authored
-