Front page | perl.perl5.porters |
Postings from May 2012
[perl #7906] core is dumped in the depths of perl_destruct() in Perl 5.6.1
Thread Previous
|
Thread Next
From:
Brian Fraser via RT
Date:
May 25, 2012 14:25
Subject:
[perl #7906] core is dumped in the depths of perl_destruct() in Perl 5.6.1
Message ID:
rt-3.6.HEAD-7788-1337981101-371.7906-15-0@perl.org
On Tue Nov 13 06:39:48 2001, ccarey@vicinity.com wrote:
>
> -----------------------------------------------------------------
>
>
> Hello there,
>
> I've encountered what seems to be a bug in an embedded Perl 5.6.1
> within a C program. There are three different core dump causes;
> two of them happen while trying to finish perl_destruct(), and
> the third seems to be due just to memory corruption. The
> precondition is that an embedded Perl subroutine die()s a certain
> number of times [which seems to vary by OS, Perl version, and
> whether multiplicity is compiled in], and each die() is caught
> because the G_EVAL flag had been given to perl_call_pv(). What's
> curious is that the G_ARRAY flag is also a necessary precondition
> for core to dump; core doesn't dump if the G_SCALAR flag is used
> instead of G_ARRAY.
>
> I have a test program called "death" that demonstrates
> the problem. It takes three arguments: -n number, where number
> is how many times the call to the embedded Perl subroutine should
> be executed; -a, where G_ARRAY is given to perl_call_pv() rather
> than G_SCALAR; and -s, where certain signals are caught rather
> than letting core dump.
>
> On Solaris 7, with Perl 5.6.1 compiled with multiplicity,
> "death -a -n 10 -s" reveals the following:
>
> Divide: dividend is zero at /home/ccarey/Perl-5.6.1/Death.pm line 27.
> ...
> signal_number: 10
> si->si_signo: 10
> si->si_errno: 0
> si->si_code: BUS_ADRALN
> si->si_addr: 3d27675b
>
> namely, that SIGBUS is the cause of the core dump. In this case,
> the si->si_addr value looks like an ASCII string in hexadecimal
> format rather than a valid address.
>
> Similarly, "death -a -n 147 -s" on the same machine shows
> a second cause:
>
> Divide: dividend is zero at /home/ccarey/Perl-5.6.1/Death.pm line 27.
> ...
> signal_number: 11
> si->si_signo: 11
> si->si_errno: 0
> si->si_code: SEGV_MAPERR
> si->si_addr: 8d3f48
>
> that in this case, SIGSEGV causes core to dump. Additionally,
> "death -a -n 574 -s" on the same machine shows another case:
>
> Divide: dividend is zero at /home/ccarey/Perl-5.6.1/Death.pm line 27.
> ...
> Can't use an undefined value as an ARRAY reference at
> /home/ccarey/Perl-5.6.1/Death.pm line 26.
> Can't use string ("0") as an ARRAY ref while "strict refs" in use at
> /home/ccarey/Perl-5.6.1/Death.pm line 26.
> Can't use string ("$$") as an ARRAY ref while "strict refs" in use at
> /home/ccarey/Perl-5.6.1/Death.pm line 26.
> Can't use string ("$$") as an ARRAY ref while "strict refs" in use at
> /home/ccarey/Perl-5.6.1/Death.pm line 26.
> signal_number: 4
> si->si_signo: 4
> si->si_errno: 0
> si->si_code: ILL_ILLOPC
> si->si_addr: 1cfc10
>
> This SIGILL condition is the most intriguing, since the four
> warnings that begin with "Can't" don't appear in the other cases;
> presumably this is due to memory corruption of some sort.
>
> When run without the "-s" argument, each of "-n 10", "-n 147",
> and "-n 574" dump core. The SIGBUS core dump reveals the following
> in gdb:
>
> (amber:281) gdb death core.multiplicity.010
> GNU gdb 4.18
> ...
> Reading symbols from
> /usr/lib/locale/iso_8859_1/iso_8859_1.so.2...done.
> #0 0xff1c6424 in _free_unlocked () from /usr/lib/libc.so.1
> (gdb) where
> #0 0xff1c6424 in _free_unlocked () from /usr/lib/libc.so.1
> #1 0xff1c63dc in free () from /usr/lib/libc.so.1
> #2 0x9e198 in Perl_safesysfree (where=0x72633d31) at util.c:158
> #3 0xa8db0 in Perl_mg_free (my_perl=0x195be8, sv=0x1ad86c) at
> mg.c:316
> #4 0xda42c in Perl_sv_clear (my_perl=0x195be8, sv=0x1ad86c) at
> sv.c:3770
> #5 0xdad88 in Perl_sv_free (my_perl=0x195be8, sv=0x1ad86c) at
> sv.c:3950
> #6 0xb8560 in Perl_av_undef (my_perl=0x195be8, av=0x1a0ad8) at
> av.c:447
> #7 0xda5d4 in Perl_sv_clear (my_perl=0x195be8, sv=0x1a0ad8) at
> sv.c:3798
> #8 0xdad88 in Perl_sv_free (my_perl=0x195be8, sv=0x1a0ad8) at
> sv.c:3950
> #9 0x75e00 in Perl_cv_undef (my_perl=0x195be8, cv=0x1a0acc) at
> op.c:4157
> #10 0xda5a4 in Perl_sv_clear (my_perl=0x195be8, sv=0x1a0acc) at
> sv.c:3792
> #11 0xdad88 in Perl_sv_free (my_perl=0x195be8, sv=0x1a0acc) at
> sv.c:3950
> #12 0x75cbc in Perl_cv_undef (my_perl=0x195be8, cv=0x1c8d8c) at
> op.c:4140
> #13 0xda5a4 in Perl_sv_clear (my_perl=0x195be8, sv=0x1c8d8c) at
> sv.c:3792
> #14 0xdad88 in Perl_sv_free (my_perl=0x195be8, sv=0x1c8d8c) at
> sv.c:3950
> #15 0x33884 in Perl_gp_free (my_perl=0x195be8, gv=0x1a63ac) at
> gv.c:1111
> #16 0xda60c in Perl_sv_clear (my_perl=0x195be8, sv=0x1a63ac) at
> sv.c:3804
> #17 0xdad88 in Perl_sv_free (my_perl=0x195be8, sv=0x1a63ac) at
> sv.c:3950
> #18 0xe4ef8 in do_clean_all (my_perl=0x195be8, sv=0x1a63ac) at
> sv.c:8411
> #19 0xcc5b4 in S_visit (my_perl=0x195be8, f=0xe4e8c <do_clean_all>)
> at sv.c:162
> #20 0xcc698 in Perl_sv_clean_all (my_perl=0x195be8) at sv.c:193
> #21 0x24e40 in perl_destruct (my_perl=0x195be8) at perl.c:665
> #22 0x23b98 in destroy_Perl_interpreter (perl_interpreter=0x195be8)
> at death.c:151
> #23 0x22f10 in postmain (argc=4, argv=0xffbef72c, wanting_array=1,
> iterations=-1) at main.c:288
> #24 0x23244 in main (argc=4, argv=0xffbef72c) at main.c:383
> (gdb) frame 3
> #3 0xa8db0 in Perl_mg_free (my_perl=0x195be8, sv=0x1ad86c) at
> mg.c:316
> 316 Safefree(mg->mg_ptr);
> (gdb) print mg
> $1 = (MAGIC *) 0x1c1a54
> (gdb) print *mg
> $2 = {mg_moremagic = 0x1c1a48, mg_virtual = 0x0, mg_private = 0,
> mg_type = 0 '\000', mg_flags = 255 '�', mg_obj = 0xa01, mg_ptr =
> 0x72633d31 <Address 0x72633d31 out of bounds>, mg_len = 32}
> (gdb) _
>
> whereas the SIGSEGV core dump unveils the following:
>
> (amber:282) gdb death core.multiplicity.147
> GNU gdb 4.18
> ...
> Reading symbols from
> /usr/lib/locale/iso_8859_1/iso_8859_1.so.2...done.
> #0 0xb77d0 in Perl_av_fetch (my_perl=0x195be8, av=0x1968c4,
> key=1899656, lval=0) at av.c:202
> 202 if (AvARRAY(av)[key] == &PL_sv_undef) {
> (gdb) where
> #0 0xb77d0 in Perl_av_fetch (my_perl=0x195be8, av=0x1968c4,
> key=1899656, lval=0) at av.c:202
> #1 0x75d5c in Perl_cv_undef (my_perl=0x195be8, cv=0x1968a0) at
> op.c:4147
> #2 0xda5a4 in Perl_sv_clear (my_perl=0x195be8, sv=0x1968a0) at
> sv.c:3792
> #3 0xdad88 in Perl_sv_free (my_perl=0x195be8, sv=0x1968a0) at
> sv.c:3950
> #4 0x24394 in perl_destruct (my_perl=0x195be8) at perl.c:407
> #5 0x23b98 in destroy_Perl_interpreter (perl_interpreter=0x195be8)
> at death.c:151
> #6 0x22f10 in postmain (argc=4, argv=0xffbef72c, wanting_array=1,
> iterations=-1) at main.c:288
> #7 0x23244 in main (argc=4, argv=0xffbef72c) at main.c:383
> (gdb) print av->sv_any->xav_array
> $1 = 0x194e18 ""
> (gdb) print key
> $2 = 1899656
> (gdb) _
>
> and the SIGILL core dump shows this:
>
> (amber:283) gdb death core.multiplicity.574
> GNU gdb 4.18
> ...
> Reading symbols from
> /usr/lib/locale/iso_8859_1/iso_8859_1.so.2...done.
> #0 0x1cfc4c in ?? ()
> (gdb) where
> #0 0x1cfc4c in ?? ()
> #1 0x28c98 in S_call_body (my_perl=0x195be8, myop=0xffbef338,
> is_eval=0) at perl.c:1824
> #2 0x28744 in Perl_call_sv (my_perl=0x195be8, sv=0x1cfc04, flags=5)
> at perl.c:1742
> #3 0x27e30 in Perl_call_pv (my_perl=0x195be8, sub_name=0x16abc0
> "Divide", flags=5) at perl.c:1619
> #4 0x2368c in Death_Divide (error_message=0xffbef500 "",
> perl_interpreter=0x195be8, wanting_array=1, divisor=1, dividend=0)
> at death.c:101
> #5 0x22e6c in postmain (argc=4, argv=0xffbef72c, wanting_array=1,
> iterations=0) at main.c:273
> #6 0x23244 in main (argc=4, argv=0xffbef72c) at main.c:383
> (gdb) frame 1
> #1 0x28c98 in S_call_body (my_perl=0x195be8, myop=0xffbef338,
> is_eval=0) at perl.c:1824
> 1824 CALLRUNOPS(aTHX);
> (gdb) _
>
> I have no experience with the perlguts, so I'm not in a position
> to easily suss out the reasons behind these core dumps. Kindly
> send a note to me at <ccarey@capaccess.org> if you'd like a copy
> of the "death" program; it's reasonably compact, fairly portable,
> and it currently compiles on Solaris 7 and Linux 2.0.36 [although
> siginfo(5) information won't be provided if it's not available
> in the OS]. As an aside, only SIGSEGV occurs on Linux 2.0.36
> with a debugging Perl 5.6.1 with multiplicity, and the SIGSEGV
> requires "-n 3" or higher.
>
> Thanks for your attention,
>
> Christian Carey <ccarey@vicinity.com>
>
>
This report fell through the cracks; OP, if you're still around, are you
still having this issue with recent versions of Perl? If so, could you
send a way to reproduce it?
Seeing how this ticket has been silent for over a decade, I recommend
waiting another thirty days, then closing it if we don't get new
information or other complains.
--hugmeir
---
via perlbug: queue: perl5 status: open
https://rt.perl.org:443/rt3/Ticket/Display.html?id=7906
Thread Previous
|
Thread Next