Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: ModPerl: ModPerl

Segmentation fault on form posting

 

 

ModPerl modperl RSS feed   Index | Next | Previous | View Threaded


neil at bowers

May 23, 2013, 5:27 AM

Post #1 of 3 (214 views)
Permalink
Segmentation fault on form posting

Hi,

I've got a mod_perl handler which has been working fine for a long time, but just recently two people have managed to trigger a seg fault under specific circumstances.

They are POSTing form data
Only happens over https - doesn't happen via http (ie without SSL)
A certain combination of bytes in the form seems to trigger this. Doesn't appear to be the *number* of bytes, but can't really be sure.
It only happens if the end-user is on 64-bit Windows (Win 7 only so far), on IE9 or Chrome 26 (27 seems to be ok). Doesn't happen on Firefix on 64bit, or on any browser on 32-bit Windows.

In my handler, if the first thing I do is print out the POST parameters, then the segfault doesn't happen. So it smells like some kind of memory overwrite.

This happens on combinations of:

CentOS 5.5 and 6.3
openssl 1.0.0d and 1.0.1e
Apache 2.2.22 and 2.2.24
Perl 5.12.3 and 5.16.3
mod_perl 2.0.5, 2.0.7 and 2.0.8

I'll probably try 5.18, though I don't expect any change with that.

So now, some questions:

Anyone seen anything like this, and have an idea where to look?
Any thoughts on where to look / what else to try?
What's the best approach to tracking this down? Valgrind?

I'm going to try attaching a debugger to an httpd process to see if I can see where it's dying, though I suspect the problem may be happening earlier.
I'll have a go with valgrind after that.

Cheers,
Neil


jschueler at eloquency

May 23, 2013, 6:12 AM

Post #2 of 3 (202 views)
Permalink
Re: Segmentation fault on form posting [In reply to]

I also encounter this problem occasionally. So your post is quite
familiar.

If the first thing you do is print the parameters, what's the second
thing? Form posts almost always trigger external processes, databases,
mail servers, etc. The external process is more likely to be causing the
fault than mod_perl.

At its heart, a perl scalar is a pretty complicated data object. I think
it's more likely that the scalar gets modified as the result of the print
operation. For example:

sprintf "%d", $cgi{quantity} ;

To my knowledge, this statement modifies the scalar $cgi{quantity} so that
the next operation views the scalar slightly differently. I have a
prototype library that examines the scalar. If I can find it, I'll
forward separately.

Finally, there are specific operations for parsing form input. Are you
using a package like CGI? Have you tried an alternative? It's only a
couple lines of code to roll your own.

-Jim

On Thu, 23 May 2013, Neil Bowers wrote:

> Hi,
> I've got a mod_perl handler which has been working fine for a long time, but
> just recently two people have managed to trigger a seg fault under specific
> circumstances.
>
> * They are POSTing form data
> * Only happens over https - doesn't happen via http (ie without SSL)
> * A certain combination of bytes in the form seems to trigger this.
> Doesn't appear to be the *number* of bytes, but can't really be sure.
> * It only happens if the end-user is on 64-bit Windows (Win 7 only so
> far), on IE9 or Chrome 26 (27 seems to be ok). Doesn't happen on Firefix
> on 64bit, or on any browser on 32-bit Windows.
>
> In my handler, if the first thing I do is print out the POST parameters,
> then the segfault doesn't happen. So it smells like some kind of memory
> overwrite.
>
> This happens on combinations of:
>
> * CentOS 5.5 and 6.3
> * openssl 1.0.0d and 1.0.1e
> * Apache 2.2.22 and 2.2.24
> * Perl 5.12.3 and 5.16.3
> * mod_perl 2.0.5, 2.0.7 and 2.0.8
>
> I'll probably try 5.18, though I don't expect any change with that.
>
> So now, some questions:
>
> * Anyone seen anything like this, and have an idea where to look?
> * Any thoughts on where to look / what else to try?
> * What's the best approach to tracking this down? Valgrind?
>
> I'm going to try attaching a debugger to an httpd process to see if I can
> see where it's dying, though I suspect the problem may be happening earlier.
> I'll have a go with valgrind after that.
>
> Cheers,
> Neil
>
>
>


jschueler at eloquency

May 23, 2013, 6:15 AM

Post #3 of 3 (200 views)
Permalink
Re: Segmentation fault on form posting [In reply to]

Here's the code I mentioned in my last post. It's included in my distro
NoSQL::PL2SQL

#include "EXTERN.h"
#include "perl.h"
#include "XSUB.h"

#include "ppport.h"

SV* typeis ( SV* what ) ;

SV* typeis ( SV* what )
{
if ( SvIOK( what ) )
return newSVpvs( "integer" ) ;
else if ( SvNOK( what ) )
return newSVpvs( "double" ) ;
else if ( SvPOK( what ) )
return newSVpvs( "string" ) ;

return newSVpvs( "unknown" ) ;
}


MODULE = NoSQL::PL2SQL PACKAGE = NoSQL::PL2SQL::Node

PROTOTYPES: ENABLE

SV*
typeis( what )
SV* what



On Thu, 23 May 2013, Neil Bowers wrote:

> Hi,
> I've got a mod_perl handler which has been working fine for a long time, but
> just recently two people have managed to trigger a seg fault under specific
> circumstances.
>
> * They are POSTing form data
> * Only happens over https - doesn't happen via http (ie without SSL)
> * A certain combination of bytes in the form seems to trigger this.
> Doesn't appear to be the *number* of bytes, but can't really be sure.
> * It only happens if the end-user is on 64-bit Windows (Win 7 only so
> far), on IE9 or Chrome 26 (27 seems to be ok). Doesn't happen on Firefix
> on 64bit, or on any browser on 32-bit Windows.
>
> In my handler, if the first thing I do is print out the POST parameters,
> then the segfault doesn't happen. So it smells like some kind of memory
> overwrite.
>
> This happens on combinations of:
>
> * CentOS 5.5 and 6.3
> * openssl 1.0.0d and 1.0.1e
> * Apache 2.2.22 and 2.2.24
> * Perl 5.12.3 and 5.16.3
> * mod_perl 2.0.5, 2.0.7 and 2.0.8
>
> I'll probably try 5.18, though I don't expect any change with that.
>
> So now, some questions:
>
> * Anyone seen anything like this, and have an idea where to look?
> * Any thoughts on where to look / what else to try?
> * What's the best approach to tracking this down? Valgrind?
>
> I'm going to try attaching a debugger to an httpd process to see if I can
> see where it's dying, though I suspect the problem may be happening earlier.
> I'll have a go with valgrind after that.
>
> Cheers,
> Neil
>
>
>

ModPerl modperl RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.