Re: Regular rarely segmentation fault in libperl.so #11841
Comments
From perlover@perlover.comSorry, previous letter had a bad formatted lines This is a bug report for perl from perlover@perlover.com, Hello, developers of perl! I regulary every day get a core files and segmentation fault in libperl.so Here some backtraces of perl without debug info (i cannot add debug 1st 'bt' from gdb: Program terminated with signal 11, Segmentation fault. Second core file: Program terminated with signal 11, Segmentation fault. 3rd core file: Program terminated with signal 11, Segmentation fault. 4th core file: Program terminated with signal 11, Segmentation fault. And so on... I don't know fixed this bug or no but i didn't find in Google some Best regards, Flags: This perlbug was built using Perl 5.10.1 in the Fedora build system. Site configuration information for perl 5.10.1: Configured by Red Hat, Inc. at Wed Dec 28 17:51:47 YEKT 2011. Summary of my perl5 (revision 5 version 10 subversion 1) configuration: Platform: Locally applied patches: @INC for perl 5.10.1: Environment for perl 5.10.1: |
From @cpansproutOn Mon Jan 02 03:25:46 2012, Perlover wrote:
Are you using any XS modules that create their own ops or fiddle with Do you know what Perl code is being compiled? Typing call Perl_warn(my_perl, "here") in the debugger (omit my_perl for non-threaded builds) should result in here at lib/Foo/Bar.pm line 3123. Maybe you could send some code snippets surrounding the offending lines. I see you are using 5.10.1. There have been a ton of bug fixes since
-- Father Chrysostomos |
|
The RT System itself - Status changed from 'new' to 'open' |
From perlover@perlover.comI think this but may be related with bug # 72406 ( |
From @iabynOn Mon, Jan 02, 2012 at 03:25:47AM -0800, Perlover wrote:
[snip] All the segfaults occur where the code is doing the first dereference of a So I reckon that the most likely thing is that your perl process is -- |
From mark@exonetric.comOn 4 Jan 2012, at 13:08, Dave Mitchell wrote:
Now, this is an interesting report for us as we have recently implemented I was a little surprised that such an easy to check condition was resulting - Mark |
From perlover@perlover.comGood day!
Yes, it may be core file size (blocks, -c) 0 Here "max memory size" is unlimited
ulimits i dumped above Best regards, Perlover |
From @iabynOn Wed, Jan 04, 2012 at 02:59:46PM +0100, Perlover wrote:
Yeah, it shouldn't be affected by stack size (that would just trigger a Could you apply this crude patch to your 5.10.1 perl? It checks for Inline Patch--- op.h- 2012-01-08 15:54:03.944453254 +0000
+++ op.h 2012-01-08 16:33:07.592199391 +0000
@@ -640,9 +640,14 @@
(var = (OP *) Perl_Slab_Alloc(aTHX_ size))
#define FreeOp(p) Perl_Slab_Free(aTHX_ p)
#else
-#define NewOp(m, var, c, type) \
+#define NewOp(m, var, c, type) STMT_START { \
(var = (MEM_WRAP_CHECK_(c,type) \
- (type*)PerlMemShared_calloc(c, sizeof(type))))
+ (type*)PerlMemShared_calloc(c, sizeof(type)))); \
+ if (!var) { \
+ write(2, STR_WITH_LEN("Zero malloc in NewOp\n")); \
+ abort(); \
+ } \
+ } STMT_END;
#define NewOpSz(m, var, size) \
(var = (OP*)PerlMemShared_calloc(1, size))
#define FreeOp(p) PerlMemShared_free(p)
-- A walk of a thousand miles begins with a single step... |
From @iabynOn Tue, Jan 17, 2012 at 11:14:26AM +0100, Perlover wrote:
Yeah, I think it's definitely a lack of memory problem at your end, so -- |
From perlover@perlover.comGood day, Dave and everybody in perl bug list! I have two core files after your patches Here backtrace from gdb: #0 0x00007f07e7db28f5 in raise () from /lib64/libc.so.6 And second corefile: I think it is good that happened because it signals to us that your What do you think? Perlover 2012/1/9 Perlover <perlover@perlover.com>:
|
From @jkeenanOn Tue Jan 17 03:48:20 2012, davem wrote:
Dave, do you have any suggestions as to how we could fix this failure to Thank you very much. |
From @iabynOn Sun, Feb 03, 2013 at 10:48:41AM -0800, James E Keenan via RT wrote:
Not without looking at the code (and I'd look at the code if/when I was in -- |
Migrated from rt.perl.org#107392 (status was 'open')
Searchable as RT107392$
The text was updated successfully, but these errors were encountered: