The workarounds (viable to me) that prevent the seg fault descirbed below
are:
1. Use LWP::UserAgent within a startup.pl (need to actually make a complete
HTTP request, not just 'use')
2. Use WWW:Curl instead of LWP::UserAgent in the output filter
One of the keys to the seg fault seems to be the use of LWP::UserAgent
within a bucket brigade filter. The seg fault occurs if Perl hasn't yet
loaded this module (and friends). After the filter runs successfully - seg
fault. Interestingly though, the other factors described are all necessary:
CGI.pm header(), the print statement must have a comma and contain >8k -
which causes the output filter to run during the "print", not after.
Can anyone offer a potential cause for the seg fault? The example code
provided is all straight out of the docs.
Other things to note:
- This occurs on a pre-forking mpm running in single process mode -X
- The LWP request is not hitting the same server
Thanks,
Ed Eddington
On 11/15/06, [EMAIL PROTECTED] <
[EMAIL PROTECTED]> wrote:
I'm getting seg faults within "print" of ModPerl::Registry script while
using an output filter handler. The output filter is run during the script's
"print" statement when the printed string is > ~8kb. Debugging shows the seg
fault occurs AFTER the output filter handler has completed successfully, but
BEFORE the print statement completes. GDB backtrace is below. Perl modules
CGI.pm and LWP::UserAgent seem to be causal in generating the seg fault.
Here is the somewhat complicated recipe that produces the seg fault
reliably.
1. ModPerl::Registry script using CGI.pm header() and a print statement
that includes a comma separated (list) of strings > 8kb.
2. An output filter handler that uses LWP::UserAgent to make an HTTP
request.
Caveats:
- Only occurs in an Apache child that hasn't already loaded these
modules (CGI, LWP::UserAgent) and dependents.
- Occurs in single process mode (-X) on both static and dynamically
linked builds.
Example script/filter and system details are below. I can provide more
info if needed. I'm currently testing other module versions. Can anyone
suggest a fix or workaround?
Thanks!
*Ed Eddington*
Sr. Software Engr - Web Development
Priority Health - Grand Rapids, MI
