Some time ago I brought to the list's attention a problem with Rivet
clashing with mod_cgi, making cgi based application totally ineffective.
The conflict happened in a way that caused cgi scripts to fail and a
child process to exit prematurely when mod_rivet was loaded in Apache.
This occurrence is only half handled by Apache: a browser would sit and
wait forever for a response to come from the server, suggesting the
problem to be deeper than just module configuration or error handling.
Child processes do not fail through a segfault or other fatal error or
exception though, they simply exit and Apache orderly calls exit
handlers for each module installed, including Rivet which duly calls a
configured ChildExitScript. Simply commenting out Rivet's 'LoadModule'
command restores the cgi scripts functionality.
I thought that debugging Apache could provide an answer. No way,
breakpoints on Rivet's exit handlers are shunted because (I presume)
they rely on symbols information stored in the executable. So I could
not trap the call to the exit handler and check the backtrace to have an
idea on what is going on. I think it must be something that has to do
with the way jump tables and other binary structures are filled by the
dynamic loader at run-time. It seems to me also this is a potential
weakness that has to be secured somehow. I think I've run out of ideas
now and I ought to ask what direction is best to take in order to track
the problem down once for all.
(Someone (Damon?) said that, to his experience, this wasn't his case and
Rivet coexisted peacefully with mod_cgi (or equivalent) on his
installations. I'd like to understand what's going on on Linux and why.)
Any suggestion is welcome.
sorry for the long message and thank you if have read it to this line....
-- Massimo
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org
For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
