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
