Hi Guys,
I found a small issue in rivet 3.1.1 and before.
I was creating a rvt file which was not readable by apache because of
different user file access right and I notice apache reporting a child
abort when I was trying to execute that rvt file.
I found an old email from Mon, Apr 20, 2015 from Massimo for rivet 2.2.2
explaining how to recompile apache and rivet in debug mode, thank you for
that.
The crash happens at the second access, not the first time.
Here is the trace:
Thread 1 "httpd" received signal SIGSEGV, Segmentation fault.
0x00007fffe7efad77 in Tcl_SetObjResult () from /usr/lib64/libtcl8.6.so
Missing separate debuginfos, use: zypper install
libapr-util1-debuginfo-1.5.3-3.2.x86_64 libapr1-debuginfo-1.5.1-5.1.x86_64
libdb-4_8-debuginfo-4.8.30-30.4.x86_64
libexpat1-debuginfo-2.1.0-20.1.x86_64
libldap-2_4-2-debuginfo-2.4.41-14.1.x86_64
libopenssl1_0_0-debuginfo-1.0.1i-21.1.x86_64
libpcre1-debuginfo-8.39-5.1.x86_64 libsasl2-3-debuginfo-2.1.26-8.1.x86_64
libuuid1-debuginfo-2.25-21.1.x86_64 libz1-debuginfo-1.2.8-8.1.x86_64
tcl-debuginfo-8.6.1-3.6.x86_64
(gdb) where
#0 0x00007fffe7efad77 in Tcl_SetObjResult () from /usr/lib64/libtcl8.6.so
#1 0x00007fffe81ae9b7 in Rivet_UrlScript (clientData=0x7ffff7e370a0,
interp=0x6ff720, objc=1, objv=0x703900) at mod_rivet_ng/rivetCore.c:1929
#2 0x00007fffe7e33d97 in TclNRRunCallbacks () from /usr/lib64/libtcl8.6.so
#3 0x00007fffe81b525a in Rivet_SendContent (private=0x7ffff7e370a0,
r=0x7ffff7e010a0) at mod_rivet_ng/mod_rivet_generator.c:317
#4 0x00007fffe74e48b7 in Prefork_MPM_Request (r=0x7ffff7e010a0, ctype=1)
at mod_rivet_ng/rivet_prefork_mpm.c:131
#5 0x00007fffe81a914f in Rivet_Handler (r=0x7ffff7e010a0)
at mod_rivet_ng/mod_rivet.c:483
#6 0x0000000000457930 in ap_run_handler (r=0x7ffff7e010a0) at config.c:169
#7 0x00000000004583e9 in ap_invoke_handler (r=0x7ffff7e010a0) at
config.c:433
#8 0x0000000000473de9 in ap_process_async_request (r=0x7ffff7e010a0)
at http_request.c:338
#9 0x0000000000473ea7 in ap_process_request (r=0x7ffff7e010a0)
at http_request.c:373
#10 0x0000000000470202 in ap_process_http_sync_connection (c=0x7ffff7e17290)
at http_core.c:210
#11 0x000000000047030e in ap_process_http_connection (c=0x7ffff7e17290)
at http_core.c:251
#12 0x00000000004654f0 in ap_run_process_connection (c=0x7ffff7e17290)
at connection.c:41
#13 0x00000000004659f9 in ap_process_connection (c=0x7ffff7e17290,
csd=0x7ffff7e170a0) at connection.c:213
#14 0x00007fffeaa5aeb9 in child_main (child_num_arg=0) at prefork.c:704
#15 0x00007fffeaa5afd6 in make_child (s=0x7ffff7fc1080, slot=0) at
prefork.c:746
#16 0x00007fffeaa5b5aa in prefork_run (_pconf=0x7ffff7fed028,
plog=0x7ffff7fbb028, s=0x7ffff7fc1080) at prefork.c:956
#17 0x0000000000436e43 in ap_run_mpm (pconf=0x7ffff7fed028,
plog=0x7ffff7fbb028, s=0x7ffff7fc1080) at mpm_common.c:94
#18 0x000000000042f13d in main (argc=2, argv=0x7fffffffe148) at main.c:777
After talking to Massimo, we confirmed that this is a bug within rivet
caching mechanism.
An entry is created in the TCL cache hash map for each file to be cached,
but not removed if the file can't be read.
I am guessing that non critical bug as been there forever.
I modify the file rivet-3.1.1/src/mod_rivet_ng/rivetCore.c and added as a
test line 1914 a TCL_DeleteHashEntry to validate the problem and indeed no
more crash after this.
if (result != TCL_OK)
{
// Hash cleanup
Tcl_DeleteHashEntry(entry);
Tcl_DecrRefCount(script);
return result;
}
I guess a proper method to remove an entry should be added
in mod_rivet_cache.c.
Thank you.
Brice.
