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
