PerlIO flush issue

[p5pRT]

Migrated from rt.perl.org#19863 (status was 'resolved')

Searchable as RT19863$

[p5pRT]

From acme@parrot.fotango.com

Created by acme@astray.com

I have a segfault bug under Perl 5.8.0 / mod_perl 1.27 (Apache 1.3.27) which
unfortunately isn't entirely reproducable and I can't knock the test case down to
less than tens of thousands of lines of code. I've also failed to get mod_perl to
give debugging symbols, so unfortunately the best I can offer at the moment is a
simple stack trace. Perhaps this will job someone's memory while I try and get
more information about the issue.

#0 0x400f01ee in fflush () from /lib/libc.so.6
#1 0x081b37ca in PerlIOStdio_flush ()
#2 0x081b183a in Perl_PerlIO_flush ()
#3 0x081b1904 in Perl_PerlIO_flush ()
#4 0x0818c40c in Perl_pp_system ()
#5 0x0812a9bd in Perl_runops_debug ()
#6 0x080dc86d in Perl_call_sv ()
#7 0x080dc4d3 in Perl_call_sv ()
#8 0x080818be in perl_call_handler ()
#9 0x08080f41 in perl_run_stacked_handlers ()
#10 0x0807f0d4 in perl_handler ()
#11 0x080ac749 in ap_invoke_handler ()
#12 0x080c250f in ap_some_auth_required ()
#13 0x080c257a in ap_process_request ()
#14 0x080b8e06 in ap_child_terminate ()
#15 0x080b908a in ap_child_terminate ()
#16 0x080b9146 in ap_child_terminate ()
#17 0x080b97dd in ap_child_terminate ()
#18 0x080ba04c in main ()
#19 0x400a5671 in __libc_start_main () from /lib/libc.so.6

Cheers, Leon

Perl Info

Flags:
    category=core
    severity=low

Site configuration information for perl v5.8.0:

Configured by acme at Wed Jan  8 16:07:48 GMT 2003.

Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration:
  Platform:
    osname=linux, osvers=2.4.19-gentoo-r7, archname=i686-linux
    uname='linux parrot.fotango.com 2.4.19-gentoo-r7 #1 tue jun 25 15:20:52 bst 2002 i686 pentium iii (coppermine) genuineintel gnulinux '
    config_args='-ds -e -Dprefix=/home/acme -Doptimize=-g'
    hint=recommended, useposix=true, d_sigaction=define
    usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef
    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 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
    optimize='-g',
    cppflags='-DDEBUGGING -fno-strict-aliasing'
    ccversion='', gccversion='2.95.3 20010315 (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 -lcrypt -lutil
    perllibs=-lnsl -ldl -lm -lc -lcrypt -lutil
    libc=/lib/libc-2.2.5.so, so=so, useshrplib=false, libperl=libperl.a
    gnulibc_version='2.2.5'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic'
    cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib'

Locally applied patches:
    


@INC for perl v5.8.0:
    /home/acme/lib/perl5/5.8.0/i686-linux
    /home/acme/lib/perl5/5.8.0
    /home/acme/lib/perl5/site_perl/5.8.0/i686-linux
    /home/acme/lib/perl5/site_perl/5.8.0
    /home/acme/lib/perl5/site_perl
    .


Environment for perl v5.8.0:
    HOME=/home/acme
    LANG (unset)
    LANGUAGE (unset)
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/home/acme/bin:/bin:/usr/bin:/usr/local/bin:/opt/bin:/usr/X11R6/bin:/opt/sun-jdk-1.4.0/bin:/opt/sun-jdk-1.4.0/jre/bin:/usr/qt/3/bin
    PERL_BADLANG (unset)
    SHELL=/bin/bash

[p5pRT]

arthur@contiller.se - Status changed from 'new' to 'open'

[p5pRT]

From arthur@contiller.se

This is full debugging stack trace.

