Closed delthas closed 8 months ago
Of note is that I do not get a panic if I remove the var.get
call before std.rollback
. (I also get a panic if I do var.set; std.rollback; var.set)
I get a different panic with the following (two var calls after the rollback, instead of one before and one after); though I suppose the root cause is likely the same:
varnishtest "Test that var works across a rollback"
server s1 {
rxreq
txresp
} -start
varnish v1 -vcl+backend {
import std;
import var from "${vmod_builddir}/.libs/libvmod_var.so";
sub vcl_backend_fetch {
std.rollback(bereq);
var.set("foo", "bar");
var.set("foo", "bar");
}
} -start
client c1 {
txreq -url "/"
rxresp
} -run
**** v1 CLI RX|Wrong turn at cache/cache_main.c:327:
**** v1 CLI RX|Signal 11 (Segmentation fault) received at 0x7e4c006f6f66 si_code 1
**** v1 CLI RX|Backtrace:
**** v1 CLI RX| ip=0x59caa62a269e sp=0x7e4c2d2912a0 <pan_ic+0x34e>
**** v1 CLI RX| ip=0x59caa63726b5 sp=0x7e4c2d291430 <VAS_Fail+0x55>
**** v1 CLI RX| ip=0x59caa629cf30 sp=0x7e4c2d291480 <child_signal_handler+0x320>
**** v1 CLI RX| ip=0x7e4c2d754770 sp=0x7e4c2d2919c0 <__sigaction+0x50>
**** v1 CLI RX| ip=0x7e4c2c5da6c8 sp=0x7e4c2cf12460 <get_vh+0x9c>
**** v1 CLI RX| ip=0x7e4c2c5da790 sp=0x7e4c2cf12490 <vmod_set_string+0x2b>
**** v1 CLI RX| ip=0x7e4c2c5da735 sp=0x7e4c2cf124d0 <vmod_set+0x30>
**** v1 CLI RX| ip=0x7e4c2c5f7a9f sp=0x7e4c2cf12500 <VGC_function_vcl_backend_fetch+0x1cf>
**** v1 CLI RX| ip=0x59caa62dbe3b sp=0x7e4c2cf12540 <vcl_call_method+0x7fb>
**** v1 CLI RX| ip=0x59caa62dc180 sp=0x7e4c2cf12690 <VCL_backend_fetch_method+0x1e0>
**** v1 CLI RX| ip=0x59caa62842dc sp=0x7e4c2cf126d0 <vbf_stp_startfetch+0x29c>
**** v1 CLI RX| ip=0x59caa62833b8 sp=0x7e4c2cf12730 <vbf_fetch_thread+0x7a8>
**** v1 CLI RX| ip=0x59caa62e2a55 sp=0x7e4c2cf12820 <Pool_Work_Thread+0x895>
**** v1 CLI RX| ip=0x59caa62e2043 sp=0x7e4c2cf128b0 <WRK_Thread+0x3e3>
**** v1 CLI RX| ip=0x59caa62e1c1b sp=0x7e4c2cf13430 <pool_thread+0xcb>
**** v1 CLI RX| ip=0x7e4c2d7a355a sp=0x7e4c2cf13460 <pthread_condattr_setpshared+0x67a>
**** v1 CLI RX| ip=0x7e4c2d820a3c sp=0x7e4c2cf13500 <__clone+0x20c>
OK, taking a step back: std.rollback also resets all PRIV_TASK objects (in which the variables are stored). In other words, std.rollback deletes request variables by design.
A possible "solution" to this would be to document that libvmod-var does not support std.rollback at all; or to detect/allow rollbacks (but we start over with no variables, because the previous ones were deleted).
hi, sorry, was a bit busy, I talked to the team and essentially you need to immediately return(retry|restart)
after std.rollback()
, but it was never documented. So, I will open a ticket on the varnish github so we can fix it, and I'm keeping this open until it's merged.
looks like they fixed the issue upstream, cloging
Hi, I get a consistent panic with the following minimal (not) working example VTC, on Varnish 7.4.2 + varnish-modules master:
(Feel free to use it as you wish as a regression test if needed.)
Panic: