Hello Massimo, No problem at all. It was easy finally to recompile and start the apache in debug. Now I can do this I can troubleshoot anything.
Sorry for not responding yesterday but I was off for Thanksgiving here. If you want I can do a real patch. Or even make a commit to a git repository if this is what you guys use. I have no idea how you guys collaboratively are working. Thank you, Brice. On Fri, Nov 29, 2019 at 4:50 AM Massimo Manghi <massimo.man...@unipr.it> wrote: > Thank you Brice for having found this annoying bug. I realized the hash > table is part of the cache implementation which is kept hidden in > src/mod_rivet_ng/mod_rivet_cache.c. I will add a function to this > module's public interface to remove an entry from the cache. Just to > keep the code consistent. Still the fix is exactly the one you provided. > > -- Massimo > > On 11/27/19 8:01 PM, Brice Hamon wrote: > > Hi Guys, > > > > I found a small issue in rivet3.1.1 and before. > > > > I was creating a rvt file which was not readable by apachebecause 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, 2015from 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 > > <http://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 <http://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 <http://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. > > > > > > > > > > > > >
