Mailing List Archive: ModPerl: ModPerl

Debugging seg faults in Apache mod_perl

Index | Next | Previous | View Threaded

js5 at sanger

Aug 17, 2009, 3:51 PM

Post #1 of 6 (1145 views)
Permalink

Debugging seg faults in Apache mod_perl

I have two handlers, one a response handler and a second an output filter.
If either of these handlers run then they run fine for any number of
requests, if I have both of these handlers I get an untraceable seg fault
with the handlers, this segfault happens on the second request to that
particular child.

If the page is generated from:

* the file system,
* via mod_php or
* mod_rails I don't have a problem

If the page content is generated by mod_perl it works perfectly well for
the first request - but fails for subsequent requests.

[notice] child pid 14475 exit signal Segmentation fault (11)

This appears to be before the page handler executes...

If I turn off the output filter - everything is OK for all requests.

Any suggestions on how I debug this... it makes life so much easier if
I can handle all requests this way (and it seems to be the apache way)

James

--
The Wellcome Trust Sanger Institute is operated by Genome Research
Limited, a charity registered in England with number 1021457 and a
company registered in England with number 2742969, whose registered
office is 215 Euston Road, London, NW1 2BE.

js5 at sanger

Aug 17, 2009, 4:54 PM

Post #2 of 6 (1082 views)
Permalink

Re: Debugging seg faults in Apache mod_perl [In reply to]

Futher to this I now have a stack trace if that helps anyone point me in
the right direction:

#0 0x00007f17ee936fb1 in strncpy () from /lib/libc.so.6
#1 0x00007f17e808ecfc in modperl_perl_global_request_save () from
/usr/lib/apache2/modules/mod_perl.so
#2 0x00007f17e807dabc in modperl_response_handler_cgi () from
/usr/lib/apache2/modules/mod_perl.so
#3 0x00007f17ef7272d3 in ap_run_handler () from /usr/sbin/apache2
#4 0x00007f17ef72aa6f in ap_invoke_handler () from /usr/sbin/apache2
#5 0x00007f17ef7385de in ap_process_request () from /usr/sbin/apache2
#6 0x00007f17ef735418 in ?? () from /usr/sbin/apache2
#7 0x00007f17ef72eca3 in ap_run_process_connection () from
/usr/sbin/apache2
#8 0x00007f17ef73cf46 in ?? () from /usr/sbin/apache2
#9 0x00007f17ef73d276 in ?? () from /usr/sbin/apache2
#10 0x00007f17ef73ddad in ap_mpm_run () from /usr/sbin/apache2
#11 0x00007f17ef71360d in main () from /usr/sbin/apache2

On Mon, 17 Aug 2009, James Smith wrote:

>
> I have two handlers, one a response handler and a second an output filter.
> If either of these handlers run then they run fine for any number of
> requests, if I have both of these handlers I get an untraceable seg fault
> with the handlers, this segfault happens on the second request to that
> particular child.
>
> If the page is generated from:
>
> * the file system,
> * via mod_php or
> * mod_rails I don't have a problem
>
> If the page content is generated by mod_perl it works perfectly well for
> the first request - but fails for subsequent requests.
>
> [notice] child pid 14475 exit signal Segmentation fault (11)
>
> This appears to be before the page handler executes...
>
> If I turn off the output filter - everything is OK for all requests.
>
> Any suggestions on how I debug this... it makes life so much easier if
> I can handle all requests this way (and it seems to be the apache way)
>
> James
>
>
> --
> The Wellcome Trust Sanger Institute is operated by Genome Research Limited, a
> charity registered in England with number 1021457 and a company registered in
> England with number 2742969, whose registered office is 215 Euston Road,
> London, NW1 2BE.

--
The Wellcome Trust Sanger Institute is operated by Genome Research
Limited, a charity registered in England with number 1021457 and a
company registered in England with number 2742969, whose registered
office is 215 Euston Road, London, NW1 2BE.

gozer at ectoplasm

Aug 17, 2009, 6:48 PM

Post #3 of 6 (1085 views)
Permalink

Re: Debugging seg faults in Apache mod_perl [In reply to]

On 17/08/09 19:54 , James Smith wrote:
>
> Futher to this I now have a stack trace if that helps anyone point me in
> the right direction:
>
> #0 0x00007f17ee936fb1 in strncpy () from /lib/libc.so.6
> #1 0x00007f17e808ecfc in modperl_perl_global_request_save () from
> /usr/lib/apache2/modules/mod_perl.so

