Another thread bomb; save_scalar_at

[p5pRT]

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

Searchable as RT1353$

[p5pRT]

From rkc@ll.mit.edu

---

Current directory is /data/esc1/src/parse/
GNU gdb 4.17
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "sparc-sun-solaris2.6"...
(gdb) core core
warning​: core file may not match specified executable file.
Core was generated by `/usr/local/bin/perl -w ./rtbv.pl'.
Program terminated with signal 9, Killed.
Reading symbols from /usr/lib/libsocket.so.1...done.
Reading symbols from /usr/lib/libnsl.so.1...done.
Reading symbols from /usr/lib/libdl.so.1...done.
Reading symbols from /usr/lib/libm.so.1...done.
Reading symbols from /usr/lib/libposix4.so.1...done.
Reading symbols from /usr/lib/libpthread.so.1...done.
Reading symbols from /usr/lib/libc.so.1...done.
Reading symbols from /usr/lib/libmp.so.2...done.
Reading symbols from /usr/lib/libaio.so.1...done.
Reading symbols from /usr/platform/SUNW,Ultra-30/lib/libc_psr.so.1...done.
Reading symbols from /usr/lib/libthread.so.1...done.
Reading symbols from
/usr/local/lib/perl5/site_perl/5.005/sun4-solaris-thread/auto/DBI/DBI.so...done.

Reading symbols from
/usr/local/lib/perl5/5.00503/sun4-solaris-thread/auto/attrs/attrs.so...done.

Reading symbols from
/usr/local/lib/perl5/site_perl/5.005/sun4-solaris-thread/auto/DBD/mysql/mysql.so...done.

Reading symbols from
/usr/local/lib/perl5/5.00503/sun4-solaris-thread/auto/Thread/Thread.so...done.

Reading symbols from
/usr/local/lib/perl5/5.00503/sun4-solaris-thread/auto/IO/IO.so...done.
Reading symbols from
/usr/local/lib/perl5/5.00503/sun4-solaris-thread/auto/Fcntl/Fcntl.so...done.

Reading symbols from
/usr/local/lib/perl5/5.00503/sun4-solaris-thread/auto/Socket/Socket.so...done.

Reading symbols from
/usr/local/lib/perl5/5.00503/sun4-solaris-thread/auto/IPC/SysV/SysV.so...done.

Reading symbols from /usr/lib/nss_files.so.1...done.
#0 0x7c7d8 in save_scalar_at ()
(gdb) where
#0 0x7c7d8 in save_scalar_at ()
#1 0x7c990 in Perl_save_scalar ()
#2 0x5cd48 in Perl_pp_gvsv ()
#3 0x9cadc in Perl_runops_standard ()
#4 0x21b94 in perl_call_sv ()
#5 0xef4721d0 in threadstart ()
(gdb) quit

Debugger finished

---

---

Site configuration information for perl 5.00503​:

Configured by rkc at Fri Jun 11 14​:28​:51 EDT 1999.

Summary of my perl5 (5.0 patchlevel 5 subversion 3) configuration​:
  Platform​:
  osname=solaris, osvers=2.6, archname=sun4-solaris-thread
  uname='sunos bruno 5.6 generic_105181-03 sun4u sparc sunw,ultra-30 '
  hint=recommended, useposix=true, d_sigaction=define
  usethreads=define useperlio=undef d_sfio=undef
  Compiler​:
  cc='gcc', optimize='-O', gccversion=2.8.1
  cppflags='-D_REENTRANT -I/usr/local/include -I/opt/local/include
-I/opt/gnu/include'
  ccflags ='-D_REENTRANT -I/usr/local/include -I/opt/local/include
-I/opt/gnu/include'
  stdchar='unsigned char', d_stdstdio=define, usevfork=false
  intsize=4, longsize=4, ptrsize=4, doublesize=8
  d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
  alignbytes=8, usemymalloc=y, prototype=define
  Linker and Libraries​:
  ld='gcc', ldflags =' -L/usr/local/lib -L/opt/local/lib -L/opt/gnu/lib'
  libpth=/usr/local/lib /opt/local/lib /opt/gnu/lib /lib /usr/lib
/usr/ccs/lib
  libs=-lsocket -lnsl -ldb -ldl -lm -lposix4 -lpthread -lc -lcrypt
  libc=/lib/libc.so, so=so, useshrplib=false, libperl=libperl.a
  Dynamic Linking​:
  dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' '
  cccdlflags='-fPIC', lddlflags='-G -L/usr/local/lib -L/opt/local/lib
-L/opt/gnu/lib'

Locally applied patches​:
 

---

@​INC for perl 5.00503​:
  /usr/local/lib/perl5/5.00503/sun4-solaris-thread
  /usr/local/lib/perl5/5.00503
  /usr/local/lib/perl5/site_perl/5.005/sun4-solaris-thread
  /usr/local/lib/perl5/site_perl/5.005
  .

---

Environment for perl 5.00503​:
  HOME=/export/home/rkc
  LANG=C
  LANGUAGE (unset)
  LD_LIBRARY_PATH=/opt/SUNWspro/lib​:/usr/openwin/lib​:/usr/local/lib
  LOGDIR (unset)
 
PATH=/opt/local/bin​:/usr/local/jdk1.1.2/bin​:/opt/SUNWspro/bin​:/export/home/rkc​:/opt/local/tcpdump​:/data/se4/mcclung/audit_tools​:/data/se4/mcclung/tcpdumpfiles/scripts​:/usr/openwin/bin/xview​:/usr/openwin/bin​:/1/security/bin​:/bin​:/usr/local/bin​:/usr/ucb​:/usr/bin​:/usr/etc​:/data/se0/gnu/bin​:/opt/local/SunOS4/bin​:/opt/local/bin​:/data/se0/rpl/lnknet/bin​:/data/se0/rpl/stat/bin​:/usr/ccs/bin​:/opt/local/SunOS4/bin​:/export/home/rkc/bin​:/.sim/bin​:/usr/local/mysql/bin
 
PERL_BADLANG (unset)
  SHELL=/bin/tcsh

--
Dr. Robert K. Cunningham Information System Technology Group
  rkc@​ll.mit.edu MIT Lincoln Laboratory
*** My comments, my opinions​: my responsibility.
PGP key available from http​://pgpkeys.mit.edu​:11371

[p5pRT]

From [Unknown Contact. See original ticket]

On Thu, 9 Sep 1999, Rob Cunningham wrote​:

This is a bug report for perl from rkc@​ll.mit.edu
generated with the help of perlbug 1.26 running under perl 5.00503.

-----------------------------------------------------------------

[GDB trace snipped]

While I don't want to downplay the usefulness of a GDB calltrace (or
whatever it's named), it's really not enough information to identify a
bug. Could you perhaps send the (hopefully short) piece perl code that
triggered this program death? (Keeping in mind that accessing any perl
variable from two threads simultaneously, without using the lock()
primitive to coordinate access, has the potential to kill the perl
interpreter at some, possibly random, point)

  Dan

[p5pRT]

From [Unknown Contact. See original ticket]

Alas, the code is for an application that is > 10,000 lines long, and
the bug only appears after more than ten minutes of processing many
megabytes of data. I tried to cut the code down, but couldn't get the
bug to re-occur, thus my less-than-completely useful report. Would it
be useful if I re-compile perl with -g and give you the exact line it
died on, or would this not really help much?

BTW, I have seen perl spawn more than 130 threads executing this
application, happily co-existing and running. (Thanks for your perl
thread regexp workaround.)

As for your concern about multi-threaded access of a global variable, I
do not believe that I access any unlocked global variable from multiple
threads, other than to read global configuration variables set up before
threads are spawned.

Rob

Dan Sugalski wrote​:

On Thu, 9 Sep 1999, Rob Cunningham wrote​:

This is a bug report for perl from rkc@​ll.mit.edu
generated with the help of perlbug 1.26 running under perl 5.00503.

-----------------------------------------------------------------

[GDB trace snipped]

While I don't want to downplay the usefulness of a GDB calltrace (or
whatever it's named), it's really not enough information to identify a
bug. Could you perhaps send the (hopefully short) piece perl code that
triggered this program death? (Keeping in mind that accessing any perl
variable from two threads simultaneously, without using the lock()
primitive to coordinate access, has the potential to kill the perl
interpreter at some, possibly random, point)

                                    Dan

--
Dr. Robert K. Cunningham Information System Technology Group
  rkc@​ll.mit.edu MIT Lincoln Laboratory
*** My comments, my opinions​: my responsibility.
PGP key available from http​://pgpkeys.mit.edu​:11371

[p5pRT]

From [Unknown Contact. See original ticket]

On Thu, 9 Sep 1999, Rob Cunningham wrote​:

Alas, the code is for an application that is > 10,000 lines long, and
the bug only appears after more than ten minutes of processing many
megabytes of data. I tried to cut the code down, but couldn't get the
bug to re-occur, thus my less-than-completely useful report. Would it
be useful if I re-compile perl with -g and give you the exact line it
died on, or would this not really help much?

Not much, unfortunately. There's unlikely to be enough info available.

BTW, I have seen perl spawn more than 130 threads executing this
application, happily co-existing and running. (Thanks for your perl
thread regexp workaround.)

Cool!

As for your concern about multi-threaded access of a global variable, I
do not believe that I access any unlocked global variable from multiple
threads, other than to read global configuration variables set up before
threads are spawned.

It's remotely possible that the global reads are causing the problem, but
not that likely. (Read access in perl code can update the underlying data
structures if they need to be promoted. Printing a scalar variable that
was an integer stringifies it and caches the stringified value, for
example, which can cause problems) It's also possible that something went
wrong early in the program but the corruption was only noticed later.

Debugging threaded code is, unfortunately, an amazing pain at times. :(

  Dan