Yep, you were right...I made a patch for you and applied it :)
Thanks!
Tanton
Philip Kendall wrote:
* The trickier one: with the above two changes, test and test2 work,
but test3 tries to pop a non-existent stack frame. In Parrot_pop_i,
should the fragment:
if (chunk_base->prev) {
At 10:17 PM 9/12/2001 +0100, Philip Kendall wrote:
>On Wed, Sep 12, 2001 at 07:21:06PM +0100, Philip Kendall wrote:
>
>[Coredumps on Alpha]
>
> > Quick research reveals the obvious problem: even when IVs are 64 bit,
> > assemble.pl is still 32 bit (as $pack_types{i} is the 32-bit type 'l').
> > Ch
On Wed, Sep 12, 2001 at 07:21:06PM +0100, Philip Kendall wrote:
[Coredumps on Alpha]
> Quick research reveals the obvious problem: even when IVs are 64 bit,
> assemble.pl is still 32 bit (as $pack_types{i} is the 32-bit type 'l').
> Changing this over to 'q' means I get further, but it's still
>
On Wed, Sep 12, 2001 at 02:54:49PM +0100, Philip Kendall wrote:
> On Wed, Sep 12, 2001 at 09:45:42AM -0400, Dan Sugalski wrote:
> > At 02:40 PM 9/12/2001 +0100, Philip Kendall wrote:
> > >
> > >Now works on Solaris and i386, but segfaults at the GRAB_IV call in
> > >read_constants_table on my Alph
At 09:57 AM 9/12/2001 -0700, Hong Zhang wrote:
> > Now works on Solaris and i386, but segfaults at the GRAB_IV call in
> > read_constants_table on my Alpha. Problems with the integer-pointer
> > conversions in memory.c? (line 29 is giving me a warning).
>
>The line 29 is extremely wrong. It assign
> Now works on Solaris and i386, but segfaults at the GRAB_IV call in
> read_constants_table on my Alpha. Problems with the integer-pointer
> conversions in memory.c? (line 29 is giving me a warning).
The line 29 is extremely wrong. It assigns IV to void* without casting.
The alignment calculatio
At 12:18 PM 9/12/2001 +0100, Simon Cozens wrote:
>On Wed, Sep 12, 2001 at 12:11:35PM +0100, Philip Kendall wrote:
> > test3.pbc is still segfaulting on me though.
>
>Yes, it is here too; I've sent some debugging info to Dan
>and he's having a look at it. I'm trying to take a look at
>it too. I sus
On Wed 12 Sep 2001 13:23, Nicholas Clark <[EMAIL PROTECTED]> wrote:
> Can we usefully smoke parrots yet?
> Or is this something that someone (Schwern?) is working on?
>
> [in that as all the world is not a vax^Wx86 it would be useful to smoke on
> "obscure" architectures that SIGBUS on unaligned
On Wed, Sep 12, 2001 at 12:11:35PM +0100, Philip Kendall wrote:
> test3.pbc is still segfaulting on me though.
Yes, it is here too; I've sent some debugging info to Dan
and he's having a look at it. I'm trying to take a look at
it too. I suspect that CHUNK_BASE isn't doing what it should.
Simon
On Tue, Sep 11, 2001 at 10:23:51AM -0700, Daniel Sully wrote:
[Parrot coredumps on Solaris]
> It also coredumps on Solaris 7, when running the test2.pbc - test.pbc is
> fine. The coredump doesn't show much, only that it keeled over at
> interpreter.c line 16, which is the while() loop.
That was
It also coredumps on Solaris 7, when running the test2.pbc - test.pbc is
fine. The coredump doesn't show much, only that it keeled over at
interpreter.c line 16, which is the while() loop.
Once upon a time Philip Kendall shaped the electrons to say...
>
>
> Hi.
>
> I've just tried getting Pa
Hi.
I've just tried getting Parrot running on a Solaris 8 box here, but it's
coredumping on me with test2.pasm and test3.pasm:
cass87:pak:~/data2/parrot$ ./test_prog test.pbc
I reg 1 is 1000206849
I reg 5 is 1000206859
I reg 2 is 1000
I reg 2 is 10
I reg 4 is 3000
N reg 1 is 3000.
12 matches
Mail list logo