That's hapenning in a fairly simple piece of code:

modperl_perl_global_svpv_save(pTHX_ modperl_perl_global_svpv_t *svpv)
{
svpv->cur = SvCUR(*svpv->sv);
strncpy(svpv->pv, SvPVX(*svpv->sv), sizeof(svpv->pv));
}

Looking at this, is there any chance you can get a mod_perl with
debugging symbols running this and post the content of :

*svpv
*(svpv->pv)
*(svpv->sv)

But looking at the guts, the only code path that will invoke this is
when saving/restoring the value of $/... Can you check to see what part
of your code alters that variable and to what ?

It might point to something interesting.

> #2 0x00007f17e807dabc in modperl_response_handler_cgi () from
> /usr/lib/apache2/modules/mod_perl.so
> #3 0x00007f17ef7272d3 in ap_run_handler () from /usr/sbin/apache2
> #4 0x00007f17ef72aa6f in ap_invoke_handler () from /usr/sbin/apache2
> #5 0x00007f17ef7385de in ap_process_request () from /usr/sbin/apache2
> #6 0x00007f17ef735418 in ?? () from /usr/sbin/apache2
> #7 0x00007f17ef72eca3 in ap_run_process_connection () from
> /usr/sbin/apache2
> #8 0x00007f17ef73cf46 in ?? () from /usr/sbin/apache2
> #9 0x00007f17ef73d276 in ?? () from /usr/sbin/apache2
> #10 0x00007f17ef73ddad in ap_mpm_run () from /usr/sbin/apache2
> #11 0x00007f17ef71360d in main () from /usr/sbin/apache2
>
>
> On Mon, 17 Aug 2009, James Smith wrote:
>
>>
>> I have two handlers, one a response handler and a second an output
>> filter.
>> If either of these handlers run then they run fine for any number of
>> requests, if I have both of these handlers I get an untraceable seg fault
>> with the handlers, this segfault happens on the second request to that
>> particular child.
>>
>> If the page is generated from:
>>
>> * the file system,
>> * via mod_php or
>> * mod_rails I don't have a problem
>>
>> If the page content is generated by mod_perl it works perfectly well for
>> the first request - but fails for subsequent requests.
>>
>> [notice] child pid 14475 exit signal Segmentation fault (11)
>>
>> This appears to be before the page handler executes...
>>
>> If I turn off the output filter - everything is OK for all requests.
>>
>> Any suggestions on how I debug this... it makes life so much easier if
>> I can handle all requests this way (and it seems to be the apache way)
>>
>> James
>>
>>
>> --
>> The Wellcome Trust Sanger Institute is operated by Genome Research
>> Limited, a charity registered in England with number 1021457 and a
>> company registered in England with number 2742969, whose registered
>> office is 215 Euston Road, London, NW1 2BE.
>
>

--
Philippe M. Chiasson GPG: F9BFE0C2480E7680 1AE53631CB32A107 88C3A5A5
http://gozer.ectoplasm.org/ m/gozer\@(apache|cpan|ectoplasm)\.org/

Attachments:

signature.asc (0.24 KB)

gozer at ectoplasm

Aug 17, 2009, 10:17 PM

Post #4 of 6 (1086 views)
Permalink

Re: Debugging seg faults in Apache mod_perl [In reply to]

On 17/08/09 21:48 , Philippe M. Chiasson wrote:
> On 17/08/09 19:54 , James Smith wrote:
>>
>> Futher to this I now have a stack trace if that helps anyone point me in
>> the right direction:
>>
>> #0 0x00007f17ee936fb1 in strncpy () from /lib/libc.so.6
>> #1 0x00007f17e808ecfc in modperl_perl_global_request_save () from
>> /usr/lib/apache2/modules/mod_perl.so
>
> That's hapenning in a fairly simple piece of code:
>
> modperl_perl_global_svpv_save(pTHX_ modperl_perl_global_svpv_t *svpv)
> {
> svpv->cur = SvCUR(*svpv->sv);
> strncpy(svpv->pv, SvPVX(*svpv->sv), sizeof(svpv->pv));
> }
>
>[...]
>
> But looking at the guts, the only code path that will invoke this is
> when saving/restoring the value of $/... Can you check to see what part
> of your code alters that variable and to what ?

