bin/perl -w
use encoding 'utf8';
my $x = /¨\.\//;
As perl aborts, I usually see the message:
"*** glibc detected *** corrupted double-linked list: 0x08134618 ***"
gdb on the core dump reports:
#0 0xe410 in ?? ()
#1 0xbfffeafc in ?? ()
#2 0x0006 in ?? ()
#3
> [jhi - Wed Dec 08 09:02:56 2004]:
>
> >>
> >>As in the following ticket,
> >>http://rt.perl.org/rt3/Ticket/Display.html?id=7460, this core dump seems
> >>to have been fixed prior to 5.8.0. I also built a 5.8.6, and this test
> >>passed withou
1.33 running under perl v5.6.1.
> >
> >
> > -
> > [Please enter your report here]
> >
> > While teaching a Perl course at HP, one of the students pointed out
> > running a solution of one of the exercises gives a core dump.
> >
> > I narrowed it down t
On Tue, 19 Jul 2005, Jarkko Hietaniemi wrote:
> The attached patch introduces %POSIX::SIGRT which gives access
> to the POSIX real time signals SIGRTMIN...SIGRTMAX, with the
> right POSIXly moves. It also plugs a hole the size of a coredump
> I accidentally run into while fooling around with the
H.Merijn Brand wrote:
>On Tue, 19 Jul 2005 12:06:00 +0300, Jarkko Hietaniemi <[EMAIL PROTECTED]>
>wrote:
>
>
>
>>The attached patch introduces %POSIX::SIGRT which gives access
>>to the POSIX real time signals SIGRTMIN...SIGRTMAX, with the
>>right POSIXly moves. It also plugs a hole the size of
On Tue, 19 Jul 2005 12:06:00 +0300, Jarkko Hietaniemi <[EMAIL PROTECTED]>
wrote:
> The attached patch introduces %POSIX::SIGRT which gives access
> to the POSIX real time signals SIGRTMIN...SIGRTMAX, with the
> right POSIXly moves. It also plugs a hole the size of a coredump
> I accidentally run
Jarkko Hietaniemi wrote:
> The attached patch introduces %POSIX::SIGRT which gives access
> to the POSIX real time signals SIGRTMIN...SIGRTMAX, with the
> right POSIXly moves. It also plugs a hole the size of a coredump
> I accidentally run into while fooling around with the patch, try
>
> perl -
The attached patch introduces %POSIX::SIGRT which gives access
to the POSIX real time signals SIGRTMIN...SIGRTMAX, with the
right POSIXly moves. It also plugs a hole the size of a coredump
I accidentally run into while fooling around with the patch, try
perl -MPOSIX -e 'sigaction(123,0)'
Merijn,
On 18/07/2005, at 2:05 AM, Michael G Schwern via RT wrote:
[EMAIL PROTECTED] - Sat Aug 30 14:33:01 2003]:
perl -wle '("1"x5683)=~ /^(11+)\1+$/'
works ok
perl -wle '("1"x 9973)=~ /^(11+)\1+$/'
Segmentation fault (core dumped)
ulimit -a
...
stack size (kbytes) 1048576
...
I can't re
> [EMAIL PROTECTED] - Sat Aug 30 14:33:01 2003]:
>
> perl -wle '("1"x5683)=~ /^(11+)\1+$/'
>
> works ok
>
> perl -wle '("1"x 9973)=~ /^(11+)\1+$/'
> Segmentation fault (core dumped)
>
> ulimit -a
> core file size (blocks) unlimited
> data seg size (kbytes) unlimited
> file size (blocks
> [shay - Wed Dec 15 03:19:13 2004]:
>
> Michael G Schwern wrote:
>
> >It appears to no longer be coring on 5.8.6.
> >
> It is still crashing for me on Win32 :(
>
> Produces an Access Violation error (more or less the Win32 equivalent
>of
> coring). Here's the call stack at the crash (using
> [EMAIL PROTECTED] - Wed Jul 23 08:17:50 2003]:
>
>
> Hello!
>
> i want to consult with you about strange
> behavior of perl v5.6.1 on FreeBSD 5.1 beta.
> may be something is wrong ... with perl or with me =)
>
> i wrote a small mail proxy which listens connections
> from local network and red
From a parallel universe, Nicholas Clark via RT <[EMAIL PROTECTED]>
scrawled.
> If you own an opteron machine and are allowed to install Fedora Core 4?
Ack... it was late when I filed this. Wrong machine - it's an ia32,
sorry..
> Given that the XS code for Ogg::Vorbis has this:
>
> OggVorb
On Mon, Jul 11, 2005 at 06:24:44PM -0700, paulb @ cajun. nu wrote:
> Trying to install Ogg::Vorbis using CPAN on perl 5.8.6 on
> amd64 Fedore Core 4, with latest OS updates. Easily reproducable.
If you own an opteron machine and are allowed to install Fedora Core 4?
> chmod 755 blib/arch/auto/O
# New Ticket Created by [EMAIL PROTECTED]
# Please include the string: [perl #36508]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=36508 >
This is a bug report for perl from [EMAIL PROTECTED],
generated with the help of
>
> I came across something similar to this the other day, using a recent
> gentoo ebuild of 5.8.6 (I /think/ it was 5.8.6-r1, but it might have
> been r2 or r3); triggered a segfault with:
>
> perl -e 'print if $. >= 1"'
>
> Upgrading to -r4 fixed the issue. FYI, HTH, HAND. =)
>
Great, probl
-
>
> I can reliably reproduce a core dump in a regular expression eval.
>
>
>
> I've seen this a number of times, working around it each time by
>
> changing either the data I'm matching or the expression itself.
>
> I just upgraded to 5.8, hoping thi
7;
> > Segmentation fault (core dumped)
> > [EMAIL PROTECTED] trew $ gdb -q -c core
> > Core was generated by `perl -e """'.
> > Program terminated with signal 11, Segmentation fault.
> > #0 0x80044e22 in ?? ()
> > (gdb) x/i $eip
> > 0x80044
t; > Segmentation fault (core dumped)
> > [EMAIL PROTECTED] trew $ gdb -q -c core
> > Core was generated by `perl -e """'.
> > Program terminated with signal 11, Segmentation fault.
> > #0 0x80044e22 in ?? ()
> > (gdb) x/i $eip
> > 0x80044e22:
On Wed, Mar 16, 2005 at 05:27:20AM -, Steve Peters via RT wrote:
> Can anyone else been able to replicate this core dump? I've tried the
No. Not with -O3 -fomit-framepointer on maint on x86 debian.
Nicholas Clark
t;"'.
> Program terminated with signal 11, Segmentation fault.
> #0 0x80044e22 in ?? ()
> (gdb) x/i $eip
> 0x80044e22: movzbl (%edx),%eax
> (gdb) i r edx eax
> edx0x0 0
> eax0x8011a93c -2146326212
>
>
Can anyone else bee
What version of the BerkeleyDB perl module are you running and what version
of Berkeley DB the library have you got? I've enclosed part of the
troubleshooting guide for BerkeleyDB at the end to help you find out these
things if you don't know.
I found (this) particular problem. I had my BerkelyDB c
isn't 0 (I will investigate what status=99 means
shortly), it seems like RETVAL is remaining NULL, and thats
what's ultimately causing teh core dump.
My intuitive guess is that that code should have an else clause,
to cope with the error condition. A module call failing shouldn't,
I d
From: Kean Johnston [mailto:[EMAIL PROTECTED]
> Hi all,
>
> This is my first posting to this list so go easy :)
>
> While doing a make test on the BerkeleyDB module I am getting a
> core dump from perl. A stack trace shows its breaking in
> Perl_newRV_noinc (tmpRef=0x0), c
Could you actually forward the backtrace. That would help find that
naughty NULL pointer that's causing the core dump.
Certainly. The only way I could get this detail was to break
inside the BerkeleyDB code, becuase if I just do a normal
"run" and then bt when it gets the SIGSEGV
On Thu, Feb 24, 2005 at 01:13:05PM -0800, Kean Johnston wrote:
> Hi all,
>
> This is my first posting to this list so go easy :)
>
> While doing a make test on the BerkeleyDB module I am getting a
> core dump from perl. A stack trace shows its breaking in
> Perl_newRV_noinc
Hi all,
This is my first posting to this list so go easy :)
While doing a make test on the BerkeleyDB module I am getting a
core dump from perl. A stack trace shows its breaking in
Perl_newRV_noinc (tmpRef=0x0), called from Perl_newRV (tmpRef=0x0).
Now, I dont know what conditions lead up to
> [RT_System - Wed Sep 12 00:19:22 2001]:
>
> The below at least replaces the core dump with an error:
>
> $ ./perl -wle '$b="abcde"; local $k; *k=\substr($b, 2, 1)'
> Can't modify non-existent substring.
>
> Change 12005 by [EMAIL PROTECTE
- Original Message -
From: "Andy Dougherty" <[EMAIL PROTECTED]>
To: "whitevamp" <[EMAIL PROTECTED]>
Cc: "Perl Porters" <[EMAIL PROTECTED]>
Sent: Friday, December 17, 2004 7:08 AM
Subject: Re: core dump
> On Sun, 28 Nov 2004, whitev
On Sun, 28 Nov 2004, whitevamp wrote:
> im running webmin or trying to and when i goto start it
> IE: /usr/local/webmin-conf/config-files-logs/webmin/start
>
> i get the following error
> Starting Webmin server in /usr/local/webmin
> Segmentation fault (core dumped)
> and i have posted a thred at
Michael G Schwern wrote:
>It appears to no longer be coring on 5.8.6.
>
It is still crashing for me on Win32 :(
Produces an Access Violation error (more or less the Win32 equivalent of
coring). Here's the call stack at the crash (using 5.8.6):
Perl_av_extend(av * 0x01830f5c, long 2147483647) l
Michael G Schwern wrote:
>
> You were correct in reporting the bug, nothing should make Perl dump core
> (unless, of course, you ask it to). And as seen from all the discussion
> on this bug it probably was fixed incidentally as opposed to explicitly.
>
> Just want to remind folks there is a tes
On Tue, Dec 14, 2004 at 01:15:52AM +0800, [EMAIL PROTECTED] wrote:
> It's just that I thought this should produce an error rather than
> a core dump. If version 5.8.6 now does produce an error, then I would now
> consider this issue resolved.
> naturally I came to the conclusion t
Ronald J Kimball <[EMAIL PROTECTED]> wrote:
On Mon, Dec 13, 2004 at 09:21:48AM -0500, Mike Giroux wrote:
> I wrote:
> >What's happening, I think, is that $#a for an empty array
> >is -1. So left shifting it _still_ gives -1, leaving perl
> >to try to create a 2^32 (or 64) element array.
>
> 2^31,
Here's my first reaction:
For the same reason $#a>>=1 shouldn't. This isn't C. -1 shouldn't
wrap around to MAXINT no matter what the user does.
Then I thought about it a little more. I don't know so much about bit
shifting, but isn't it pretty much asking for exactly this sort of
problem?
Pr
From: [EMAIL PROTECTED]
Hi Guys! Pardon me for saying so, but the reason I posted this in the first
place was because I didn't think that any instruction should actually make
perl
dump core.
I don't think you're going to find anyone on p5p who disagrees with that,
unless
you're playing with unpac
nitely the problem as you
suggest. I should have stated in my original posting that this is what I thought
was happening. It's just that I thought this should produce an error rather than
a core dump. If version 5.8.6 now does produce an error, then I would now
consider this issue resolved. It hadn&
On Mon, Dec 13, 2004 at 10:27:16AM -0500, Ronald J Kimball wrote:
> > >I think the only answer if you want to use that
> > >trick to shrink your array is to explicitly check
> > >if you're already done.
> >
> > Hmm, I take that back...
> >
>
wer if you want to use that
> >trick to shrink your array is to explicitly check
> >if you're already done.
>
> Hmm, I take that back...
>
> perl -e'$#a=-1'
>
> doesn't core dump, or warn.
Why would it? $#a=-1 just makes the array empty.
o use that
trick to shrink your array is to explicitly check
if you're already done.
Hmm, I take that back...
perl -e'$#a=-1'
doesn't core dump, or warn.
Neither do most other numeric ops on $#a when
uninitialized.
So it looks like there's already a sanity check
somewhere, and
John Krivitsky wrote:
The following line makes Perl dump core:
$#a>>=1;
if @a is empty (or undefined).
Cute...
I see you're using 5.8.3. Using my 5.8.6 build, I get
./perl -e'$#x>>=1'
Out of memory during array extend at -e line 1.
That's a bit better :)
What's happening, I think, is that $#
# New Ticket Created by John Krivitsky
# Please include the string: [perl #33003]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=33003 >
This is a bug report for perl from [EMAIL PROTECTED],
generated with the help of pe
>>
>>As in the following ticket,
>>http://rt.perl.org/rt3/Ticket/Display.html?id=7460, this core dump seems
>>to have been fixed prior to 5.8.0. I also built a 5.8.6, and this test
>>passed without any failures.
>
>
> Did you also try that with a *HUGE*
-----
> > > [Please enter your report here]
> > >
> > > Core dump deep down in the bowels of libc when endpwent() is called.
> > > I have little idea of how to even start fixing this. This used to
> > > work as a few w
On Wed 08 Dec 2004 01:58, "Steve Peters via RT" <[EMAIL PROTECTED]> wrote:
> > [EMAIL PROTECTED] - Sun Aug 05 01:50:04 2001]:
> >
> >
> > -
> > [Please enter your report here]
> >
> [EMAIL PROTECTED] - Sun Aug 05 01:50:04 2001]:
>
>
> -
> [Please enter your report here]
>
> Core dump deep down in the bowels of libc when endpwent() is called.
> I have little idea of how to even start
e]
>
> While teaching a Perl course at HP, one of the students pointed out
> running a solution of one of the exercises gives a core dump.
>
> I narrowed it down to the following program:
>
> #!/usr/bin/perl -w
> setpwent;
> 1 while getpwent;
>
Nicholas Clark <[EMAIL PROTECTED]> writes:
> On Wed, Oct 08, 2003 at 03:49:16AM -0700, Gisle Aas wrote:
>
> > ..and, yes, I know I'm playing with an undocumented feature.
>
> Given that it's undocumented, and that the filter semantics used by the
> @INC filters are "broken" w.r.t. how proper fil
in the BEGIN block case, while the clone will not continue the
parse after the BEGIN, I don't think any other badness (such as a core
dump) should happen.
So I think Tim's test case needs some other explanation.
Sarathy
[EMAIL PROTECTED]
Tim Bunce <[EMAIL PROTECTED]> wrote:
:I'd really appreciate this patch going in, or better still the
:underlying problem being solved, otherwise the next DBI release
:will be triggering core dumps for all 5.8 ithreads users.
I wonder whether this could be related to my recent fix for C?
I don't o
This test needs to be made conditional on the existence of PerlIO.
--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen
[EMAIL PROTECTED] wrote:
:Perl gives a segmentation fault and core dump when redefining
:sort subroutine and calling it via goto &NAME. E.g
:
:@sorted = sort foo @myarray
:
:sub foo {
: goto &sortsub
:}
:
:sub sortsub{
:#sort code
:}
Just found this bug report back. I can confirm that
Here's a patch that fixes the "die in SPLICE" bug. In fact, it probably
fixes a whole host of mysterious eval/die bugs.
Hooray.
But
it works by changing the way Perl handles inner runops() loops,
And...
it's written by me, who up until a week ago didn't have a clue
how any of this here high-
Hugo Van Der Sanden <[EMAIL PROTECTED]> writes:
>Slaven Rezic <[EMAIL PROTECTED]> wrote:
>:I'm not sure whether this is a Perl/Tk or perl problem:
>[...]
>:
>:In perl's Perl_regexec_flags function, a core will be dumped at line
>:1427:
>:bool do_utf8 = DO_UTF8(sv);
>
>That's a problem with the
On Fri, 24 Aug 2001 at 15:52:42 -0400, Michael G Schwern wrote:
> On Fri, Aug 24, 2001 at 02:25:42PM +0100, Ian Phillipps wrote:
> > Where do I get bleadperl, or diffs 5.7.2->there? Is there an rsync
> > server?
>
> Read the perlhack man page. It's mentioned as perl-current.
Thanks, sorry to pr
This is a bug report for perl from [EMAIL PROTECTED],
generated with the help of perlbug 1.33 running under perl v5.6.1.
-
[Please enter your report here]
The following produces a SEGV. It's a minimal reduction of a program that'
Here's stack trace from Tru64:
kosh:/tmp/jhi/perl ; gdb ./perl core.perl.kosh.0
GDB is free software and you are welcome to distribute copies of it
under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for details.
GDB
On Sun, Jun 10, 2001 at 12:35:12AM +0300, Samuli Kärkkäinen wrote:
>
> This is a bug report for perl from [EMAIL PROTECTED],
> generated with the help of perlbug 1.28 running under perl v5.6.0.
>
>
> -
> [Please enter your report h
58 matches
Mail list logo
