> I don't have a test to reproduce the segfault, so I'm just shooting in the > dark based on the core trace that you've kindly provided. Please revert the > previous patch and try the new one:
We tried the new patch, but can still get the segfault. We wrote 3 modules that can reproduce the segfault on our system. We're using the same trickery in our production code. The segfault will occur when the server is under a bit of load, refreshing the browser repeatedly will make it die quickly. We have apache configured so the children only handle 10 requests before exiting. The transhandler will answer requests for any domain name, and strip the uri passed off of the request. It returns declined after that so our handler can step in and do its work. The handler is parsing an XML file and using XML::GDOME::XSLT to transform it into html. We used XML::LibXSLT for a while too, the segfaults were happening before we switched over. The Global Module is just a locker for storing the parts of the request we want to access from modules down the line. Some code we didn't include calls different objects based on the uri passed in. But we could reproduce the bomb without all of that. We compiled apache without expat, having read that this can cause segfaults when using some XML modules. The latest backtrace and the portion of httpd.conf that sets up the test environment are in the README for Server::Killer. We don't want to take too much of your time with this, if we knew what portion of our code was causing the bomb then we could just recode it. If you need any more information, please let us know. Thanks again, Marc Slagle Whapps, LLC
Server-Killer-0.01.tar.gz
Description: application/compressed-tar
Server-KillerGlobal-0.01.tar.gz
Description: application/compressed-tar
Server-KillerTH-0.04b.tar.gz
Description: application/compressed-tar
-- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
