threads + 'require IO' causes segmentation fault #8094

p5pRT · 2005-09-05T08:42:50Z

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

Searchable as RT37076$

p5pRT · 2005-09-05T08:42:51Z

From ikegami@ni.aist.go.jp

Created by ikegami@p06cmp000.asc.hpcc.jp

On dual Opteron (2 GHz) machine, perl 5.8.7 frequently causes
segmentation fault with the following code snippet.

#!/usr/bin/perl
use threads;
use threads::shared;

sub socket () {
require IO;
return;
}

my $s = new threads \&socket;
my $c = new threads \&socket;

$s->join;
$c->join;

It is not reproducible by 100 %, and may not be reproducible on
slow/single-processor machines. As a workaround, put 'use IO'
somewhere. A stack trace taken from core file follows.

#0 0x0000002a95da8d88 in chunk_alloc () from /lib64/libc.so.6
#1 0x0000002a95da8bc1 in malloc () from /lib64/libc.so.6
#2 0x0000000040065cb0 in Perl_safesysmalloc ()
#3 0x000000004007026f in S_save_hek_flags ()
#4 0x00000000400712fb in S_share_hek_flags ()
#5 0x00000000400722ee in S_hv_fetch_common ()
#6 0x0000000040072c20 in Perl_hv_fetch ()
#7 0x0000000040026ff7 in Perl_gv_fetchpv ()
#8 0x00000000400484a6 in Perl_newXS ()
#9 0x0000000040048a9e in Perl_newCONSTSUB ()
#10 0x0000002a9670225a in boot_IO ()
from /home/ikegami/local/perl/lib/5.8.7/x86_64-linux-thread-multi/auto/IO/IO.so
#11 0x000000004007780f in Perl_pp_entersub ()
#12 0x000000004007609e in Perl_runops_standard ()
#13 0x000000004001f92d in S_call_body ()
#14 0x0000000040020741 in Perl_call_sv ()
#15 0x00000000400209ec in Perl_call_list ()
#16 0x00000000400527bc in Perl_newATTRSUB ()
#17 0x00000000400510bb in Perl_utilize ()
#18 0x00000000400434af in Perl_yyparse ()
#19 0x00000000400a6e4a in S_doeval ()
#20 0x00000000400a890d in Perl_pp_require ()
#21 0x000000004007609e in Perl_runops_standard ()
#22 0x000000004001f92d in S_call_body ()
#23 0x0000000040020741 in Perl_call_sv ()
#24 0x00000000400209ec in Perl_call_list ()
#25 0x00000000400527bc in Perl_newATTRSUB ()
#26 0x00000000400510bb in Perl_utilize ()
#27 0x00000000400434af in Perl_yyparse ()
#28 0x00000000400a6e4a in S_doeval ()
#29 0x00000000400a890d in Perl_pp_require ()
#30 0x000000004007609e in Perl_runops_standard ()
#31 0x000000004001f92d in S_call_body ()
#32 0x0000000040020741 in Perl_call_sv ()
#33 0x0000002a95f6f020 in Perl_ithread_run ()
from /home/ikegami/local/perl/lib/5.8.7/x86_64-linux-thread-multi/auto/threads/threads.so
#34 0x0000002a95c22c26 in pthread_start_thread () from /lib64/libpthread.so.0
#35 0x0000002a95dfbc95 in thread_start () from /lib64/libc.so.6

Perl Info


Flags:
    category=core
    severity=low

Site configuration information for perl v5.8.7:

Configured by ikegami at Tue Jun 21 18:32:40 JST 2005.

