synth.vtc causes a panic in vcl_call_method() when CFLAGS includes -O0 #2
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The
synth.vtctest has been failing with a panic when the VMOD is built so thatCFLAGSincludes-O0. I noticed it when running the coverage target, which among other things sets-O0, but the problem evidently isn't caused by the gcov stuff, just the-Osetting.The assertion is here, where the comments say:
The
awsvariable is read fromWS_Snapshot(wrk->aws)before calling the VMOD method, and then checked with this assertion afterward.This is a peculiar problem, because it only happens when the VMOD's
.synth()method is tested, which not only does not reserve any workspace, it doesn't use any workspace at all, at least not directly in the VMOD code.This is the panic message part of the VTC log (for some reason, the panic is there twice). The full log is in the attachment: synth.log
changed title from synth.vtc causes a panic in {-
vcl_call_method()-} when CFLAGS includes -O0 to synth.vtc causes a panic in {+vcl_call_method()+} when CFLAGS includes -O0closed via commit
e632d8a6e9The "fix" here was simply to remove the call to
VRT_synth_strands(), create a BLOB instead, and callVRT_synth_blob():But that's more of a workaround that doesn't really explain what the problem was.
I don't see what it was about the VMOD that could have made
wrk->aws->fchange when this method was called, but only if-O0was set. It makes me wonder if something strange is going on inVRT_synth_strands(); but that would be more of a Varnish VRT issue than a VMOD issue.ARGH! A C beginner error was lurking in this code for years now.
Spot the error: