Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Internal warning from exception inside a grep #8096

Closed
p5pRT opened this issue Sep 7, 2005 · 7 comments
Closed

Internal warning from exception inside a grep #8096

p5pRT opened this issue Sep 7, 2005 · 7 comments

Comments

@p5pRT
Copy link

p5pRT commented Sep 7, 2005

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

Searchable as RT37094$

@p5pRT
Copy link
Author

p5pRT commented Sep 7, 2005

From chris@heathens.co.nz

Created by chris@heathens.co.nz

This is a bug report for perl from chris@​heathens.co.nz,
generated with the help of perlbug 1.35 running under perl v5.8.6.

-----------------------------------------------------------------
Throwing an exception inside a grep sometimes causes Perl
to emit an internal warning.

$ perl -e 'for ("foo") { grep(die, "bar") }'
Died at -e line 1.
Attempt to free unreferenced scalar​: SV 0x96c61dc, Perl interpreter​: 0x96ae008.

Does this warning indicate possible internal corruption? I have seen
some Perl corruption in a production system at my work recently, as well
as this warning, so I wondered if they could be related.

Perl Info

Flags:
    category=core
    severity=low

This perlbug was built using Perl v5.8.6 in the Red Hat build system.
It is being executed now by Perl v5.8.6 - Wed May 18 18:20:12 EDT 2005.

Site configuration information for perl v5.8.6:

Configured by Red Hat, Inc. at Wed May 18 18:20:12 EDT 2005.

Summary of my perl5 (revision 5 version 8 subversion 6) configuration:
  Platform:
    osname=linux, osvers=2.4.21-27.0.2.elsmp, archname=i386-linux-thread-multi
    uname='linux decompose.build.redhat.com 2.4.21-27.0.2.elsmp #1 smp wed jan 12 23:35:44 est 2005 i686 i686 i386 gnulinux '
    config_args='-des -Doptimize=-O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -m32 -march=i386 -mtune=pentium4 -fasynchronous-unwind-tables -Dversion=5.8.6 -Dmyhostname=localhost -Dperladmin=root@localhost -Dcc=gcc -Dcf_by=Red Hat, Inc. -Dinstallprefix=/usr -Dprefix=/usr -Darchname=i386-linux -Dvendorprefix=/usr -Dsiteprefix=/usr -Duseshrplib -Dusethreads -Duseithreads -Duselargefiles -Dd_dosuid -Dd_semctl_semun -Di_db -Ui_ndbm -Di_gdbm -Di_shadow -Di_syslog -Dman3ext=3pm -Duseperlio -Dinstallusrbinperl=n -Ubincompat5005 -Uversiononly -Dpager=/usr/bin/less -isr -Dd_gethostent_r_proto -Ud_endhostent_r_proto -Ud_endprotoent_r_proto -Ud_endservent_r_proto -Ud_sethostent_r_proto -Ud_setprotoent_r_proto -Ud_setservent_r_proto -Dinc_version_list=5.8.5 5.8.4 5.8.3'
    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=undef use64bitall=undef uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='gcc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DDEBUGGING -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm',
    optimize='-O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -m32 -march=i386 -mtune=pentium4 -fasynchronous-unwind-tables',
    cppflags='-D_REENTRANT -D_GNU_SOURCE -DDEBUGGING -fno-strict-aliasing -pipe -I/usr/local/include -I/usr/include/gdbm'
    ccversion='', gccversion='4.0.0 20050516 (Red Hat 4.0.0-6)', 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='gcc', ldflags =' -L/usr/local/lib'
    libpth=/usr/local/lib /lib /usr/lib
    libs=-lresolv -lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lpthread -lc
    perllibs=-lresolv -lnsl -ldl -lm -lcrypt -lutil -lpthread -lc
    libc=/lib/libc-2.3.5.so, so=so, useshrplib=true, libperl=libperl.so
    gnulibc_version='2.3.5'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E -Wl,-rpath,/usr/lib/perl5/5.8.6/i386-linux-thread-multi/CORE'
    cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib'

Locally applied patches:
    