Summary of my perl5 (revision 5 version 8 subversion 7) configuration:
  Platform:
    osname=linux, osvers=2.4.21-251-smp, archname=x86_64-linux-thread-multi
    uname='linux p06cmp000.asc.hpcc.jp 2.4.21-251-smp #1 smp sun nov 7 22:25:59 jst 2004 x86_64 unknown '
    config_args='-ds -e -Dprefix=/home/ikegami/local/perl -Dusethreads'
    hint=recommended, useposix=true, d_sigaction=define
    usethreads=define use5005threads=undef useithreads=define usemultiplicity=define
    useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
    use64bitint=define use64bitall=define uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
    optimize='-O2',
    cppflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -fno-strict-aliasing -pipe -I/usr/local/include'
    ccversion='', gccversion='3.3.3 (SUSE Linux)', gccosandvers=''
    intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
    ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
    alignbytes=8, prototype=define
  Linker and Libraries:
    ld='cc', ldflags =' -L/usr/local/lib'
    libpth=/usr/local/lib /lib /usr/lib
    libs=-lnsl -ldl -lm -lcrypt -lutil -lpthread -lc
    perllibs=-lnsl -ldl -lm -lcrypt -lutil -lpthread -lc
    libc=, so=so, useshrplib=false, libperl=libperl.a
    gnulibc_version='2.2.5'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
    cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib'

Locally applied patches:
    


@INC for perl v5.8.7:
    /home/ikegami/lib/perl/x86_64-linux-thread-multi
    /home/ikegami/lib/perl
    /home/ikegami/local/perl/lib/5.8.7/x86_64-linux-thread-multi
    /home/ikegami/local/perl/lib/5.8.7
    /home/ikegami/local/perl/lib/site_perl/5.8.7/x86_64-linux-thread-multi
    /home/ikegami/local/perl/lib/site_perl/5.8.7
    /home/ikegami/local/perl/lib/site_perl
    .


Environment for perl v5.8.7:
    HOME=/home/ikegami
    LANG=ja_JP.ujis
    LANGUAGE (unset)
    LC_COLLATE=POSIX
    LD_LIBRARY_PATH=/home/ikegami/local/intel_fc_80/lib:/home/ikegami/local/intel_cc_80/lib:/opt/intel_fc_80/lib:/opt/intel_cc_80/lib:/opt/gt2/lib:/home/ikegami/local/lib
    LOGDIR (unset)
    PATH=/home/ikegami/local/ninfg-2.4.0/bin:/home/ikegami/bin:/home/ikegami/util:/home/ikegami/local/bin:/opt/gcc33/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/X11R6/bin:/home/ikegami/local/intel_fc_80/bin:/home/ikegami/local/intel_cc_80/bin:/opt/score/bin:/opt/score/sbin:/opt/score/deploy:/usr/pbs/bin:/opt/intel_fc_80/bin:/opt/intel_cc_80/bin:/opt/gt2/bin:/opt/gt2/sbin:/usr/games:/opt/gnome2/bin:/opt/gnome/bin:/opt/kde3/bin:/usr/lib/java/bin:/opt/gm/bin:/opt/pathscale/bin:/opt/pgi/linux86-64/5.2/bin:/opt/pgi/linux86/5.2/bin:.
    PERL5LIB=/home/ikegami/lib/perl
    PERL_BADLANG (unset)
    SHELL=/bin/bash

p5pRT · 2005-09-05T15:18:50Z

From @nwc10

On Mon, Sep 05, 2005 at 01:42:52AM -0700, ikegami @ ni. aist. go. jp wrote:

On dual Opteron (2 GHz) machine, perl 5.8.7 frequently causes
segmentation fault with the following code snippet.
    \#\!/usr/bin/perl
    use threads;
    use threads&#8203;::shared;
    
    sub socket  \{
      require IO;
      return;
    \}
    
    my $s = new threads \\&socket;
    my $c = new threads \\&socket;
    
    $s\->join;
    $c\->join;
It is not reproducible by 100 %, and may not be reproducible on
slow/single-processor machines. As a workaround, put 'use IO'
somewhere. A stack trace taken from core file follows.

It's more like 1-5% reproducible on x86 Linux (this was a dual CPU machine)

