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
segmentation fault in mg.c on Fedora 16-x64 #11845
Comments
From erik@thekrib.comCreated by erik@thekrib.comRunning the sympa mailing list software via its fastcgi module wwsympa.fcgi, when I perform various functions like subscribe/unsubscribe that cause an e-mail to be generated, Another person has reported this under openSUSE, same version of perl. It formerly worked in perl 5.12. E-mail thread: https://listes.cru.fr/sympa/arc/sympa-users/2012-01/msg00005.html I am using Fedora 16, stock distribution perl, modules installed via CPAN. Enabled crash dumps, shows that in all of the different cases, it's crashing on the same line, mg.c#232 I can send full crash dumps if needed, as well as result of -d:Trace. Here is snippet of relevant bt: [Thread debugging using libthread_db enabled] (gdb) print mg Alignment bug? Stepping on freed memory? Thanks for any help! I can provide any support. This is 100% reproducible for me. - Erik Perl Info
|
From @cpansproutOn Tue Jan 03 11:43:51 2012, erik@thekrib.com wrote:
I don’t really know where to begin. But you could try call Perl_warn(my_perl, "here") in gdb to see which piece of Perl code it’s crashing on. Is there any chance you could do a binary search to find out which -- Father Chrysostomos |
The RT System itself - Status changed from 'new' to 'open' |
From erik@thekrib.comOn Tue, 3 Jan 2012, Father Chrysostomos via RT wrote:
Thank you for responding so quickly! Because this is run out out of a cgi script, I'm relying on core dumps as But I did some more digging in one of the core dumps. This caught my eye... (gdb) frame 0 **** These look to be bogus values for mg structure -- in particular, mg_virtual, which is unlike all other pointers I've seen. (gdb) print sv sv_flags in hex is = 40044407 -- includes svpad_name and svpad_our flags. (gdb) print sv->sv_any sv->sv_any looks good. So based on xmg_u being a union, I tried to look at xmg_u as xmg_ourstash (gdb) print *((HV *)0x1d52bd8) The code in Perl_mg_get() is walking that link to xmg_magic without checking the flags first? - Erik -- |
From @cpansproutOn Wed Jan 04 08:10:13 2012, erik@thekrib.com wrote:
That entire magic structure is garbage. There is no magic type '\326'.
SVt_PVMG, SVf_POK, SVp_POK, SVpad_OUR, SVpad_NAME And the call is coming from S_pad_findlex. Was pad.c:1035 the line But S_pad_find_lex is trying to create a new SV from an existing one case SVt_PVMG:
I’ve just learn something new. sv.h has this: union _xmgu {
mg_get seems to be designed that way. But the calling code checks 0x00200000 # SVs_GMG Maybe this is a compiler bug. I really can’t tell. Are you in a position to recompile perl? You could try SvGMAGICAL(sstr) Or what happens if you reinstall perl unmodified? (When it comes to this compilation stuff, I’m just waving my hands Also: Is it possible for you to run the CGI script yourself from the -- Father Chrysostomos |
From erik@thekrib.comUpdate of information on this bug. I have spent the last two evenings trying to make progress. It is very I was able to repro the problems on a virtual machine with an all-new On Wed, 4 Jan 2012, Father Chrysostomos via RT wrote:
Yes, line 1035 definitely.
Yes, I have broken through the barrier of DBD::mysql not building (patched I built it with -DDEBUGGING turned on, and very interestingly, it asserts perl: mg.c:227: Perl_mg_get: Assertion `!(((_svmagic)->sv_flags & (0x40000000|0x00040000)) == (0x40000000|0x00040000))' failed. I beleive this corresponds to the second assert in this macro: # define SvMAGIC(sv) \ Is this opposite case of the one that page-faults the machine? Unfortunately, because of that assert, I cannot attempt to run the command I ran this with perl tracing on, and here are the last few lines before [Thu Jan 05 20:31:05 2012] [warn] [client ::1] mod_fcgid: stderr: >> /opt/perl/lib/5.14.2/Exporter.pm:45: my $args = @_ or @_ = @$exports; Full Devel::trace at http://test.thekrib.com/trace-107480-debug.txt.gz
Tried these, to no avail. It still gets through. I don't think this is a save_magic(mgs_ix, sv); the flag value is reset along with who-knows-what.
Not possible, due to its interaction, but I can use gdb to attach to the I am at a disadvantage here because I'm not that familiar with even the Thanks for any insight. - Erik -- |
From @cpansproutOn Sat Jan 07 04:20:22 2012, erik@thekrib.com wrote:
It sounds like exactly the same problem to me.
Due to local firewall settings, I cannot access that URL. Could you
I’m in the opposite position. I’m a Perl and JavaScript programmer who -- Father Chrysostomos |
From @iabynOn Fri, Jan 06, 2012 at 10:33:48PM -0800, Erik Olson wrote:
Yes, this is normal behaviour. I think the problem is that an SV in the The diff below to 5.14.2 adds an assertion that should catch that Inline Patch--- sv.h.orig 2012-01-08 23:43:14.352614694 +0000
+++ sv.h 2012-01-08 23:52:00.791663213 +0000
@@ -1214,6 +1214,8 @@
((sv)->sv_u.svu_rv = (val)); } STMT_END
#define SvMAGIC_set(sv, val) \
STMT_START { assert(SvTYPE(sv) >= SVt_PVMG); \
+ assert(!(SvFLAGS(sv) & SVpad_NAME) || \
+ (SvTYPE(sv) != SVt_PVNV && SvTYPE(sv) != SVt_PVMG)); \
(((XPVMG*)SvANY(sv))->xmg_u.xmg_magic = (val)); } STMT_END
#define SvSTASH_set(sv, val) \
STMT_START { assert(SvTYPE(sv) >= SVt_PVMG); \
-- "I do not resent criticism, even when, for the sake of emphasis, |
From @cpansproutOn Sun Jan 08 14:14:19 2012, sprout wrote:
Can you also provide a full gdb backtrace from that assertion? And also, back to my earlier question: Since the problem begins (i.e.,
I’ve had a look at it, but I really don’t know what to look for. I wish
-- Father Chrysostomos |
From erik@thekrib.comgzipped perl trace rejected by mailing list, will send separately if you ---------- Forwarded message ---------- On Mon, 9 Jan 2012, Dave Mitchell wrote:
Yes, I was able to get it to assert on this as I fired up the cgi script for SvMAGIC_set(sv, moremagic); Like the previous assert alluded to on mg.c:227, this happens before I even run Full bt of core dump enclosed. I can keep running tests like this, as much as it takes. I have worked around the problem locally by recompiling perl 5.12.x, so time - Erik -- |
From erik@thekrib.com#0 0x00000032ec036285 in __GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 |
From erik@thekrib.comOn Mon, 9 Jan 2012, Father Chrysostomos via RT wrote:
Sent a backtrace from the new assertion. Let's see if that helps.
Nope, when I run it straight from the commandline, it exits out "normally" -- |
From @iabynOn Mon, Jan 09, 2012 at 10:09:04PM -0800, Erik Olson wrote:
The assertion failing there indicates that the assertion code I gave you Inline Patch--- sv.h.orig 2012-01-08 23:43:14.352614694 +0000
+++ sv.h 2012-01-11 17:41:01.957571210 +0000
@@ -1214,6 +1214,8 @@
((sv)->sv_u.svu_rv = (val)); } STMT_END
#define SvMAGIC_set(sv, val) \
STMT_START { assert(SvTYPE(sv) >= SVt_PVMG); \
+ assert(!SvPAD_OUR(sv) || \
+ (SvTYPE(sv) != SVt_PVNV && SvTYPE(sv) != SVt_PVMG)); \
(((XPVMG*)SvANY(sv))->xmg_u.xmg_magic = (val)); } STMT_END
#define SvSTASH_set(sv, val) \
STMT_START { assert(SvTYPE(sv) >= SVt_PVMG); \
-- No matter how many dust sheets you use, you will get paint on the carpet. |
From @cpansproutOn Wed Jan 11 10:02:29 2012, davem wrote:
If the script won’t run without a CGI environment, it might be $ REQUEST_METHOD=GET perl5.14.2 -t wwsympa.fcgi
-- Father Chrysostomos |
From erik@thekrib.comOn Wed, 11 Jan 2012, Dave Mitchell wrote:
Indeed, this DOES now allow me to run it on the commandline -- thanks!
Unfortunately, with this new assert added, I'm back to the "original" Anything I can dig up here? Oh, full backtrace: (gdb) bt (gdb) bt full -- |
From @iabynOn Wed, Jan 11, 2012 at 04:18:57PM -0800, Erik Olson wrote:
Oh :-(
In that case, would it be possible to provide a stripped down test script -- |
From @cpansproutOn Fri Jan 13 04:05:38 2012, davem wrote:
But he doesn’t know Perl. :-( I have not been able to reproduce this problem myself. -- Father Chrysostomos |
From erik@thekrib.comOn Fri, 13 Jan 2012, Father Chrysostomos via RT wrote:
But I do know how to hack. So I will see if using the 10,000-line source - Erik -- |
From bouyer@NetBSD.orgHello, Here is what gdb tells me from the core dump: |
From [Unknown Contact. See original ticket]Hello, Here is what gdb tells me from the core dump: |
From @cpansproutOn Fri Feb 10 07:04:57 2012, bouyer wrote:
Are you able to reproduce it from the command line? If so, would you be -- Father Chrysostomos |
From erik@thekrib.comDifferent person -- bouyer is not me. "Real" work has swamped me, so I can't yet devote a chunk of time to On Mon, 13 Feb 2012, Father Chrysostomos via RT wrote:
-- |
Migrated from rt.perl.org#107480 (status was 'open')
Searchable as RT107480$
The text was updated successfully, but these errors were encountered: