*From:* ToddAndMargo via perl6-users
*Sent:* Friday, August 30, 2019 7:21 PM
*To:* perl6-us...@perl.org
*Subject:* Re: core dump
On 8/9/19 3:41 PM, ToddAndMargo via perl6-users wrote:
Hi All,
Fedora 30
rakudo-0.2019.03-2.fc30.x86_64
I have a weird question. I need to simulate a core
dump
argc[0]=
argc[1]=<20575>
argc[2]=
argc[3]=
argc[4]=
Total bytes in core dump: 282624
I used just
$ perl
^\Quit (core dumped)
$ cat core.info
argc=5
argc[0]=
argc[1]=<3804>
argc[2]=
argc[3]=
argc[4]=
Total b
On 8/9/19 3:41 PM, ToddAndMargo via perl6-users wrote:
Hi All,
Fedora 30
rakudo-0.2019.03-2.fc30.x86_64
I have a weird question. I need to simulate a core
dump under a bash (ulimit) shell.
Any of you guys know who to get Perl to crash with a
core dump?
I need to prove that core dumps are
Hi All,
Fedora 30
rakudo-0.2019.03-2.fc30.x86_64
I have a weird question. I need to simulate a core
dump under a bash (ulimit) shell.
Any of you guys know who to get Perl to crash with a
core dump?
I need to prove that core dumps are not
active on my system. Or if I am mistaken.
Many
# New Ticket Created by Ben Sauvin
# Please include the string: [perl #133162]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=133162 >
I'm trying to run this code:
my $n;
await IO::Socket::Async.connect('127.0.0.1', 5000).the
On Wed, 12 Jul 2017 15:30:33 -0700, ug...@cpan.org wrote:
> Resolved in https://github.com/rakudo/rakudo/commit/c86090e
>
> `perl6 -e 'run("ls", :merge).out.slurp.say'`
Worls on OSX as well. The fudged test was unfudged by ugexe++. Closing issue.
Resolved in https://github.com/rakudo/rakudo/commit/c86090e
`perl6 -e 'run("ls", :merge).out.slurp.say'`
I've unsuccessfully tried to fix this, but I've come up with an idea how an
actual fix might go.
When the merge flag (which I added in recent commits) gets passed to
MVM_proc_spawn or MVM_proc_shell, we have to first create a new pipe on our
own, then set up both stdio 1 and 2 to UV_REUSE_STREA
# New Ticket Created by Daniel Green
# Please include the string: [perl #128594]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=128594 >
perl6 --version
This is Rakudo version 2016.06-220-g2ad3239 built on MoarVM version
2016
Also, the Kubuntu system Rakudo was built with --gen-moar, on the Arch
Linux system MoarMV, NQP, and Rakudo were all built separately with the
same --prefix.
On Wed, Jun 15, 2016 at 12:01 AM, Daniel Green wrote:
> Doesn't happen every time, seem to be about 1 in 5. Here are the results
> for two
Doesn't happen every time, seem to be about 1 in 5. Here are the results
for two different system.
This is an up-to-date Arch Linux
uname -a
Linux 4.5.3-1-ARCH #1 SMP PREEMPT Sat May 7 20:43:57 CEST 2016
x86_64 GNU/Linux
p6 --version
This is Rakudo version 2016.05-145-gac0dcdd built on MoarVM v
Also, running it ~30 times without profiling never saw a crash.
On Wed, Jun 15, 2016 at 12:04 AM, Daniel Green wrote:
> Also, the Kubuntu system Rakudo was built with --gen-moar, on the Arch
> Linux system MoarMV, NQP, and Rakudo were all built separately with the
> same --prefix.
>
> On Wed, Ju
ay $proc.out.slurp-rest;
Removing the :merge eliminates the core dump. This is with the latest Rakudo on
moar.
# New Ticket Created by Adrian White
# Please include the string: [perl #75502]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=75502 >
Using %() to coerce hash context causes Rakudo to core dump.
e.g. Using Rak
On Wed Oct 05 22:27:25 2005, jhi wrote:
> Didn't notice this earlier because the whole japh.t is
> reported as succeeding even though a core dump happens
> for the subtest #10.
>
Since we're on 0.6.0 now and there are only 5 tests left in this test file,
rejecting thi
The test t/src/hash_6.c is still dumping core for me. I haven't tried
debugging in detail beyond the information already in the RT ticket.
--
Andy Dougherty [EMAIL PROTECTED]
# New Ticket Created by Jarkko Hietaniemi
# Please include the string: [perl #41251]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=41251 >
---
osname= dec_osf
osvers= 5.1a
arch= alpha-dec_osf-thread-multi
cc= cc V6.4
166000) ["myops.ops":55\
, 0x3001ac4]
...
So haha, the Parrot_hcf() still halts and catches fire. Very funny, haha.
The problem is that it shows up as a core dump. Surely this test could
be implemented somehow differently and still be funny?
---
Summary of my parrot 0.4.7 (r
# New Ticket Created by Jarkko Hietaniemi
# Please include the string: [perl #41255]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=41255 >
---
osname= dec_osf
osvers= 5.1a
arch= alpha-dec_osf-thread-multi
cc= cc V6.4
# New Ticket Created by Jarkko Hietaniemi
# Please include the string: [perl #41249]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=41249 >
---
osname= dec_osf
osvers= 5.1a
arch= alpha-dec_osf-thread-multi
cc= cc V6.4
# New Ticket Created by Jarkko Hietaniemi
# Please include the string: [perl #41254]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=41254 >
---
osname= dec_osf
osvers= 5.1a
arch= alpha-dec_osf-thread-multi
cc= cc V6.4
# New Ticket Created by Jarkko Hietaniemi
# Please include the string: [perl #41257]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=41257 >
---
osname= dec_osf
osvers= 5.1a
arch= alpha-dec_osf-thread-multi
cc= cc V6.4
un-subscribe
On 8/4/06, Chip Salzenberg via RT <[EMAIL PROTECTED]> wrote:
Fixed in svn by deleting that never-will-work-again japh,
which hacked internals in an amazingly evil way.
Chip Salzenberg via RT wrote:
> parrot obeys you
> when you ask it politely
> to halt and catch fire
The test harness
should kindly be told about
this confusing anomaly
I never could get my
haikus to work
--
Jarkko Hietaniemi <[EMAIL PROTECTED]> http://www.iki.fi/jhi/ "There is this
special
bio
Fixed in svn by deleting that never-will-work-again japh,
which hacked internals in an amazingly evil way.
parrot obeys you
when you ask it politely
to halt and catch fire
Fixed in svn.
Actual bug was causing malloc(0).
Proximate bug is that, on tru64, malloc(0) fails. :-)
Until we know what these I/O ops should do, seg faults aren't
unexpected. Nor are they something we can meaningfully fix.
This ticket now depends on the review of the I/O pdd.
This ticket now depends on ResizeableBooleanArray rewrite.
7;,
2 => 'opcode "pack" is gone',
4 => 'namespace has changed',
9 => 'P1 is no longer special',
10 => 'core dump',
...
Todo tests are run and supposed to fail or not to gi
Wow. So I've just learned that our test harness ignores seg faults. Which
explains why t/examples/japh.t keeps reporting "all tests successful" when
actually they're mostly segfaulting and otherwise failing.
This particular japh uses threading, which is known not to work until the
STM work by Ch
On Mon, Jul 10, 2006 at 02:18:21PM -0500, Patrick R. Michaud wrote:
> I totally agree that PGE probably needs to provide better syntax
> error checking in situations such as this, thus I'm leaving this
> ticket open, or will add a new more descriptive one soon.
But why the core dum
On Sun, Jul 09, 2006 at 07:15:07PM -0700, Kevin Tew wrote:
> ../../parrot ../../compilers/pge/pgc.pir
> --output=lib/pruby_grammar_gen.pir lib/pruby.pg
> Method 'reduce' not found
> current instr.: 'parrot;PGE::Exp::Quant;reduce' pc 4358
> (compilers/pge/PGE/Exp.pir:402)
> ...
> pruby.pg is avail
# New Ticket Created by Kevin Tew
# Please include the string: [perl #39776]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=39776 >
---
osname= darwin
osvers= 8.0
arch= darwin-thread-multi-2level
cc= cc
---
Flags:
hcf is actually supposed to explode if possible. Not sure if we should:
1) skip the test usually;
2) close the ticket as "not a bug"
3) eliminate this particular (silly) dynamic opcode.
Regards.
On Jul 7, 2006, at 2:04 AM, Jarkko Hietaniemi (via RT) wrote:
# New Ticket Created by Jarkko Hiet
# New Ticket Created by Jarkko Hietaniemi
# Please include the string: [perl #39752]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=39752 >
(dbx) run --gc-debug t/pmc/lexicals_27.pir
# Failed test (t/op/lexicals.t at l
# New Ticket Created by Jarkko Hietaniemi
# Please include the string: [perl #39751]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=39751 >
(dbx) run --gc-debug t/dynoplibs/myops_4.pir
neither here
thread 0x3 signal Segment
# New Ticket Created by Jarkko Hietaniemi
# Please include the string: [perl #39756]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=39756 >
(dbx) run --gc-debug t/examples/japh_10.pasm
run --gc-debug t/examples/japh_10.pasm
# New Ticket Created by Jarkko Hietaniemi
# Please include the string: [perl #39750]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=39750 >
(dbx) run --gc-debug t/examples/japh_12.pasm
Parrot VM: PANIC: Out of bound registe
# New Ticket Created by Jarkko Hietaniemi
# Please include the string: [perl #39753]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=39753 >
(dbx) run --gc-debug t/pmc/io_1.pir
Undef ok 1
Undef ok 2
Assertion failed: (unsign
# New Ticket Created by Jarkko Hietaniemi
# Please include the string: [perl #39754]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=39754 >
(dbx) run --gc-debug t/pmc/resizablebooleanarray_20.pasm
thread 0x3 signal Segmenta
Jarkko -
Is this still an issue with svn-latest ?
> [jhi - Wed Oct 05 22:27:25 2005]:
>
> Didn't notice this earlier because the whole japh.t is
> reported as succeeding even though a core dump happens
> for the subtest #10.
>
>1 pthread_kill(0x0, 0x1
Jarkko Hietaniemi wrote:
Joshua Hoblitt via RT wrote:
It's a test failure for unimplemented feature(s). There is already a
TODO ticket (bug #31178) that ruffly covers this. Can you make a case
for why it needs to be to tracked as a software defect?
A core dump is a software defec
Joshua Hoblitt via RT wrote:
> On Sat, Oct 15, 2005 at 11:09:38AM +0300, Jarkko Hietaniemi wrote:
>
>>Joshua Hoblitt via RT wrote:
>>
>>>According to our records, your request regarding
>>> "[BUG] Parrot 0.3.0 t/pmc/io.t assert core dump"
>&
On Sat, Oct 15, 2005 at 11:09:38AM +0300, Jarkko Hietaniemi wrote:
> Joshua Hoblitt via RT wrote:
> > According to our records, your request regarding
> > "[BUG] Parrot 0.3.0 t/pmc/io.t assert core dump"
> > has been resolved.
>
> According to my record
Joshua Hoblitt via RT wrote:
> According to our records, your request regarding
> "[BUG] Parrot 0.3.0 t/pmc/io.t assert core dump"
> has been resolved.
According to my records, it's a TODO test and therefore not quite
yet resolved :-)
> If you have any further qu
cceeding even though a core dump happens
for the subtest #10.
1 pthread_kill(0x0, 0x11fffb038, 0x0, 0x11fffc010, 0x3ff0001)
[0x3ff805c0ed0]
2 (unknown)() [0x3ff805c7908]
3 (unknown)() [0x3ff80633994]
4 exc_raise_signal_exception(0xb0ffe0003, 0x86, 0x0, 0x12013b8ac,
0x1) [0x3ff80633d
Jarkko Hietaniemi (via RT) wrote:
# New Ticket Created by Jarkko Hietaniemi
# Please include the string: [perl #37336]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=37336 >
$ ./parrot t/pmc/io_1.pir
This is a TODO tes
# New Ticket Created by Jarkko Hietaniemi
# Please include the string: [perl #37336]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=37336 >
$ ./parrot t/pmc/io_1.pir
Undef ok 1
Undef ok 2
Assertion failed: (unsigned long)l
Nick Glencross <[EMAIL PROTECTED]> wrote:
> Guys,
> This isn't a highly critical segfault I imagine, although it might be of
> interest to someone.
> I discovered 'make fulltest' this evening. One of the debuginfo tests
> (#7) fails as follows with r7942 on i386 Linux:
> [EMAIL PROTECTED] parro
3 subtests skipped.
Failed 1/1 test scripts, 0.00% okay. 1/8 subtests failed, 87.50% okay.
There's a core dump (the last line of output wasn't printed), and a
backtrace reveals:
Loaded symbols for /lib/ld-linux.so.2
#0 0x080c578a in gc_ms_get_free_object (interpreter=0x8256db8,
pool=0x82
Bernhard Schmalhofer <[EMAIL PROTECTED]> wrote:
> since a couple of days the example japh16 is dumping core on my Linux
> machine.
> It looks like there was a free on a NULL, when cleaning up packfile
> segments. The attached patch checks wether there is a fixup table in the
> seqment.
> I'm not
# New Ticket Created by Bernhard Schmalhofer
# Please include the string: [perl #32450]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=32450 >
Hi,
since a couple of days the example japh16 is dumping core on my Linux
ma
53 matches
Mail list logo