#0 0x0000002a95da8d88 in chunk_alloc () from /lib64/libc.so.6
#1 0x0000002a95da8bc1 in malloc () from /lib64/libc.so.6
#2 0x0000000040065cb0 in Perl_safesysmalloc ()
#3 0x000000004007026f in S_save_hek_flags ()
#4 0x00000000400712fb in S_share_hek_flags ()
#5 0x00000000400722ee in S_hv_fetch_common ()
#6 0x0000000040072c20 in Perl_hv_fetch ()
#7 0x0000000040026ff7 in Perl_gv_fetchpv ()
#8 0x00000000400484a6 in Perl_newXS ()
#9 0x0000000040048a9e in Perl_newCONSTSUB ()
#10 0x0000002a9670225a in boot_IO ()
from /home/ikegami/local/perl/lib/5.8.7/x86_64-linux-thread-multi/auto/IO/IO.so
#11 0x000000004007780f in Perl_pp_entersub ()
#12 0x000000004007609e in Perl_runops_standard ()
#13 0x000000004001f92d in S_call_body ()
#14 0x0000000040020741 in Perl_call_sv ()
#15 0x00000000400209ec in Perl_call_list ()
#16 0x00000000400527bc in Perl_newATTRSUB ()
#17 0x00000000400510bb in Perl_utilize ()
#18 0x00000000400434af in Perl_yyparse ()
#19 0x00000000400a6e4a in S_doeval ()
#20 0x00000000400a890d in Perl_pp_require ()
#21 0x000000004007609e in Perl_runops_standard ()
#22 0x000000004001f92d in S_call_body ()
#23 0x0000000040020741 in Perl_call_sv ()
#24 0x00000000400209ec in Perl_call_list ()
#25 0x00000000400527bc in Perl_newATTRSUB ()
#26 0x00000000400510bb in Perl_utilize ()
#27 0x00000000400434af in Perl_yyparse ()
#28 0x00000000400a6e4a in S_doeval ()
#29 0x00000000400a890d in Perl_pp_require ()
#30 0x000000004007609e in Perl_runops_standard ()
#31 0x000000004001f92d in S_call_body ()
#32 0x0000000040020741 in Perl_call_sv ()
#33 0x0000002a95f6f020 in Perl_ithread_run ()
from /home/ikegami/local/perl/lib/5.8.7/x86_64-linux-thread-multi/auto/threads/threads.so
#34 0x0000002a95c22c26 in pthread_start_thread () from /lib64/libpthread.so.0
#35 0x0000002a95dfbc95 in thread_start () from /lib64/libc.so.6

Stack backtrace from blead compiled with -g

#0 0xb749fa8e in _int_malloc () from /lib/tls/libc.so.6
(gdb) where
#0 0xb749fa8e in _int_malloc () from /lib/tls/libc.so.6
#1 0xb749ee9d in malloc () from /lib/tls/libc.so.6
#2 0x080d3b77 in Perl_savesharedpv (my_perl=0x8347568,
pv=0x841a5ec "IO::Handle") at util.c:820
#3 0x080aa378 in Perl_newCONSTSUB (my_perl=0x8347568, stash=0x8414700,
name=0xb5efd321 "SEEK_CUR", sv=0x8403b08) at op.c:4610
#4 0xb5efcd9b in boot_IO (my_perl=0x8347568, cv=0x84b5a48) at IO.xs:497
#5 0x080fa824 in Perl_pp_entersub (my_perl=0x8347568) at pp_hot.c:2788
#6 0x080d1d9c in Perl_runops_debug (my_perl=0x8347568) at dump.c:1597
#7 0x0806841a in S_call_body (my_perl=0x8347568, myop=0xb68ffa10,
is_eval=0 '\0') at perl.c:2617
#8 0x08067ef8 in Perl_call_sv (my_perl=0x8347568, sv=0x84b5948, flags=4)
at perl.c:2546
#9 0xb75e640a in Perl_ithread_run (arg=0x8347520) at threads.xs:301
#10 0xb756adec in start_thread () from /lib/tls/libpthread.so.0
#11 0xb750aa2a in clone () from /lib/tls/libc.so.6

backtrace from blead compiled -O2

