Re: Another SEGV perl 5.8.0-RC2 apache 1.3.26 mod_perl 1.27
5.8.0-RC3 still produces the SEGV with apache 1.3.26, mod_perl 1.27, Apache::Request 1.0 and MaxRequestPerChild 0. My recipe to reproduce the SEGV currently is: Set MaxRequestPerChild to 1 and request a static image. Unless the problem is fixed before 5.8.0 comes out (i.e.~Thursday), I fear we must document the fact: --- perl-5.7.3@17527/pod/perldelta.pod~ Sun Jul 14 02:18:36 2002 +++ perl-5.7.3@17527/pod/perldelta.pod Sun Jul 14 15:34:54 2002 -3133,6 +3133,10 Use mod_perl 1.27 or higher. +=head2 mod_perl 1.27 sometimes produces a segmentation fault + +Setting MaxRequestsPerChild to 0 seems to work around the problem. + =head2 lib/ftmp-security tests warn 'system possibly insecure' Don't panic. Read the 'make test' section of INSTALL instead. Jim, in any case it would be great if you could release a new Apache::Request with the two fixes that Doug has posted to the list[1], so that people need not fall into the two already fixed traps.--Thanks! -- andreas [1] http://mathforum.org/epigone/modperl/zhoolamgheld and http://mathforum.org/epigone/modperl/glongsnaysimp
Re: Another SEGV perl 5.8.0-RC2 apache 1.3.26 mod_perl 1.27
On Sat, 29 Jun 2002 16:48:57 -0700 (PDT), Doug MacEachern [EMAIL PROTECTED] said: 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. Thanks Doug, another great step forward! I can confirm that setting MaxRequestPerChild to 0 is an excellent way to avert the SEGV. But unfortunately your patch doesn't cure completely. This is the latest stack trace I got after I applied your patch. It was triggered by a static file request that did not call a mod_perl handler. MaxRequestPerChild was set to 3. Program received signal SIGSEGV, Segmentation fault. 0x400d8076 in chunk_free (ar_ptr=0x4016ca40, p=0x82fd0a0) at malloc.c:3097 3097malloc.c: No such file or directory. (gdb) bt #0 0x400d8076 in chunk_free (ar_ptr=0x4016ca40, p=0x82fd0a0) at malloc.c:3097 #1 0x400d7f5a in __libc_free (mem=0x82fd0a8) at malloc.c:3023 #2 0x8169142 in Perl_safesysfree (where=0x82fd0a8) at util.c:151 #3 0x8197ea2 in Perl_sv_clear (my_perl=0x82fc9c8, sv=0x86ed0bc) at sv.c:5049 #4 0x819831d in Perl_sv_free (my_perl=0x82fc9c8, sv=0x86ed0bc) at sv.c:5192 #5 0x818d4d8 in do_clean_all (my_perl=0x82fc9c8, sv=0x86ed0bc) at sv.c:400 #6 0x818d147 in S_visit (my_perl=0x82fc9c8, f=0x818d47c do_clean_all) at sv.c:292 #7 0x818d4fe in Perl_sv_clean_all (my_perl=0x82fc9c8) at sv.c:418 #8 0x810ddd5 in perl_destruct (my_perl=0x82fc9c8) at perl.c:771 #9 0x8099039 in perl_shutdown (s=0x82f140c, p=0x8903d6c) at mod_perl.c:294 #10 0x809b373 in perl_child_exit (s=0x82f140c, p=0x8903d6c) at mod_perl.c:958 #11 0x809afce in perl_child_exit_cleanup (data=0x8903efc) at mod_perl.c:926 #12 0x80ddc8e in run_cleanups () #13 0x80dc4bd in ap_clear_pool () #14 0x80dc531 in ap_destroy_pool () #15 0x80e945b in clean_child_exit () #16 0x80ec707 in child_main () #17 0x80eccb0 in make_child () #18 0x80ece09 in startup_children () #19 0x80ed466 in standalone_main () #20 0x80edc33 in main () #21 0x4009698b in __libc_start_main (main=0x80ed8dc main, argc=4, argv=0xbcc4, init=0x807a6f8 _init, fini=0x828da5c _fini, rtld_fini=0x4000ae60 _dl_fini, stack_end=0xbcbc) at ../sysdeps/generic/libc-start.c:92 -- andreas
Re: Another SEGV perl 5.8.0-RC2 apache 1.3.26 mod_perl 1.27
On Sun, 30 Jun 2002, Andreas J. Koenig wrote: Program received signal SIGSEGV, Segmentation fault. 0x400d8076 in chunk_free (ar_ptr=0x4016ca40, p=0x82fd0a0) at malloc.c:3097 3097malloc.c: No such file or directory. (gdb) bt #0 0x400d8076 in chunk_free (ar_ptr=0x4016ca40, p=0x82fd0a0) at malloc.c:3097 #1 0x400d7f5a in __libc_free (mem=0x82fd0a8) at malloc.c:3023 #2 0x8169142 in Perl_safesysfree (where=0x82fd0a8) at util.c:151 #3 0x8197ea2 in Perl_sv_clear (my_perl=0x82fc9c8, sv=0x86ed0bc) at sv.c:5049 hmm, looks like double free of SvPVX. if you could in gdb: (gdb) up 3 (gdb) print *sv (gdb) print *(XPV*)sv-sv_any might give a hint.
Re: Another SEGV perl 5.8.0-RC2 apache 1.3.26 mod_perl 1.27
On Sun, 30 Jun 2002 15:30:18 -0700 (PDT), Doug MacEachern [EMAIL PROTECTED]
said:
#0 0x400d8076 in chunk_free (ar_ptr=0x4016ca40, p=0x82fd0a0) at malloc.c:3097
#1 0x400d7f5a in __libc_free (mem=0x82fd0a8) at malloc.c:3023
#2 0x8169142 in Perl_safesysfree (where=0x82fd0a8) at util.c:151
#3 0x8197ea2 in Perl_sv_clear (my_perl=0x82fc9c8, sv=0x86ed0bc) at sv.c:5049
hmm, looks like double free of SvPVX. if you could in gdb:
(gdb) up 3
(gdb) print *sv
(gdb) print *(XPV*)sv-sv_any
(gdb) up 3
#3 0x8197fa2 in Perl_sv_clear (my_perl=0x82fcaa8, sv=0x86ed170) at sv.c:5049
5049Safefree(SvPVX(sv));
(gdb) print *sv
$1 = {sv_any = 0x8638d10, sv_refcnt = 0, sv_flags = 4194307}
(gdb) print *(XPV*)sv-sv_any
$2 = {xpv_pv = 0x82fd188 , xpv_cur = 0, xpv_len = 140741932}
--
andreas
Re: Another SEGV perl 5.8.0-RC2 apache 1.3.26 mod_perl 1.27
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
Another SEGV perl 5.8.0-RC2 apache 1.3.26 mod_perl 1.27
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. Again, as in my older posted SEGV, the line numbers are wrong, I do not know why. I'd appreciate any hint what I could try to come closer to a real bugreport. Program received signal SIGSEGV, Segmentation fault. 0x400d8076 in chunk_free (ar_ptr=0x4016ca40, p=0x8907350) at malloc.c:3097 3097malloc.c: No such file or directory. (gdb) bt #0 0x400d8076 in chunk_free (ar_ptr=0x4016ca40, p=0x8907350) at malloc.c:3097 #1 0x400d7f5a in __libc_free (mem=0x8907c88) at malloc.c:3023 #2 0x400d044b in _IO_new_fclose (fp=0x8907c88) at iofclose.c:61 #3 0x820c861 in PerlIOStdio_close (my_perl=0x82fc9c8, f=0x8303a00) at perlio.c:2638 #4 0x820a329 in Perl_PerlIO_close (my_perl=0x82fc9c8, f=0x8303a00) at perlio.c:1206 #5 0x8208b81 in PerlIO_cleantable (my_perl=0x82fc9c8, tablep=0x82fd3a0) at perlio.c:498 #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 #11 0x80ddc8e in run_cleanups () #12 0x80dc4bd in ap_clear_pool () #13 0x80dc531 in ap_destroy_pool () #14 0x80e945b in clean_child_exit () #15 0x80ec707 in child_main () #16 0x80eccb0 in make_child () #17 0x80ece09 in startup_children () #18 0x80ed466 in standalone_main () #19 0x80edc33 in main () #20 0x4009698b in __libc_start_main (main=0x80ed8dc main, argc=4, argv=0xbcd4, init=0x807a6f8 _init, fini=0x828da5c _fini, rtld_fini=0x4000ae60 _dl_fini, stack_end=0xbccc) at ../sysdeps/generic/libc-start.c:92 # /usr/local/perl-5.8.0-RC2/bin/perl -V Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration: Platform: osname=linux, osvers=2.2.18pre15, archname=i686-linux-multi uname='linux pause.perl.org 2.2.18pre15 #5 fri oct 13 21:59:16 cest 2000 i686 unknown ' config_args='-des -Dprefix=/usr/local/perl-5.8.0-RC2 -Dinstallusrbinperl=n -Uversiononly -Dusemultiplicity -Doptimize=-g' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=define useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-DDEBUGGING -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm', optimize='-g', cppflags='-DDEBUGGING -fno-strict-aliasing -I/usr/local/include -I/usr/include/gdbm' ccversion='', gccversion='egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=4, prototype=define Linker and Libraries: ld='cc', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-lnsl -lndbm -lgdbm -ldb -ldl -lm -lc -lposix -lcrypt -lutil perllibs=-lnsl -ldl -lm -lc -lposix -lcrypt -lutil libc=/lib/libc-2.1.3.so, so=so, useshrplib=false, libperl=libperl.a gnulibc_version='2.1.3' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic' cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: DEBUGGING MULTIPLICITY USE_LARGE_FILES PERL_IMPLICIT_CONTEXT Built under linux Compiled at Jun 24 2002 06:49:05 INC: /usr/local/perl-5.8.0-RC2/lib/5.8.0/i686-linux-multi /usr/local/perl-5.8.0-RC2/lib/5.8.0 /usr/local/perl-5.8.0-RC2/lib/site_perl/5.8.0/i686-linux-multi /usr/local/perl-5.8.0-RC2/lib/site_perl/5.8.0 /usr/local/perl-5.8.0-RC2/lib/site_perl . -- andreas
