varnish-cache
varnish-cache copied to clipboard
SIGSEGV in vmod bad metadata code path
Expected Behavior
varnishd should drop an error message if loading a vmod/extension fails
Current Behavior
vcc crashes
Error:
Message from VCC-compiler:
FOUND VMOD in VEXT ../vext_cache/libvmod_slash.so,yoaekqrm.so
Running VCC-compiler failed, signal 11, core dumped
VCL compilation failed
Core was generated by `/tmp/sbin/varnishd -a :8081 -a self=@varnish_self -f /home/slink/src/slash/test'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x000059a41fb31e0e in vcc_VmodLoad (tl=0x73b44f8f0000, vim=0x73b44f847320) at vcc_vmod.c:255
255 "VMOD %.*s: bad metadata\n", PF(vim->t_mod));
(gdb) bt
#0 0x000059a41fb31e0e in vcc_VmodLoad (tl=0x73b44f8f0000, vim=0x73b44f847320) at vcc_vmod.c:255
#1 0x000059a41fb325fc in vcc_ImportVext (tl=0x73b44f8f0000, filename=0x73b44f8292c0 "../vext_cache/libvmod_slash.so,yoaekqrm.so")
at vcc_vmod.c:581
#2 0x000059a41fb16c9b in VCC_VEXT (vcc=0x73b44f8f0000, filename=0x73b44f8292c0 "../vext_cache/libvmod_slash.so,yoaekqrm.so")
at vcc_compile.c:962
#3 0x000059a41faf5228 in vcc_vext_iter_func (filename=0x73b44f829140 "vext_cache/libvmod_slash.so,yoaekqrm.so", priv=0x73b44f8f0000)
at mgt/mgt_vcc.c:104
#4 0x000059a41fabd008 in vext_iter (func=0x59a41faf5150 <vcc_vext_iter_func>, priv=0x73b44f8f0000) at common/common_vext.c:94
#5 0x000059a41faf4cf3 in run_vcc (priv=0x7ffde0fbc450) at mgt/mgt_vcc.c:133
#6 0x000059a41fb58ab6 in VSUB_run (sb=0x73b44f81d450, func=0x59a41faf4ae0 <run_vcc>, priv=0x7ffde0fbc450,
name=0x59a41fb94dd7 "VCC-compiler", maxlines=-1) at vsub.c:153
#7 0x000059a41faf47b2 in mgt_vcc_compile (vp=0x7ffde0fbc450, sb=0x73b44f81d450, C_flag=0) at mgt/mgt_vcc.c:290
#8 0x000059a41faf4248 in mgt_VccCompile (cli=0x7ffde0fbc750, vcl=0x73b44f847280, vclname=0x59a41fb87687 "boot",
vclsrc=0x73b44f8cdb00 "vcl 4.1;\n\nimport slash;\nimport std;\nimport blob;\nimport blobsynth;\n\nbackend none none;\n\nbackend self {\n\t.path = \"@varnish_self\";\n}\n\nsub vcl_init {\n\tslash.tune_fellow(storage.fellow,\n\t dsk_reserve_c"...,
vclsrcfile=0x73b44f8291c0 "/home/slink/src/slash/testing/burn-in/fellow_test.vcl", C_flag=0) at mgt/mgt_vcc.c:427
#9 0x000059a41faf5fe3 in mgt_new_vcl (cli=0x7ffde0fbc750, vclname=0x59a41fb87687 "boot",
vclsrc=0x73b44f8cdb00 "vcl 4.1;\n\nimport slash;\nimport std;\nimport blob;\nimport blobsynth;\n\nbackend none none;\n\nbackend self {\n\t.path = \"@varnish_self\";\n}\n\nsub vcl_init {\n\tslash.tune_fellow(storage.fellow,\n\t dsk_reserve_c"...,
vclsrcfile=0x73b44f8291c0 "/home/slink/src/slash/testing/burn-in/fellow_test.vcl", state=0x0, C_flag=0) at mgt/mgt_vcl.c:461
#10 0x000059a41faf5dff in mgt_vcl_startup (cli=0x7ffde0fbc750,
vclsrc=0x73b44f8cdb00 "vcl 4.1;\n\nimport slash;\nimport std;\nimport blob;\nimport blobsynth;\n\nbackend none none;\n\nbackend self {\n\t.path = \"@varnish_self\";\n}\n\nsub vcl_init {\n\tslash.tune_fellow(storage.fellow,\n\t dsk_reserve_c"...,
vclname=0x59a41fb87687 "boot", origin=0x73b44f8291c0 "/home/slink/src/slash/testing/burn-in/fellow_test.vcl", C_flag=0)
at mgt/mgt_vcl.c:513
#11 0x000059a41faeaff0 in mgt_process_f_arg (cli=0x7ffde0fbc750, C_flag=0, fap=0x73b44f81d110) at mgt/mgt_main.c:553
#12 0x000059a41fae8cdd in main (argc=28, argv=0x7ffde0fbc958) at mgt/mgt_main.c:938
(gdb) p *vim
$2 = {magic = 830487133, err = 0x59a41fbad2a5 "No VMOD JSON found", json = 0x73b44f81df00, path = 0x0, list = {vtqe_next = 0x0,
vtqe_prev = 0x0}, from_vext = 0, unimported_vext = 0, vmod_syntax = 1, name = 0x0, func_name = 0x0, file_id = 0x0, abi = 0x0,
major = 0, minor = 0, sym = 0x0, t_mod = 0x0, vj = 0x73b44f81df30, n_alias = 0, n_cproto = 0, n_event = 0, n_func = 0, n_method = 0,
n_obj = 0, n_vmod = 0, n_restrict = 0}
Possible Solution
No response
Steps to Reproduce (for bugs)
No response
Context
.
Varnish Cache version
92570c961a5742f9aa54437c4c88fb4e9a87a45a
Operating system
No response
Source of binary packages used (if any)
No response
So this seems to be due to the code path re-used for extensions not having the VCC parser tokens. So question to bugwash: Should we refactor to not use tokens?
bugwash: @bsdphk wants to have a look, thank you