@INC for perl v5.8.6:
    /usr/lib/perl5/site_perl/5.8.6/i386-linux-thread-multi
    /usr/lib/perl5/site_perl/5.8.5/i386-linux-thread-multi
    /usr/lib/perl5/site_perl/5.8.4/i386-linux-thread-multi
    /usr/lib/perl5/site_perl/5.8.3/i386-linux-thread-multi
    /usr/lib/perl5/site_perl/5.8.6
    /usr/lib/perl5/site_perl/5.8.5
    /usr/lib/perl5/site_perl/5.8.4
    /usr/lib/perl5/site_perl/5.8.3
    /usr/lib/perl5/site_perl
    /usr/lib/perl5/vendor_perl/5.8.6/i386-linux-thread-multi
    /usr/lib/perl5/vendor_perl/5.8.5/i386-linux-thread-multi
    /usr/lib/perl5/vendor_perl/5.8.4/i386-linux-thread-multi
    /usr/lib/perl5/vendor_perl/5.8.3/i386-linux-thread-multi
    /usr/lib/perl5/vendor_perl/5.8.6
    /usr/lib/perl5/vendor_perl/5.8.5
    /usr/lib/perl5/vendor_perl/5.8.4
    /usr/lib/perl5/vendor_perl/5.8.3
    /usr/lib/perl5/vendor_perl
    /usr/lib/perl5/5.8.6/i386-linux-thread-multi
    /usr/lib/perl5/5.8.6
    .


Environment for perl v5.8.6:
    HOME=/home/chris
    LANG=en_NZ.UTF-8
    LANGUAGE (unset)
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/usr/kerberos/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/home/chris/bin:/sbin:/usr/sbin:/usr/local/sbin
    PERL_BADLANG (unset)
    SHELL=/bin/bash

@p5pRT
Copy link
Author

p5pRT commented Sep 7, 2005

From @salva

this is the same bug as #24254

@p5pRT
Copy link
Author

p5pRT commented Sep 7, 2005

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

@p5pRT
Copy link
Author

p5pRT commented Sep 7, 2005

From @nwc10

On Tue, Sep 06, 2005 at 07​:01​:06PM -0700, Chris Heath wrote​:

Throwing an exception inside a grep sometimes causes Perl
to emit an internal warning.

$ perl -e 'for ("foo") { grep(die, "bar") }'
Died at -e line 1.
Attempt to free unreferenced scalar​: SV 0x96c61dc, Perl interpreter​: 0x96ae008.

The unreferenced scalar seems to be "bar" as this will still generate an error

$ perl -e 'grep {die} "bar" for undef'
Died at -e line 1.
Attempt to free unreferenced scalar​: SV 0x800dd0.

(undef has special reference counting semantics)

Replacing grep with map produces the same error.

Does this warning indicate possible internal corruption? I have seen
some Perl corruption in a production system at my work recently, as well
as this warning, so I wondered if they could be related.

Well, it's a double "free", in as much as one part of the interpreter has a
pointer to a block of memory that will be recycled as a new scalar at some
point. I'm not sure quite what route, or what manipulation of $@​ could create
actual corruption though.

Nicholas Clark

@p5pRT
Copy link
Author

p5pRT commented Sep 7, 2005

From @salva

Nicholas Clark wrote​:

On Tue, Sep 06, 2005 at 07​:01​:06PM -0700, Chris Heath wrote​:

Throwing an exception inside a grep sometimes causes Perl
to emit an internal warning.

$ perl -e 'for ("foo") { grep(die, "bar") }'
Died at -e line 1.
Attempt to free unreferenced scalar​: SV 0x96c61dc, Perl interpreter​: 0x96ae008.

The unreferenced scalar seems to be "bar" as this will still generate an error

$ perl -e 'grep {die} "bar" for undef'
Died at -e line 1.
Attempt to free unreferenced scalar​: SV 0x800dd0.

(undef has special reference counting semantics)

Replacing grep with map produces the same error.

Does this warning indicate possible internal corruption? I have seen
some Perl corruption in a production system at my work recently, as well
as this warning, so I wondered if they could be related.

Well, it's a double "free", in as much as one part of the interpreter has a
pointer to a block of memory that will be recycled as a new scalar at some
point. I'm not sure quite what route, or what manipulation of $@​ could create
actual corruption though.

This bug is a dup of #24254, sometime ago I was able to trace it
and to found its cause, not to solve it :-(

Attached to that bug report is a description of what is going on.

Cheers,

  - Salvador.

@p5pRT
Copy link
Author

p5pRT commented Nov 8, 2005

From chris@heathens.co.nz

Ticket 24254 marked as resolved.

@p5pRT
Copy link
Author

p5pRT commented Nov 8, 2005

chris@heathens.co.nz - Status changed from 'open' to 'resolved'

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant