[perl #42792] GC bug added in r18323

[via RT]

# New Ticket Created by  Joshua Isom 
# Please include the string:  [perl #42792]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org/rt3/Ticket/Display.html?id=42792 >


My current svn repository uses a patch that I sent to the list about a 
week ago, in which the pge tests would run with gc on if the file 
DEVELOPING existed.  Since I updated to over 18323, 
t/compilers/pge/p5regex/p5rx.t segfaults after test 553.  The 
current_cont in the interp's ctx is null, and results in a segfault 
inside of set_returns.  It doesn't happen on my darwin-ppc system, so I 
don't know how specific it is, and if rebooting will fix it(as often 
happens with the gc bugs in my experience).  But it is failing on my 
freebsd-amd64 system.  Since odds are r18323 just exposed a bug instead 
of adding one, maybe other people will get the crash as well.  You will 
have to remove -G in t/compilers/pge/p5regex.t/p5rx.t to get it to 
fail, as with -G it succeeds(and with -t too).

I've learned a lot lately about how to use gdb, and all I've come to 
learn is that if 
interp->ctx.state->current_cont->obj.u._ptrs._struct_val is null, 
parrot isn't happy, of course that's with macro expansion, and that 
getting the level of debugging information I'd like to be able to write 
little tools to process an analyze it better isn't easy.

[perl #42790] [BUG] Tailcall with slurpy argument passing causes a memory leak

[Mehmet Yavuz Selim Soyturk]

# New Ticket Created by  "Mehmet Yavuz Selim Soyturk" 
# Please include the string:  [perl #42790]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org/rt3/Ticket/Display.html?id=42790 >


Next program makes a slurpy tailcall, and it causes a memory leak for me.

.sub callee
   .param pmc params :slurpy

   $P0 = new .Integer
   .return ($P0)
.end

.sub caller
$P0 = new .Integer
$P1 = new .Float
$P2 = new .ResizablePMCArray

# tailcall causes a memory leak
.return callee($P0, $P1, $P2)
.end

.sub main :main
  loop:
caller()
goto loop
.end



parrot revision r18352
i686 GNU/Linux

-- 
Mehmet

Re: [perl #42769] can't create a variable named 'object'

[Klaas-Jan Stol]

hi,

related to this, I think that imcc also allows for built-in types as types.
such as ".local Array a" etc. (sorry can't check; don't have my own pc
around here, this is a public pc) (I added some notes about this and other
PIR cleanups in languages/PIR and I think also in compilers/pirc IIRC).

IMHO, this is not needed; "pmc" is sufficient, and it'd be nice to keep PIR
as simple as possible, after all it's an intermediate language. Moreover,
everytime a built-in type is added (although not happening that often) the
grammar would have to be updated to stay consistent.

my 2c,
kjs



On 4/28/07, via RT Jerry Gay <[EMAIL PROTECTED]> wrote:


# New Ticket Created by  Jerry Gay
# Please include the string:  [perl #42769]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=42769 >


it seems that 'object' is a reserved word in imcc, it's a synonym for
'pmc'. it seems undocumented, and i don't see a reason for it--we
already have a word for 'pmc'.

D:\usr\local\parrot\head>parrot -
.sub main
.local pmc object
.end
^Z
error:imcc:syntax error, unexpected OBJECTV, expecting IDENTIFIER
 in file '-' line 2


sure enough, i can create a '.local object foo':

D:\usr\local\parrot\head>parrot -
.sub main
.local object foo
foo = new 'String'
foo = 'bar'
say foo
.end
^Z
bar


i suggest we deprecate 'object'.
~jerry

Re: [perl #42768] [PATCH] Enum cleanups

[Klaas-Jan Stol]

On 4/28/07, chromatic <[EMAIL PROTECTED]> wrote:


On Friday 27 April 2007 12:22, Steve Peters wrote:

> The attached additional patch fixes one problem caused by the previous
> patch and gets Intel C++ to compile and pass all of its tests on
> Linux.  Only apply the attached patch after applying the first patch.

This part bothers me:

--- src/mmd.c   (revision 18345)
+++ src/mmd.c   (working copy)
@@ -1703,7 +1703,12 @@
 * register default mmds for this type
 */
for (i = 0; i < n; ++i) {
+/* The following always fails for Intel C++ for unknown reasons,
+ * but I'm assuming its optimizer related.
+ */



eeuhw, "assuming" ? I guess that'snot what you want in a multi-platform,
stable, production environment that parrot will be...


kjs

Re: [perl #42768] [PATCH] Enum cleanups

[Leopold Toetsch]

Am Freitag, 27. April 2007 22:10 schrieb chromatic:
> This part bothers me:

Indeed, your feeling is totally legitimate.

> +++ src/mmd.c   (working copy)
> @@ -1703,7 +1703,12 @@

> +#ifndef __INTEL_COMPILER
>          assert((PTR2UINTVAL(mmd_table[i].func_ptr) & 3) == 0);

The assert is of course there for some reason. The lower bit(s) are used for 
flagging the contents of the MMD table:

From mmd.c:147 ff

*is_pmc = (UINTVAL)func & 3;
func_ = (funcptr_t)((UINTVAL)func & ~3);
#ifndef PARROT_HAS_ALIGNED_FUNCPTR

... and as the snippet reveals, there's also alternate code to deal with 
compilers which don't align function pointers (ususally there is a compiler 
flag to achieve this too).

Background:

The mmd_table is a huge cache of known binary MMD functions, which are coded 
in C or are PMCs. But as the table is quadratic (per function) and very 
sparse, it should be replaced with some better structures e.g. per PMC or by 
some compressed table.

leo

Re: [perl #42768] [PATCH] Enum cleanups

[Joshua Isom]

On Apr 27, 2007, at 2:22 PM, Steve Peters wrote:


On Fri, Apr 27, 2007 at 09:22:22AM -0700, Steve Peters wrote:

# New Ticket Created by  Steve Peters
# Please include the string:  [perl #42768]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=42768 >


Intel C++ complains very loudly using enum types in variable and 
parameter

declarations.   This patch helps to clean them up.



The attached additional patch fixes one problem caused by the previous
patch and gets Intel C++ to compile and pass all of its tests on
Linux.  Only apply the attached patch after applying the first patch.



But fails all the stm tests on freebsd amd64.  I don't understand how, 
but it might be worth testing on another 64 bit system and seeing if 
it's just that.



Steve Peters
[EMAIL PROTECTED]

Re: [perl #42774] [PATCH] Configure.pl --gc=libc doesn't compile

[Allison Randal]

chromatic wrote:

On Friday 27 April 2007 11:19, Andy Dougherty wrote:


Unfortunately, Configure.pl --gc=libc doesn't compile.  I don't know how
long it's been broken.  I do I know *I* haven't tried it for a very long
time.  Here's the error message I get


I'm going to hold off on this patch. Allison?


I've added this ticket as a dependency for the 0.4.12 release ticket. 
Best is to fix the bug before the release, but if not, apply the patch.


Allison

Re: [perl #42792] GC bug added in r18323

[Allison Randal]

Joshua Isom (via RT) wrote:


My current svn repository uses a patch that I sent to the list about a 
week ago, in which the pge tests would run with gc on if the file 
DEVELOPING existed.  Since I updated to over 18323, 
t/compilers/pge/p5regex/p5rx.t segfaults after test 553.  The 
current_cont in the interp's ctx is null, and results in a segfault 
inside of set_returns.  It doesn't happen on my darwin-ppc system, so I 
don't know how specific it is, and if rebooting will fix it(as often 
happens with the gc bugs in my experience).  But it is failing on my 
freebsd-amd64 system.  Since odds are r18323 just exposed a bug instead 
of adding one, maybe other people will get the crash as well.  You will 
have to remove -G in t/compilers/pge/p5regex.t/p5rx.t to get it to 
fail, as with -G it succeeds(and with -t too).


I can't duplicate the error on darwin-intel or ubuntu-x86. Could be 
specific to FreeBSD (which might help us pin it down further).


I've learned a lot lately about how to use gdb, and all I've come to 
learn is that if 
interp->ctx.state->current_cont->obj.u._ptrs._struct_val is null, 
parrot isn't happy, of course that's with macro expansion, and that 
getting the level of debugging information I'd like to be able to write 
little tools to process an analyze it better isn't easy.


Could you send us a stack trace? (gdb command bt) Also, if you haven't 
already, try a make realclean (we've made some significant fundamental 
changes recently).


Thanks!
Allison

[PATCH] Re: [perl #42616] Parrot won't build with perl-5.6.

[Bob Rogers]

   From: Andy Dougherty <[EMAIL PROTECTED]>
   Date: Fri, 27 Apr 2007 10:47:55 -0400 (EDT)

   On Fri, 27 Apr 2007, Allison Randal via RT wrote:

   > Agreed. I hate yielding compatibility, but it makes sense in this case 
   > (since we're likely to eventually require that any Perl 5 code in the 
   > repository be able to run on the Parrot implementation of Perl 5).

   Fair enough.  I suggest the following patch.  (The 5.8.4 version is 
   arbitrary.  It's the oldest 5.8.x I happen to have installed for easy 
   testing.  It should perhaps be replaced with whatever version regular 
   Parrot contributors are going to be using.)

FWIW, I build Parrot regularly using 5.8.1.  Out of curiosity, I tried
it with 5.8.0 (which is the oldest version I have readily available),
and it only needed a trivial tweak (attached), which would allow us to
say "Needs Perl 5.8.x" here.  Do we care enough that I should commit
this?

-- Bob Rogers
   http://rgrjr.dyndns.org/

* lib/Parrot/Pmc2c/delegate.pm:
   + (body):  Minor tweak to make this work in 5.8.0.

Diffs between last version checked in and current workfile(s):

Index: lib/Parrot/Pmc2c/delegate.pm
===
--- lib/Parrot/Pmc2c/delegate.pm(revision 18352)
+++ lib/Parrot/Pmc2c/delegate.pm(working copy)
@@ -96,9 +96,11 @@
 
 # I think that these will be out by one - NWC
 my $l = $self->line_directive( $line, "delegate.c" );
+# [Leave the space between "${decl}" and the "{"; otherwise Perl 5.8.0
+# thinks this is a hashref.  -- rgr, 29-Apr-07.]
 my $cout = <

Re: [perl #42792] GC bug added in r18323

[Joshua Isom]

On Apr 29, 2007, at 12:55 PM, Allison Randal via RT wrote:


Joshua Isom (via RT) wrote:


My current svn repository uses a patch that I sent to the list about a
week ago, in which the pge tests would run with gc on if the file
DEVELOPING existed.  Since I updated to over 18323,
t/compilers/pge/p5regex/p5rx.t segfaults after test 553.  The
current_cont in the interp's ctx is null, and results in a segfault
inside of set_returns.  It doesn't happen on my darwin-ppc system, so 
I

don't know how specific it is, and if rebooting will fix it(as often
happens with the gc bugs in my experience).  But it is failing on my
freebsd-amd64 system.  Since odds are r18323 just exposed a bug 
instead
of adding one, maybe other people will get the crash as well.  You 
will

have to remove -G in t/compilers/pge/p5regex.t/p5rx.t to get it to
fail, as with -G it succeeds(and with -t too).


I can't duplicate the error on darwin-intel or ubuntu-x86. Could be
specific to FreeBSD (which might help us pin it down further).


I've learned a lot lately about how to use gdb, and all I've come to
learn is that if
interp->ctx.state->current_cont->obj.u._ptrs._struct_val is null,
parrot isn't happy, of course that's with macro expansion, and that
getting the level of debugging information I'd like to be able to 
write

little tools to process an analyze it better isn't easy.


Could you send us a stack trace? (gdb command bt) Also, if you haven't
already, try a make realclean (we've made some significant fundamental
changes recently).

Thanks!
Allison




I've done realclean a few times actually.  If I run with r18322, it 
runs just fine, but r18323, which dealt with zero length mallocs for 
strings, caused it to start crashing.  Here's a backtrace.  This is one 
of those tests where with -G it succeeds, so you'll have to make sure 
that gc is enabled.  I'm not having any trouble on my darwin/ppc 
machine, but my only two running platforms are darwin/ppc and 
freebsd/amd64.



[freebsd:~/parrot] jisom% gdb parrot parrot.core
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and 
you are
welcome to change it and/or 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.

This GDB was configured as "amd64-marcel-freebsd"...
Core was generated by `parrot'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from 
/usr/home/jisom/parrot/blib/lib/libparrot.so.0.4.11...done.

Loaded symbols for /usr/home/jisom/parrot/blib/lib/libparrot.so.0.4.11
Reading symbols from /lib/libpthread.so.2...done.
Loaded symbols for /lib/libpthread.so.2
Reading symbols from /usr/local/lib/libicuuc.so.36...done.
Loaded symbols for /usr/local/lib/libicuuc.so.36
Reading symbols from /usr/local/lib/libicudata.so.36...done.
Loaded symbols for /usr/local/lib/libicudata.so.36
Reading symbols from /lib/libm.so.4...done.
Loaded symbols for /lib/libm.so.4
Reading symbols from /lib/libcrypt.so.3...done.
Loaded symbols for /lib/libcrypt.so.3
Reading symbols from /lib/libutil.so.5...done.
Loaded symbols for /lib/libutil.so.5
Reading symbols from /usr/local/lib/libgmp.so.7...done.
Loaded symbols for /usr/local/lib/libgmp.so.7
Reading symbols from /lib/libreadline.so.6...done.
Loaded symbols for /lib/libreadline.so.6
Reading symbols from /usr/lib/libstdc++.so.5...done.
Loaded symbols for /usr/lib/libstdc++.so.5
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/libncurses.so.6...done.
Loaded symbols for /lib/libncurses.so.6
Reading symbols from /libexec/ld-elf.so.1...done.
Loaded symbols for /libexec/ld-elf.so.1
#0  0x000800c0589c in pthread_testcancel () from 
/lib/libpthread.so.2

[New Thread 0x8cbc00 (runnable)]
[New Thread 0x8cb800 (sleeping)]
[New Thread 0x8cb400 (LWP 100057)]
[New Thread 0x512000 (runnable)]
[New LWP 100086]
(gdb) bt
#0  0x000800c0589c in pthread_testcancel () from 
/lib/libpthread.so.2

#1  0x000800bf4100 in sigaction () from /lib/libpthread.so.2
#2  0x000800bfe09a in pthread_mutexattr_init () from 
/lib/libpthread.so.2

#3  0x in ?? ()
Cannot access memory at address 0x7fbff000
(gdb) quit
[freebsd:~/parrot] jisom% gdb parrot
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and 
you are
welcome to change it and/or 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.

This GDB was configured as "amd64-marcel-freebsd"...
(gdb) run t/compilers/pge/p5regex/p5rx.t
Starting program: /usr/home/jisom/parrot/parrot 
t/compilers/pge/p5regex/p5rx.t
warning: Unable to get location for thread creation breakpoint: generic 
error

[New LWP 100086]
1..960
ok 1 -

Re: Is Parrot 1.0 too late?

[Allison Randal]

Nikolay,

Here's a few things you (and others) can do:

- give a talk about Parrot at your local linux/ruby/python/php/perl/etc 
user group (recruiting new developers, and raising general awareness), 
show working code


- contribute a patch (accelerating our path to the 1.0 release)

- document a feature (making it easier for new users/developers to get 
involved)



This list isn't really the right place to talk about the "business" side 
of the project, but we have good connections with significant companies 
who who have an eye on Parrot. They can't do anything until we ship a 
production (or at least beta) release, though. 1.0 is our top priority 
right now, as soon as possible.


Allison

CPS reading list

[Allison Randal]

whorf wrote:

Parrot moves beyond the fragile stack-based control flow common to
virtual machines today, to a continuation-based control flow. (I can
recommend a few good books and articles if you're curious.)

Could you recommend the books and articles for the curious.


I've had quite a few requests for this. Here's a good start:

- "Continuations and advanced flow control" by Jonathan Bartlett, 



- "Compiling with Continuations" by Andrew W. Appel, Cambridge 
University Press


- "A Dynamic Continuation-Passing Style for Dynamic Delimited 
Continuations" by Dariusz Biernacki, Olivier Danvy, Kevin Millikin, 



- "Representing Control, A Study of the CPS Transformation Mathematical 
Structures" by Olivier Danvy and Andrzej Filinski, Computer Science 
2(4):361-391


- "A Correspondence between Continuation Passing Style and Static Single 
Assignment Form" by Richard A. Kelsey, ACM SIGPLAN Notices 30 (3): 13-22.


- "The Scheme Programming Language" 3rd ed. by Kent Dybvig (chapter 3, 
particularly section 3.4), The MIT Press. Also 



Allison

[perl #42795] [PATCH] NULL function pointer should be a pointer

[Matt Diephouse via RT]

Applied in r18355. Thanks!

--
Matt Diephouse

[perl #41168] graceful "no compiler" error message?

[James Keenan via RT]

A participant in this weekend's hackathon in Toronto posed this question:

"Invoking the compiler on a simple source file, then checking that the
generated code exists seems such an obvious test that there must be a
fatal flaw in it. What am I missing?"