(gdb) where
#0 0xb74a02c0 in malloc_consolidate () from /lib/tls/libc.so.6
#1 0xb749faf9 in _int_malloc () from /lib/tls/libc.so.6
#2 0xb749ee9d in malloc () from /lib/tls/libc.so.6
#3 0x080b071f in Perl_safesysmalloc ()
#4 0x080bfe1b in S_hsplit ()
#5 0x080c0391 in S_share_hek_flags ()
#6 0x080c123e in S_hv_fetch_common ()
#7 0x080c1211 in S_hv_fetch_common ()
#8 0x080c1e4e in Perl_hv_fetch ()
#9 0x0806abad in Perl_gv_fetchpvn_flags ()
#10 0x0806bf33 in Perl_gv_fetchpv ()
#11 0x0808e475 in Perl_newXS ()
#12 0xb5efdb20 in ?? () from lib/auto/IO/IO.so
#13 0x00000002 in ?? ()
#14 0x0000000d in ?? ()
#15 0x083d34b8 in ?? ()
#16 0x082737d8 in ?? ()
#17 0x00000010 in ?? ()
#18 0x082737a0 in ?? ()
#19 0x082dd3c0 in ?? ()
#20 0x082bc428 in ?? ()
#21 0xb68ff858 in ?? ()
#22 0x0808eb33 in Perl_newCONSTSUB ()
Previous frame inner to this frame (corrupt stack?)

From 5.8.7 compiled -O2

(gdb) where
#0 0xb749fa8e in _int_malloc () from /lib/tls/libc.so.6
#1 0xb749ee9d in malloc () from /lib/tls/libc.so.6
#2 0x080ad937 in Perl_savesharedpv ()
#3 0x0808d698 in Perl_newCONSTSUB ()
#4 0xb5f94441 in boot_IO () from lib/auto/IO/IO.so
#5 0x080c5b6d in Perl_pp_entersub ()
#6 0x080be7e9 in Perl_runops_standard ()
#7 0x080641ba in Perl_call_sv ()
#8 0xb7407de0 in Perl_ithread_run () from lib/auto/threads/threads.so
#9 0xb756adec in start_thread () from /lib/tls/libpthread.so.0
#10 0xb750aa2a in clone () from /lib/tls/libc.so.6

(gdb) where
#0 0xb749fa8e in _int_malloc () from /lib/tls/libc.so.6
#1 0xb749ee9d in malloc () from /lib/tls/libc.so.6
#2 0x080ac90f in Perl_safesysmalloc ()
#3 0x080cac1e in Perl_sv_grow ()
#4 0x080cafe6 in Perl_sv_setpv ()
#5 0x0808d6fa in Perl_newCONSTSUB ()
#6 0xb5dfd3df in boot_IO () from lib/auto/IO/IO.so
#7 0x080c5b6d in Perl_pp_entersub ()
#8 0x080be7e9 in Perl_runops_standard ()
#9 0x080641ba in Perl_call_sv ()
#10 0xb7407de0 in Perl_ithread_run () from lib/auto/threads/threads.so
#11 0xb756adec in start_thread () from /lib/tls/libpthread.so.0
#12 0xb750aa2a in clone () from /lib/tls/libc.so.6

So I assume that all this in-malloc() corruption comes from scribbling over
memory at some other point in some other thread. Reasonable?

Nicholas Clark

p5pRT · 2005-09-05T15:18:52Z

The RT System itself - Status changed from 'new' to 'open'

p5pRT · 2006-01-09T01:08:15Z

From @iabyn

On Mon, Sep 05, 2005 at 04:18:11PM +0100, Nicholas Clark wrote:

On Mon, Sep 05, 2005 at 01:42:52AM -0700, ikegami @ ni. aist. go. jp wrote:
On dual Opteron (2 GHz) machine, perl 5.8.7 frequently causes
segmentation fault with the following code snippet.
    \#\!/usr/bin/perl
    use threads;
    use threads&#8203;::shared;
    
    sub socket  \{
      require IO;
      return;
    \}
    
    my $s = new threads \\&socket;
    my $c = new threads \\&socket;
    
    $s\->join;
    $c\->join;
It is not reproducible by 100 %, and may not be reproducible on
slow/single-processor machines. As a workaround, put 'use IO'
somewhere. A stack trace taken from core file follows.
It's more like 1-5% reproducible on x86 Linux (this was a dual CPU machine)

It's more reproducable on a 4-CPU x86_64 box.

It turns out that IO.xs's BOOT section calls newCONSTSUB(), and
newCONSTSUB() isn't threadsafe, as it messes with fields of PL_curcop,
while ops are shared between threads. Whoops.

Not sure yet what the best fix is, or how pervasive this problem is (ie
what other code (if any) diddles with PL_curcop fields?)

