crash in Perl_hv_common / S_share_hek_flags #14123
Comments
From @marcin-gryszkalisCreated by @marcin-gryszkalisThis is a bug report for perl from mg@fork.pl, ----------------------------------------------------------------- Stacktrace looks like this: #0 0x00000008008de137 in S_share_hek_flags (my_perl=0x801c19e00, str=0x815d59660 "COUNT", len=5, hash=1160607206, flags=1024) at hv.c:2872 #0 0x00000008008de137 in S_share_hek_flags (my_perl=0x801c19e00, str=0x816727f30 "cdr", len=3, hash=2934883949, flags=258) at hv.c:2872 entry seems to be broken (gdb) p *entry but I don't know much about hash entry internals... Perl Info |
From @cpansproutOn Mon Sep 29 17:18:16 2014, mg@fork.pl wrote:
That’s not much to go by. Could you at least show us the line of Perl code on which it’s crashing, or maybe even the containing function? This should give you the file and line number: (gdb) p Perl_warn(my_perl, "") Also, it may help you to reduce the test case if you get a Perl backtrace: (gdb) p Perl_eval_pv(my_perl,"use Carp; Carp::cluck 'foo'",0) -- Father Chrysostomos |
|
The RT System itself - Status changed from 'new' to 'open' |
From @demerphqFC just posted the following advice. I think these kind of tricks should be From FC: This should give you the file and line number: (gdb) p Perl_warn(my_perl, "") Also, it may help you to reduce the test case if you get a Perl backtrace: (gdb) p Perl_eval_pv(my_perl,"use Carp; Carp::cluck 'foo'",0) -- |
From PeterCMartini@GMail.com
+1 Those two are useful if you have a reproducible crash; I have a couple written down somewhere to inspect those kinds of variables from core dumps, which I'll happily share when I find them :-)
|
From @iabynOn Tue, Sep 30, 2014 at 05:12:54PM -0700, Father Chrysostomos via RT wrote:
Perl shares hash keys between different hashes: this is to make objects, The code is crashing while trying to add a new key ("COUNT") to the shared Thus, its likely that an unrelated piece of code has earlier corrupted It may also be that the crash is intermittent based on hash randomisation. $ PERL_HASH_SEED_DEBUG=1 perl -le'print "hello"' It's then possible to run re-perl using the same seed: $ PERL_HASH_SEED=0xf71b975f74369627 perl .... -- |
From perl5-porters@perl.orgPeter Martini wrote:
Such tricks are quite dependent on Perl internals and build options. (If you are volunteering to maintain it, I'd say go ahead.) |
From @marcin-gryszkalisI looks like reply-to-RT-by-email doesn't work or get some hiccups - so I'm pasting here answer I already sent - sorry if it finally gets duplicated. On 2014-10-01 02:12, Father Chrysostomos via RT wrote:
Sure, but I don't have live gdb session - only coredump, ie. (gdb) p Perl_warn(my_perl, "") As I mentioned It's web application with many perl processes serving Other problem is that the crashes happen randomly (eg. I didn't have On 2014-10-01 14:04, Dave Mitchell via RT wrote:
I checked older cores and they seem to confirm what you wrote. perl #0 0x00000008008de137 in S_share_hek_flags (my_perl=0x801c19e00, #0 0x00000008008de137 in S_share_hek_flags (my_perl=0x801c19e00,
PERTURB_KEYS = 1 (RANDOM)
I guess I could do this but not sure what could be achieved with this... -- |
From @cpansproutOn Wed Oct 01 13:03:31 2014, mg@fork.pl wrote:
I’ve never debugged a core file before. Can you access the entire process’s memory from the moment it crashed? In that case you can get a Perl line number with: (gdb) p *my_perl->Icurcop And look at cop_line and cop_file.
If you could run a copy of the script repeatedly outside the context of a web server and capture the hash seed when it crashes, that might help. That said, it should be possible to get the hash seed from a core file, but I don’t know how offhand. -- Father Chrysostomos |
From @cpansproutOn Wed Oct 01 21:53:28 2014, sprout wrote:
I’ve just had a look: (gdb) p PL_hash_seed Getting that into a hexadecimal string is a little more complicated.... If you can capture the output and feed it to unpack("H*",$output), you can then use the hexadecimal string like this: $ PERL_HASH_SEED=42baff1edc0ffee5 your_script.pl and try to reproduce the crash. -- Father Chrysostomos |
From @tonycozOn Mon Sep 29 17:18:16 2014, mg@fork.pl wrote:
This may be same bug as in https://rt-archive.perl.org/perl5/Ticket/Display.html?id=122873 Could you try reinstalling Encode with the patch I've attached here? (This is the same patch I included in https://rt.cpan.org/Ticket/Display.html?id=99264 ) Tony |
From @tonycoz0001-SPAGAIN-after-call_pv-which-can-reallocate-the-perl-.patchFrom 5f0737ab20b7bd46cddaccdfff5a6f78b73f19e1 Mon Sep 17 00:00:00 2001
From: Tony Cook <tony@develop-help.com>
Date: Thu, 2 Oct 2014 11:05:03 +1000
Subject: [PATCH] SPAGAIN after call_pv(), which can reallocate the perl stack
---
Encode.xs | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Encode.xs b/Encode.xs
index 5ee4539..5e20c3d 100644
--- a/Encode.xs
+++ b/Encode.xs
@@ -686,6 +686,7 @@ CODE:
/* require_pv(PERLIO_FILENAME); */
eval_pv("require PerlIO::encoding", 0);
+ SPAGAIN;
if (SvTRUE(get_sv("@", 0))) {
ST(0) = &PL_sv_no;
@@ -703,6 +704,7 @@ CODE:
encode_t *enc = INT2PTR(encode_t *, SvIV(SvRV(obj)));
SV *retval;
eval_pv("require Encode::MIME::Name", 0);
+ SPAGAIN;
if (SvTRUE(get_sv("@", 0))) {
ST(0) = &PL_sv_undef;
--
1.7.10.4
|
From @timbunceOn Wed, Oct 01, 2014 at 07:44:59PM -0000, Father Chrysostomos wrote:
Even when out of date, those kinds of docs are still helpful.
And I'd be grateful. Tim. |
From @demerphqOn 2 October 2014 11:44, Tim Bunce <Tim.Bunce@pobox.com> wrote:
Ok, Then I will try to find time to do this. Yves -- |
From @timbunceOn Wed, Oct 01, 2014 at 07:43:30AM -0400, Peter Martini wrote:
This reminded me of https://metacpan.org/source/GOZER/mod_perl-1.31/.gdbinit I'm sure that's out of date but it shows a nice way to package the tips Then I wondered if any other distros contained .gdbinit files, and curl -XPOST 'api.metacpan.org/v0/file' -d '{"query":{"match_all":{}},"filter":{"and":[{"term":{"path":".gdbinit"}},{"term":{"status":"latest"}}]},"fields":["release"],"size":200}' | grep release "release" : "Devel-SizeMe-0.19" The Devel-SizeMe and Devel-NYTProf files are mostly random cargo-cult stuff. Tim. |
From @marcin-gryszkalisOn 2014-10-01 02:12, Father Chrysostomos via RT wrote:
Sure, but I don't have live gdb session - only coredump, ie. (gdb) p Perl_warn(my_perl, "") As I mentioned It's web application with many perl processes serving Other problem is that the crashes happen randomly (eg. I didn't have -- |
From @marcin-gryszkalisOn 2014-10-01 14:04, Dave Mitchell via RT wrote:
I checked older cores and they seem to confirm what you wrote. perl #0 0x00000008008de137 in S_share_hek_flags (my_perl=0x801c19e00, #0 0x00000008008de137 in S_share_hek_flags (my_perl=0x801c19e00,
PERTURB_KEYS = 1 (RANDOM)
I guess I could do this but not sure what could be achieved with this... -- |
From @marcin-gryszkalisOn Wed Oct 01 22:07:39 2014, tonyc wrote:
I did, no crashes for last few hours but we'll have to wait a bit longer... |
From @marcin-gryszkalisOn Wed Oct 01 21:53:28 2014, sprout wrote:
I did for few coredumps I have and it's pretty random: $1 = 0x80cc50680 "/usr/local/lib/perl5/site_perl/5.20/MIME/Types.pm" $1 = 0x8177c9c30 "(eval 11979)" $1 = 0x80cc4a700 "/usr/local/lib/perl5/site_perl/5.20/MIME/Types.pm" $1 = 0x80689fd80 "/usr/local/lib/perl5/site_perl/5.20/mach/Data/Dumper.pm" $1 = 0x815d5bd40 "/usr/local/lib/perl5/site_perl/5.20/mach/Template/Iterator.pm" $1 = 0x8047caf40 "/usr/local/lib/perl5/site_perl/5.20/CGI/Simple/Util.pm" $1 = 0x816de1310 "(eval 12310)" $1 = 0x809cdc2c0 "/usr/local/lib/perl5/site_perl/5.20/mach/Encode.pm" |
From @marcin-gryszkalisOn Wed Oct 01 22:07:39 2014, tonyc wrote:
Hi, I tried your patch on 5.20 (still segv) and then I downgraded to 5.18.4 and tested with and without the patch - in both cases I get segv :( I guess I didn't mention that application worked without problems on 5.14 |
From @marcin-gryszkalisAfter upgrading to FreeBSD 10.1 with new clang compiler Note that other confirmed similar problems |
|
As mentioned in #13962 (RT#122199) bug was specific to freebsd 10.0 (and clang included) - now it's long gone. |
Migrated from rt.perl.org#122868 (status was 'open')
Searchable as RT122868$
The text was updated successfully, but these errors were encountered: