- 06 Jul, 2023 1 commit
-
-
Darryl Rodden authored
-
- 04 Jul, 2023 1 commit
-
-
Nils Goroll authored
FreeBSD/arm (not 64) vtester **** p2 stderr|Error: Child failed on launch within cli_timeout=3.00s (tip: set startup_timeout) **** p2 stderr|Error: Child (29805) said Child starts **** p2 stderr|Error: Child (29805) said -sdebug init delay 0.000000s **** p2 stderr|Error: Child (29805) said -sdebug open delay in init 5.000000s **** p2 stderr|Error: Child (29805) died signal=6 **** p2 stderr|Error: Child (29805) said Wrong turn in cli_quit(), ../../../../bin/varnishd/cache/cache_main.c line 371: pthread_kill(cli_thread, sig) failed **** p2 stderr|Error: Child (29805) said errno = 22 (Invalid argument) **** p2 stderr|Error: Child (29805) said Wrong turn in child_signal_handler(), ../../../../bin/varnishd/cache/cache_main.c line 327: Signal 6 (Abort trap) received at 0x0 si_code 65543 **** p2 stderr|Error: Child (29805) said errno = 22 (Invalid argument)
-
- 03 Jul, 2023 14 commits
-
-
Nils Goroll authored
Some systems see it, others not
-
Nils Goroll authored
-
Nils Goroll authored
Hopefully this should fix vtest errors on bsd/arm Thank you to phk for the quick help!
-
Nils Goroll authored
-
Nils Goroll authored
I do not understand how to avoid the child panicking while it is being killed for timeout. And removing the AZ() for this case only is not a good idea. *** v1 debug|Error: Child (36277) not dying (waitpid = 0), killing *** v1 debug|Child (36277) died signal=6 *** v1 debug|Error: Child (36277) Panic at: Mon, 03 Jul 2023 15:18:50 GMT *** v1 debug|Assert error in CLI_Run(), cache/cache_cli.c line 102: *** v1 debug| Condition((VCLI_WriteResult(heritage.cli_out, CLIS_OK, \"Ready\")) == 0) not true.
-
Nils Goroll authored
An r3940 vtest failure on freebsd seems to suggest that the child does not terminate while blocking in a write. *** v1 debug|Error: Child (74042) Panic at: Mon, 03 Jul 2023 13:40:40 GMT *** v1 debug|Assert error in CLI_Run(), cache/cache_cli.c line 102: *** v1 debug| Condition((VCLI_WriteResult(heritage.cli_out, CLIS_OK, \"Ready\")) == 0) not true. This might need another iteration.
-
Nils Goroll authored
as seen in varnishtest: *** v1 debug|Error: Child (0) not dying, killingChild (74042) died signal=6
-
Dridi Boukelmoune authored
-
Dridi Boukelmoune authored
-
Dridi Boukelmoune authored
This makes obvious what is used for statistics purposes and what is used to maintain the pool queue. In particular, the pool::nqueued field has nothing to do with pool::ndequeued.
-
Dridi Boukelmoune authored
-
Nils Goroll authored
printf debugging showed that the initial VSMW_New() call did not go through vsm_vsmw_lock() / vsm_vsmw_unlock() simply because the function pointers were not initialized yet. This patch moves the init just after their initialization. child_main() was previously called right after VSMW_New(), and VSM_Init() is almost the first thing which child_main() calls, so this move is mostly cosmetic. Seen staring at #3948
-
Nils Goroll authored
-
Nils Goroll authored
When a child did not come up within cli_timeout, varnishd startup would hang indefinitely. We add startup_timeout specifically for child startup. To facilitate the transition, we use the maximum of cli_timeout and start_timeout (suggested by Dridi, thank you) and add a tip if startup_timeout is not used. We avoid the previous harsh exit(1), primarily to make the vtc_varnish facility work. The test case uses both vtc_varnish and vtc_process to exercise the different code paths for implicit startup vs. cli "start". Fixes #3940
-
- 29 Jun, 2023 2 commits
-
-
Dridi Boukelmoune authored
For both processes, dump the screen before checking expectations. For p1, we make sure we have something to show before proceeding, and can abuse CLI serialization for that. Since p2 was already waited for, the screen dump was already guaranteed to succeed, on the other hand the superfluous p2 -wait can go away.
-
Nils Goroll authored
Motivated by #3948
-
- 28 Jun, 2023 1 commit
-
-
Dridi Boukelmoune authored
The VCC_GlobalSymbol() function might be called twice for the same symbol. For example a subroutine symbol may be created when the sub keyword is first encountered, but it was referenced by a call action before the subroutine definition. The main problem the leak is causing is lsan's output polluting test cases looking at the screen output of varnishd, making the lines we care about scroll out to oblivion. To remedy this, VCC_GlobalSymbol() idempotence becomes free of side effects.
-
- 26 Jun, 2023 12 commits
-
-
Nils Goroll authored
As noted in 31baed29, my commit 0c1aef58 was wrong, and it was even worse than we thought: Despite what the linux man page suggests, the close_range() declaration is in unistd.h on Linux like on freebsd. We do not actually need linux/close_range.h, because it has only macro definitions which we do not need. We now add a specific configure test if close_range() not only exists but also works. Closes #3905
-
Dridi Boukelmoune authored
But retain the ability to specify them: make VGZ_CFLAGS=-Wfoo We may need them again if new warnings crop up when we sync with zlib in the future, or if we retire libvgz in favor of a vanilla zlib. Refs 3df9cdc1
-
Nils Goroll authored
We have two forms of -efile(766, config.h) globally
-
Nils Goroll authored
I believe this is the most invasive method: -e{766} has no effect --e{766} applies to the whole file -efile(766, ...) in flint.lnt applies to the (sub)tree
-
Nils Goroll authored
-
Dridi Boukelmoune authored
This was fixed after several attempts in the past [1] and I convinced myself that I was doing it wrong when I implemented generic VSC rules similarly to how VTC rules were centralized [2] but some lessons will never be learned. The reason why I was so easily convinced is that the '-local' suffix is clearly documented, but the '-am' one is not, which leads me to believe that it is an implementation detail we shouldn't rely on. The documentation clearly states the lack of '-local' ordering, one more reason not to rely on 'check-local'. If we can use neither 'check-local' nor 'check-am' reliably for the test suite refresh vs execution ordering, maybe there's a simpler solution? Fixes #3942 [1] 85e3d442 [2] dcaf616c
-
Nils Goroll authored
Fixes #3943
-
Nils Goroll authored
https://gitlab.com/uplex/varnish/slash/-/issues/13 is an example where 9 stack frames are used by abort handling alone.
-
Walid Boudebouda authored
-
Walid Boudebouda authored
pthread_* calls don't set errno but return it instead. This cocci patch ensures we always use PTOK macro that sets errno in case of pthread calls failures.
-
Walid Boudebouda authored
-
Poul-Henning Kamp authored
-
- 23 Jun, 2023 3 commits
-
-
Nils Goroll authored
this happened on one of the uplex linux vtesters which runs gcc and clang in parallel un-namespaced * top VTEST Abstract UDS backend: change path, drop poll ** top === feature abstract_uds **** dT 0.004 ** top === server s1 -listen "@vtc.s1.sock" { ** s1 Starting server ---- s1 Server listen address (@vtc.s1.sock) cannot be resolved: bind(2)
-
Nils Goroll authored
to have available a unique string for concurrently running tests which is not a path.
-
Nils Goroll authored
from the log: ** top === shell -exit 1 -expect {failing as requested} { **** top shell_cmd|exec 2>&1 ; **** top shell_cmd|\tvarnishadm -n /root/VT/_vtest_tmp/vtc.37277.0dc3c11b/v1 vcl.load f1 /root/VT/_vtest_tmp/vtc.37277.0dc3c11b/f1 **** dT 27.789 **** v1 vsl| 0 CLI - Rd vcl.load f1 vcl_f1.1686893821.277415/vgc.so 1auto **** v1 vsl| 0 CLI - Wr 300 62 VCL "f1" Failed initialization Message: failing as requested **** dT 27.893 **** v1 vsl| 0 CLI - Rd ping **** v1 vsl| 0 CLI - Wr 200 19 PONG 1686893826 1.0 **** dT 32.987 **** top shell_out|CLI communication error (hdr) **** top shell_status = 0x0002 ---- top shell_exit not as expected: got 0x0002 wanted 0x0001 * top RESETTING after ../../../../bin/varnishtest/tests/m00000.vtc **** dT 32.988
-
- 22 Jun, 2023 1 commit
-
-
Nils Goroll authored
-
- 20 Jun, 2023 1 commit
-
-
Poul-Henning Kamp authored
in the most diff-friendly way. If Mark Adler ever decides that the 21st century is real thing, we will adopt his diff. This should allow us to revert 79c7d175
-
- 16 Jun, 2023 4 commits
-
-
Nils Goroll authored
Varnish historians claim to have evidence that the odd wording "from mgt_param" could have been an unintended side effect of a struct rename in ancient times at around 2011. (82411494)
-
Nils Goroll authored
To keep things simple, the open delay is global - the delay of the last debug stevedore applies to all of them.
-
Nils Goroll authored
-
Dridi Boukelmoune authored
-