Just had an idea, can't verify or test it right now, but I suspect this
might be caused by:

$/ = undef;

Could you have one of these lying around in your code somewhere ?

If so, can you try and change it to the usually recommended form:

local $/ = undef;

Hope this helps.

--
Philippe M. Chiasson GPG: F9BFE0C2480E7680 1AE53631CB32A107 88C3A5A5
http://gozer.ectoplasm.org/ m/gozer\@(apache|cpan|ectoplasm)\.org/

Attachments:

signature.asc (0.24 KB)

js5 at sanger

Aug 17, 2009, 11:30 PM

Post #5 of 6 (1079 views)
Permalink

Re: Debugging seg faults in Apache mod_perl [In reply to]

Phillipe,

Thnx, that seems to have solved the problem - I'd been slurping in the
page template file with a $/.. it also explains why switching from
using perl-script to modperl as the handler type also resolved the
issue...

James

On Tue, 18 Aug 2009, Philippe M. Chiasson wrote:

> On 17/08/09 21:48 , Philippe M. Chiasson wrote:
>> On 17/08/09 19:54 , James Smith wrote:
>>>
>>> Futher to this I now have a stack trace if that helps anyone point me in
>>> the right direction:
>>>
>>> #0 0x00007f17ee936fb1 in strncpy () from /lib/libc.so.6
>>> #1 0x00007f17e808ecfc in modperl_perl_global_request_save () from
>>> /usr/lib/apache2/modules/mod_perl.so
>>
>> That's hapenning in a fairly simple piece of code:
>>
>> modperl_perl_global_svpv_save(pTHX_ modperl_perl_global_svpv_t *svpv)
>> {
>> svpv->cur = SvCUR(*svpv->sv);
>> strncpy(svpv->pv, SvPVX(*svpv->sv), sizeof(svpv->pv));
>> }
>>
>> [...]
>>
>> But looking at the guts, the only code path that will invoke this is
>> when saving/restoring the value of $/... Can you check to see what part
>> of your code alters that variable and to what ?
>
> Just had an idea, can't verify or test it right now, but I suspect this
> might be caused by:
>
> $/ = undef;
>
> Could you have one of these lying around in your code somewhere ?
>
> If so, can you try and change it to the usually recommended form:
>
> local $/ = undef;
>
> Hope this helps.
>
> --
> Philippe M. Chiasson GPG: F9BFE0C2480E7680 1AE53631CB32A107 88C3A5A5
> http://gozer.ectoplasm.org/ m/gozer\@(apache|cpan|ectoplasm)\.org/
>
>

--
The Wellcome Trust Sanger Institute is operated by Genome Research
Limited, a charity registered in England with number 1021457 and a
company registered in England with number 2742969, whose registered
office is 215 Euston Road, London, NW1 2BE.

gozer at ectoplasm

Aug 18, 2009, 1:08 PM

Post #6 of 6 (1071 views)
Permalink

Re: Debugging seg faults in Apache mod_perl [In reply to]

On 18/08/09 02:30 , James Smith wrote:
>
> Phillipe,
>
> Thnx, that seems to have solved the problem - I'd been slurping in the
> page template file with a $/..

In theory, if you used local $/, it should work, maybe.

Can you try this small patch ?

Index: src/modules/perl/modperl_perl_global.c
===================================================================
--- src/modules/perl/modperl_perl_global.c (revision 805561)
+++ src/modules/perl/modperl_perl_global.c (working copy)
@@ -372,7 +372,7 @@
modperl_perl_global_svpv_save(pTHX_ modperl_perl_global_svpv_t *svpv)
{
svpv->cur = SvCUR(*svpv->sv);
- strncpy(svpv->pv, SvPVX(*svpv->sv), sizeof(svpv->pv));
+ strncpy(svpv->pv, SvPV_nolen(*svpv->sv), sizeof(svpv->pv));
}

static void

> it also explains why switching from
> using perl-script to modperl as the handler type also resolved the issue...

Yup, in perl-script mode, it does a lot of housekeeping behind the scenes.

--
Philippe M. Chiasson GPG: F9BFE0C2480E7680 1AE53631CB32A107 88C3A5A5
http://gozer.ectoplasm.org/ m/gozer\@(apache|cpan|ectoplasm)\.org/

Attachments:

signature.asc (0.24 KB)

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads