On Mon, 24 Jun 2002, Andreas J. Koenig wrote:
> This stack trace is all I have. I cannot reproduce this SEGV at will,
> so it will be difficult to obtain additional information. All I can do
> is let the webserver run in -X mode and wait. I have no hints (yet)
> what kind of request triggers it.
...
> #6 0x820baa2 in PerlIO_cleanup (my_perl=0x82fc9c8) at perlio.c:2124
> #7 0x810d298 in perl_destruct (my_perl=0x82fc9c8) at perl.c:490
> #8 0x8099039 in perl_shutdown (s=0x82f140c, p=0x88f9c24) at mod_perl.c:294
> #9 0x809b373 in perl_child_exit (s=0x82f140c, p=0x88f9c24) at mod_perl.c:958
> #10 0x809afce in perl_child_exit_cleanup (data=0x88f9db4) at mod_perl.c:926
looks like a leaked PerlIO* from Request.xs, as this is happening when the
child is killed by apache (e.g. MaxRequestsPerChild reached).
patch below may cure, seems like a better approach in any case.
it is ugly here because the FILE was opened by an apache api function
which will close it when the request pool is cleared, so we must dup.
--- Request/Request.xs~ Sun Jan 20 09:27:35 2002
+++ Request/Request.xs Sat Jun 29 16:37:37 2002
@@ -491,8 +491,13 @@
ApacheUpload_fh(upload)
Apache::Upload upload
+ PREINIT:
+ int fd;
+
CODE:
- if ( ( RETVAL = PerlIO_importFILE(ApacheUpload_fh(upload),0) ) == NULL )
+ fd = PerlLIO_dup(fileno(ApacheUpload_fh(upload)));
+
+ if (!(RETVAL = PerlIO_fdopen(fd, "r")))
XSRETURN_UNDEF;
OUTPUT:
@@ -501,18 +506,9 @@
CLEANUP:
if (ST(0) != &PL_sv_undef) {
IO *io = GvIOn((GV*)SvRV(ST(0)));
- int fd = PerlIO_fileno(IoIFP(io));
- PerlIO *fp;
- fd = PerlLIO_dup(fd);
- if (!(fp = PerlIO_fdopen(fd, "r"))) {
- PerlLIO_close(fd);
- croak("fdopen failed!");
- }
if (upload->req->parsed)
- PerlIO_seek(fp, 0, 0);
-
- IoIFP(io) = fp;
+ PerlIO_seek(IoIFP(io), 0, 0);
}
long