--
"Do not dabble in paradox, Edward, it puts you in danger of fortuitous
wit." -- Lady Croom - Arcadia

p5pRT · 2006-04-19T08:32:35Z

From @nwc10

On Mon, Jan 09, 2006 at 01:09:32AM +0000, Dave Mitchell wrote:

It turns out that IO.xs's BOOT section calls newCONSTSUB(), and
newCONSTSUB() isn't threadsafe, as it messes with fields of PL_curcop,
while ops are shared between threads. Whoops.

Not sure yet what the best fix is, or how pervasive this problem is (ie
what other code (if any) diddles with PL_curcop fields?)

I think a solution would be to rewrite newCONSTSUB so that it doesn't
use any of PL_curcop (etc). It's doing a rather simple job, and currently
it seems that it's calling into a complex function to get its work done.
I assume that it can be turned inside out, so that either newXS calls it,
or both call a shared function that does what it needs, but I've not looked
into the practicality of this.

Nicholas Clark

p5pRT · 2008-05-24T22:07:41Z

From p5p@spam.wizbit.be

On Mon Sep 05 01:42:51 2005, ikegami@ni.aist.go.jp wrote:

This is a bug report for perl from ikegami@p06cmp000.asc.hpcc.jp,
generated with the help of perlbug 1.35 running under perl v5.8.7.

-----------------------------------------------------------------
[Please enter your report here]

On dual Opteron (2 GHz) machine, perl 5.8.7 frequently causes
segmentation fault with the following code snippet.
    \#\!/usr/bin/perl
    use threads;
    use threads&#8203;::shared;

    sub socket  \{
      require IO;
      return;
    \}

    my $s = new threads \\&socket;
    my $c = new threads \\&socket;

    $s\->join;
    $c\->join;
It is not reproducible by 100 %, and may not be reproducible on
slow/single-processor machines. As a workaround, put 'use IO'
somewhere. A stack trace taken from core file follows.

Re-tested this with:

perl-5.8.8: segfault
perl-5.8.x: no segfault
perl-5.10: no segfault
perl-blead: no segfault

by using:

perl -wle 'for (1 .. 5000) { system("./perl -Ilib /tmp/rt-37076.pl"); }'

So I'm assuming this got resolved.

Can someone else test as well?

Kind regards,

Bram

p5pRT · 2008-06-22T09:29:26Z

p5p@spam.wizbit.be - Status changed from 'open' to 'resolved'

p5pRT · 2008-08-03T20:11:37Z

From p5p@spam.wizbit.be

This was fixed by Change 32091.

http://public.activestate.com/cgi-bin/perlbrowse/p/32091
Change 32091 by davem@davem-pigeon on 2007/10/10 15:03:16

newCONTSUB() wasn't thread-safe ([perl #45053])

p5pRT closed this as completed Jun 22, 2008

p5pRT added Severity Low distro-Linux type-core labels Oct 18, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

threads + 'require IO' causes segmentation fault #8094

threads + 'require IO' causes segmentation fault #8094

p5pRT commented Sep 5, 2005

p5pRT commented Sep 5, 2005

p5pRT commented Sep 5, 2005

p5pRT commented Sep 5, 2005

p5pRT commented Jan 9, 2006

p5pRT commented Apr 19, 2006

p5pRT commented May 24, 2008

p5pRT commented Jun 22, 2008

p5pRT commented Aug 3, 2008

threads + 'require IO' causes segmentation fault #8094

threads + 'require IO' causes segmentation fault #8094

Comments

p5pRT commented Sep 5, 2005

p5pRT commented Sep 5, 2005

From ikegami@ni.aist.go.jp

Created by ikegami@p06cmp000.asc.hpcc.jp

p5pRT commented Sep 5, 2005

From @nwc10

p5pRT commented Sep 5, 2005

p5pRT commented Jan 9, 2006

From @iabyn

p5pRT commented Apr 19, 2006

From @nwc10

p5pRT commented May 24, 2008

From p5p@spam.wizbit.be

p5pRT commented Jun 22, 2008

p5pRT commented Aug 3, 2008

From p5p@spam.wizbit.be