#0 __pthread_mutex_lock (mutex=0x6120794d) at mutex.c​:82
#1 0x40460c2b in __flockfile (stream=0xa352ef8) at lockfile.c​:32
#2 0x40281630 in _IO_fflush (fp=0xa352ef8) at iofflush.c​:40
#3 0x81be543 in PerlIOStdio_flush (f=0x822906c) at perlio.c​:2812
#4 0x81bc727 in Perl_PerlIO_flush (f=0x822906c) at perlio.c​:1507
#5 0x81bc7e1 in Perl_PerlIO_flush (f=0x822906c) at perlio.c​:1535
#6 0x81303d2 in Perl_my_popen (cmd=0xa937488 "-", mode=0xbffff460 "r") at
util.c​:2084
#7 0x819ac1d in Perl_do_openn (gv=0xa4f5478, name=0xa937488 "-", len=1,
as_raw=0, rawmode=0, rawperm=0, supplied_fp=0x0,
  svp=0x96abbd8, num_svs=0) at doio.c​:490
#8 0x8185f4f in Perl_pp_open () at pp_sys.c​:542
#9 0x812bde4 in Perl_runops_debug () at dump.c​:1398
#10 0x80de7df in S_call_body (myop=0xbffff620, is_eval=0) at perl.c​:2045
#11 0x80de42f in Perl_call_sv (sv=0x980e698, flags=4) at perl.c​:1963
#12 0x8083d3c in perl_call_handler (sv=0x980e698, r=0xa33bbec, args=0x0) at
mod_perl.c​:1658
#13 0x8083238 in perl_run_stacked_handlers (hook=0x81d7099 "PerlHandler",
r=0xa33bbec, handlers=0x82a4670) at mod_perl.c​:1371
#14 0x80808c8 in perl_handler (r=0xa33bbec) at mod_perl.c​:897
#15 0x80afa93 in ap_invoke_handler (r=0xa33bbec) at http_config.c​:518
#16 0x80c47e9 in process_request_internal (r=0xa33bbec) at http_request.c​:1308
#17 0x80c484c in ap_process_request (r=0xa33bbec) at http_request.c​:1324
#18 0x80bb84e in child_main (child_num_arg=0) at http_main.c​:4603
#19 0x80bba8c in make_child (s=0x82182cc, slot=0, now=1052215224) at
http_main.c​:4773
---Type <return> to continue, or q <return> to quit---
#20 0x80bbb39 in startup_children (number_to_start=2) at http_main.c​:4800
#21 0x80bc196 in standalone_main (argc=3, argv=0xbffff874) at http_main.c​:5108
#22 0x80bc963 in main (argc=3, argv=0xbffff874) at http_main.c​:5456

[p5pRT]

From arthur@contiller.se

This bug is essentially a dupe of http​://mathforum.org/epigone/modperl/
zhoolamgheld/m3lm9ml44m.fsf@​k242.linux.bogus which was reported by Andreas
König Tue, 11 Jun 2002 and caused quite a lot of headache before the culprit was
found.

The solution to the bug is to upgrade to libapreq 1.1 / Apache​::Request 1.1 since 1.0 is
the offending module. Sadly 1.1 was not released until february 2003 even if the patch
was from the summer 2002. 1.1 incorprates the patch slightly differently and even more
robust. The other solution is to make sure you don't have upload filehandles around
when you do a system() call (or anything that flushes all filehandles).

What happens essentially is that Apache​::Request gets a filehandle for the upload and
tells perl about it, however it forgot to tell Perl it was a readonly filehandle. So when perl
does a backtik or system operation it tries to flush all filehandles, this include trying to
flush the readonly filehandle it thought was writeable. This lead to a segfault depending
on what data was in there.

Apache​::Request 1.1 fixes this by importing the filehandle as readonly.

Arthur

[p5pRT]

arthur@contiller.se - Status changed from 'open' to 'resolved'