On Thursday 31 January 2008 14:21:27 Zev Benjamin wrote:
> The attached code makes parrot segfault (invoked as "./parrot
> segfault.pir"). I attempted to debug, but wasn't able to get to the
> root of the problem. It seems as though VTABLE_get_class() on line 64
>
FWIW, running under valgrind gives:
uniqua:~/parrot $ valgrind ./parrot segfault.pir
==19577== Memcheck, a memory error detector.
==19577== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et
al.
==19577== Using LibVEX rev 1804, a library for dynamic binary
translation.
==19577== Cop
# New Ticket Created by Zev Benjamin
# Please include the string: [perl #50440]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=50440 >
The attached code makes parrot segfault (invoked as "./parrot
segfault.p
I have found a way to segfault parrot. (I know that the following code is
incorrect):
[EMAIL PROTECTED]/prg/parrot$ cat hello.pasm
main:
set I0, 3
set I1, 2
get_results "(0)", I0
set_args "(0,0)", P0, I1
fakesub:
get_params "(0,0)", I0, I1
add I0,
On Wed, Jun 29, 2005 at 08:37:44AM -0700, chromatic wrote:
> On Wed, 2005-06-29 at 10:59 -0400, Matt Fowles wrote:
>
> > Would it be reasonable to not run tests that are known to leave core
> > files? I feel like after a successful build there should not be
> > evidence like this left around...
>
On Wed, 2005-06-29 at 10:59 -0400, Matt Fowles wrote:
> Would it be reasonable to not run tests that are known to leave core
> files? I feel like after a successful build there should not be
> evidence like this left around...
People could set ulimit (though we'd have to tell them all to do that
Leo~
On 6/29/05, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Matt Fowles wrote:
>
> > Core was generated by `./parrot --gc-debug
> > /home/mfowles/perl6/parrot/t/pmc/io_1.pir'.
>
> Ah. ok. That's a TODO tests that is supposed to fail. It is testing io
> opcodes with undefs and integer PMCs.
>
On Wednesday 29 June 2005 15:24, Matt Fowles wrote:
> t/pmc/io_1.pir
Ah, yes. This is a failing todo test. The useage of IO ops on non IO-PMCs is
not specced yet.
jens
#6 0x08128193 in PIO_putps (interpreter=0x826e050, pmc=0x82a93e8,
s=0x843c7d8) at io/io.c:1011
1006INTVAL
1007PIO_put
Matt Fowles wrote:
Core was generated by `./parrot --gc-debug
/home/mfowles/perl6/parrot/t/pmc/io_1.pir'.
Ah. ok. That's a TODO tests that is supposed to fail. It is testing io
opcodes with undefs and integer PMCs.
As soon as the io opcodes are methods in ParrotIO we get type safety and
ap
Jens~
On 6/29/05, Jens Rieks <[EMAIL PROTECTED]> wrote:
> > #13 0x0808588e in main (argc=1, argv=0xb8ac) at imcc/main.c:637
> Can you please run
> print ((char**)0xb8ac)[1]
> to find out which file causes the coredump??
Sure!
> gdb ./parrot core
Core was generated by `./parrot --gc-debu
> #13 0x0808588e in main (argc=1, argv=0xb8ac) at imcc/main.c:637
Can you please run
print ((char**)0xb8ac)[1]
to find out which file causes the coredump??
jens
All~
Although all tests pass, a core file is created during the test run.
Here is a little snippet from GDB. I am running a fairly stock Debian
Testing x86 (slightly out of date).
(gdb) list
1006INTVAL
1007PIO_putps(theINTERP, PMC *pmc, STRING *s)
1008{
1009ParrotIOLayer *l
12 matches
Mail list logo
