On Mon, 2 Feb 2009, Andrew Whitworth via RT wrote:
> On Sat Oct 06 05:46:09 2007, pcoch wrote:
> > In src/gc/register.c:clear_regs() there is the todo item:
> >
> > /* depending on -D40 we set int, num to garbage different garbage
> > * TODO remove this cod
Author: Whiteknight
Date: Wed Jan 14 16:44:41 2009
New Revision: 35571
Modified:
trunk/docs/pdds/pdd09_gc.pod
Changes in other areas also in this revision:
Modified:
trunk/include/parrot/pobj.h
trunk/src/gc/generational_ms.c
trunk/src/inter_call.c
trunk/src/pmc/deleg_pmc.pmc
Log
/include/parrot/gc_mark_sweep.h
- copied unchanged from r35374,
/branches/pdd09gc_part2/include/parrot/gc_mark_sweep.h
trunk/include/parrot/gc_pools.h
- copied unchanged from r35374,
/branches/pdd09gc_part2/include/parrot/gc_pools.h
trunk/src/gc/api.c
- copied unchanged from
Why is this test labelled [Perl] rather than [PIR]?
On Monday 27 October 2008 18:18:26 Will Coleda wrote:
> Attached is a PIR-only file (no tcl required) that triggers the same
> GC-related segfault (tested in r32210)
Fixed in r32229. The problem is that retrieving the STRING value of a String
Key returned that STRING directly. Modifyi
On Mon, Oct 27, 2008 at 9:31 AM, Will Coleda <[EMAIL PROTECTED]> wrote:
> On Sun, Oct 26, 2008 at 11:17 AM, Will Coleda <[EMAIL PROTECTED]> wrote:
> Here is a very small snippet of tcl
Attached is a PIR-only file (no tcl required) that triggers the same
GC-related segfault
On Sun, Oct 26, 2008 at 11:17 AM, Will Coleda <[EMAIL PROTECTED]> wrote:
> Turns out setting the conditional breakpoint never fired; left this
> running overnight, and it eventually came back with the segfault
> directly. Back to the drawing board.
Here is a very small snippet of tcl (with a singl
On Sun, Oct 26, 2008 at 2:00 AM, via RT Will Coleda
<[EMAIL PROTECTED]> wrote:
> # New Ticket Created by Will Coleda
> # Please include the string: [perl #60128]
> # in the subject line of all future correspondence about this issue.
> # http://rt.perl.org/rt3/Ticket/Display.html?id=60128 >
>
>
>
# New Ticket Created by Will Coleda
# Please include the string: [perl #60128]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=60128 >
Trying to track down a segfault that is occurring for me in parrot
(triggered by partcl):
On Mon Mar 03 15:11:25 2008, rgrjr wrote:
>From: Bob Rogers <[EMAIL PROTECTED]>
>Date: Sun, 2 Mar 2008 11:28:08 -0500
>
>. . . if I revert string.pmc in r26175 (the one experiment I didn't
>bother trying), it does in fact work . . .
>
> And I notice that RT#50040 also no longer fa
Does this still fail? If not, we can close this ticket.
--
Andrew Whitworth
a.k.a Whiteknight
I believe chromatic resolved this in a spate of GC hackery last spring.
I'm not sure exactly when, but I haven't been bothered by it in a while.
-- Bob Rogers
http://rgrjr.dyndns.org/
On Sat Oct 13 11:14:42 2007, pcoch wrote:
> In src/exit.c:Parrot_exit() there is the todo item (with some context):
>
> /* call all the exit handlers */
>
> TODO reset stacktop or better disable GC
>
> Make a decision as to which is better to do; reset stacktop or
Andrew Whitworth wrote:
I created a new branch tonight, /branches/pdd09gc to try to continue
some of my GC work from the summer with a blank slate. I have a few
cleanup jobs I want to do first, so that it should be easier to add in
a new GC without having so many problems as I had. One thing
On Mon, Jun 2, 2008 at 7:18 PM, chromatic <[EMAIL PROTECTED]> wrote:
> I like the general idea, but I wonder if there's something cleaner than an
> environment variable. Nothing really comes to mind at the moment besides
> making argument processing even uglier in IMCC's main.c.
>
> Let's think a
I created a new branch tonight, /branches/pdd09gc to try to continue
some of my GC work from the summer with a blank slate. I have a few
cleanup jobs I want to do first, so that it should be easier to add in
a new GC without having so many problems as I had. One thing I've
wanted to do
On Mon, Aug 4, 2008 at 7:36 PM, Andrew Whitworth <[EMAIL PROTECTED]> wrote:
> I edited PDD09 tonight to try and add some details and some
> clarification on points that weren't particularly clear before. I have
> a few questions that need answering before I can do more:
>
> 1) GC_trace_normal and G
On Monday 04 August 2008 16:36:15 Andrew Whitworth wrote:
> I edited PDD09 tonight to try and add some details and some
> clarification on points that weren't particularly clear before. I have
> a few questions that need answering before I can do more:
>
> 1) GC_trace_normal and GC_trace_stack_FLA
I edited PDD09 tonight to try and add some details and some
clarification on points that weren't particularly clear before. I have
a few questions that need answering before I can do more:
1) GC_trace_normal and GC_trace_stack_FLAG are defined exactly the
same. However, GC_trace_normal is never us
On Monday 21 July 2008 18:38:55 [EMAIL PROTECTED] wrote:
> --- branches/gsoc_pdd09/src/gc/gc_it.c (original)
> +++ branches/gsoc_pdd09/src/gc/gc_it.c Mon Jul 21 18:38:55 2008
> @@ -239,6 +239,11 @@
> {
> const Arenas * const arena_base = interp->arena_base;
>
On Sunday 13 July 2008 17:55:59 [EMAIL PROTECTED] wrote:
> Modified:
>branches/gsoc_pdd09/src/gc/gc_it.c
>
> Log:
> [gsoc_pdd09] Stop sweeping const_PMC pools for now (causes weird error).
> Added a note about this.
>
> Modified: branches/g
On Tue May 06 17:41:43 2008, coke wrote:
> On Fri Aug 03 13:43:42 2007, [EMAIL PROTECTED] wrote:
> > On Friday 03 August 2007 13:29:53 Jerry Gay wrote:
> >
> > > i'm having trouble on x86_64. when running a 32bit parrot, i get
> > > occasional deadlock at the OS level, after Parrot_exit. when runn
I took another long look at this branch, and see nothing here that is
salvageable for current use. I have deleted the branch as of r28915.
--Andrew Whitworth
On Monday 30 June 2008 14:53:17 [EMAIL PROTECTED] wrote:
> Modified:
>branches/gsoc_pdd09/include/parrot/smallobject.h
>branches/gsoc_pdd09/src/gc/gc_it.c
>branches/gsoc_pdd09/src/gc/memory.c
>branches/gsoc_pdd09/src/headers.c
>
> Log:
> [gsoc_pdd09] add a
Hi Coke, Andrew, Chromatic,
I have not considered this branch as a candidate for research on the Parrot
GC, but had a look @ it. As it seems, it wouldn't be of much use as its
*quite* old.
Regards,
Senaka
On Sat, Jun 28, 2008 at 1:19 AM, Will Coleda via RT <
[EMAIL PROTECTED]> wrote
y. One of the branches that remains is
> >> the 'gcm' branch, created by "heimdall" and last updated
> >> on 2005-09-13. Supposedly this is an implementation of
> >> a generational gc algorithm for Parrot.
> >>
> >> Although it m
On Tuesday 17 June 2008 15:01:43 [EMAIL PROTECTED] wrote:
> Log:
> [src/gc] Add some basic function-level documentation to src/gc/memory.c as
> per RT#48260. More is needed, but I've covered the basics.
Excellent.
One thing most people don't notice -- neither criticism nor c
/include/parrot/dod.h
trunk/include/parrot/oo.h
trunk/include/parrot/resources.h
trunk/languages/dotnet/pmc/dotnetassembly.pmc
trunk/languages/lua/src/pmc/lua.pmc
trunk/languages/lua/src/pmc/luatable.pmc
trunk/src/dynext.c
trunk/src/exit.c
trunk/src/gc/dod.c
trunk/src/gc
On Thursday 12 June 2008 07:23:30 Andrew Whitworth via RT wrote:
> I've been testing this patch locally for about a week and there are no
> issues with it. If nobody has any questions/comments/objections I'd like
> to apply it later today. Anybody?
+1
-- c
On Thu Jun 05 15:44:05 2008, Whiteknight wrote:
> PDD09 contained a number of deprecation notes, for functions and
> macros whose names are to be updated. The attached patch makes these
> changes globally, including in PDD09 and other documentation. The
> following macros and functions are renamed:
ranch, created by "heimdall" and last updated
>> on 2005-09-13. Supposedly this is an implementation of
>> a generational gc algorithm for Parrot.
>>
>> Although it may be a bit of work because the branch is
>> so old, it may be worthwhile to bring this br
On Monday 09 June 2008 09:33:20 [EMAIL PROTECTED] wrote:
> Modified: branches/gsoc_pdd09/src/gc/gc_it.c
> --- branches/gsoc_pdd09/src/gc/gc_it.c (original)
> +++ branches/gsoc_pdd09/src/gc/gc_it.c Mon Jun 9 09:33:19 2008
> @@ -83,6 +83,7 @@
> * 4) repeat (3) until there are n
On Thursday 05 June 2008 15:44:05 Andrew Whitworth wrote:
> Index: tools/dev/mk_language_shell.pl
> ===
> --- tools/dev/mk_language_shell.pl (revision 28110)
> +++ tools/dev/mk_language_shell.pl (working copy)
> @@ -425,7 +4
but I'll look at it much closer in the
coming week to see if I can figure it out. A few points:
* The last notes that I can find written anywhere about this indicate
that the gmc GC still has some bugs in it, although I can't find
information about how many, how severe, or how difficult t
On Tue Nov 27 14:08:00 2007, pmichaud wrote:
> Today we cleaned up a lot of the unused branches of the
> Parrot repository. One of the branches that remains is
> the 'gcm' branch, created by "heimdall" and last updated
> on 2005-09-13. Supposedly this is an imple
On Mon Jun 04 23:15:17 2007, [EMAIL PROTECTED] wrote:
> After a little prodding around, I think the problem is that the dynops
> aren't build with the rpath. I don't know how "proper" the following
> patch is(i.e. linux doesn't seem to have a problem so either this is
> right or the other way i
110)
+++ src/global.c (working copy)
@@ -765,7 +765,7 @@
PMC *ns;
/* PF structures aren't fully constructed yet */
-Parrot_block_DOD(interp);
+Parrot_block_GC_mark(interp);
/* store relative to HLL namespace */
CONTEXT(interp)->current_HLL = PMC_sub(sub)->
On Monday 02 June 2008 13:10:32 [EMAIL PROTECTED] wrote:
> +/*
> + * 2) Mark root items as grey
> + * I don't currently know how to determine which items are root. However,
> + * When we find them, we can mark them
> + */
The existing GC systems all start with interp->ig
On Monday 02 June 2008 07:58:57 NotFound wrote:
> Previous version generates a warning when building with C, fixed now.
I like the general idea, but I wonder if there's something cleaner than an
environment variable. Nothing really comes to mind at the moment besides
making argument processing
Previous version generates a warning when building with C, fixed now.
--
Salu2
Index: src/runops_cores.c
===
--- src/runops_cores.c (revisión: 28033)
+++ src/runops_cores.c (copia de trabajo)
@@ -242,13 +242,28 @@
opcode_t *
runo
After some discussion on #parrot about the slowness of the gcdebug
core with HLL programs, I've done this proof of concept patch: it
skips the gc run the first n opcodes, with n defined by setting an
environment variable.
Example of usage:
PARROT_GCDEBUG_SKIP=85000 ../../parrot --runcore=gc
I accept that, and the note helps, but I just pulled the conditional
declarations out of the block and ran make headerizer again. It put
the
headers for the conditional functions back in the headerizer block.
Yeah, I understand. I don't have a solution yet. I'll ponder.
xoxo,
Andy
--
And
On Sunday 11 May 2008 18:43:57 Andy Lester wrote:
> The sections that the headerizer rewrites are not for human
> modification. Putting preprocessor directives between HEADERIZER
> BEGIN and HEADERIZER END is the same as modifying an auto-generated
> file. As the headerizer exists now, you
On May 11, 2008, at 9:08 PM, chromatic wrote:
Perhaps you missed the invisible tags I forgot to include.
I must have.
headerizer makes the silly double-declaration problem of C more
bearable.
Thank you for writing it.
You're welcome. I'm about to finish with a "DO NOT TOUCH" message.
On Sunday 11 May 2008 18:52:17 Andy Lester wrote:
> On May 11, 2008, at 8:48 PM, chromatic wrote:
> > I'm trying to decide which I hate more, headerizer, C, or #ifdefs
> > in .c files. Ah, who am I kidding? It's the latter.
> >
> > If you add a note to headerizer to this effect (or tell me "It'
On May 11, 2008, at 8:48 PM, chromatic wrote:
I'm trying to decide which I hate more, headerizer, C, or #ifdefs
in .c files.
Ah, who am I kidding? It's the latter.
If you add a note to headerizer to this effect (or tell me "It's
already
there, you dope!") I'll fix the .c files so this wo
On Sunday 11 May 2008 18:43:57 Andy Lester wrote:
> On May 11, 2008, at 4:09 PM, chromatic wrote:
> > headerizer should *not* delete preprocessor directives. What needs
> > changing so that it doesn't mangle this code in the future?
>
> A massive reworking of how headerizer handles header files,
On May 11, 2008, at 4:09 PM, chromatic wrote:
headerizer should *not* delete preprocessor directives. What needs
changing
so that it doesn't mangle this code in the future?
A massive reworking of how headerizer handles header files, because
what you expected here is not at all how the h
On May 11, 2008, at 4:07 PM, chromatic wrote:
Log:
putting back the struct on Parrot_Context for headerizer
I prefer that headerizer does the right thing, rather than
cluttering up
functional code. What goes kablooie in the headerizer here?
Actually, it's not headerizer, but the header
On Saturday 10 May 2008 22:53:48 [EMAIL PROTECTED] wrote:
> Log:
> more headerizing, except for src/headers.c which needs Special Attention
> Modified: trunk/compilers/imcc/optimizer.c
> ===
>=== --- trunk/compilers/imcc/opti
On Saturday 10 May 2008 22:22:17 [EMAIL PROTECTED] wrote:
> Modified:
>trunk/src/gc/register.c
>
> Log:
> putting back the struct on Parrot_Context for headerizer
I prefer that headerizer does the right thing, rather than cluttering up
functional code. What goes kablooie in
On Saturday 10 May 2008 08:15:01 NotFound wrote:
> The attached patch makes explicit the assumptions about non-nullness
> in parrot_mark_hash and asserts them.
Thanks, applied as r27432.
Ideally this is unnecessary, but if it helps clear up other GC bugs, we can
fix their hash marking a
The attached patch makes explicit the assumptions about non-nullness
in parrot_mark_hash and asserts them.
--
Salu2
Index: src/hash.c
===
--- src/hash.c (revisión: 27411)
+++ src/hash.c (copia de trabajo)
@@ -299,6 +299,7 @@
=item
chromatic wrote:
[...]
These are the headerizer changes that bother me the most.
Reverted in r27414.
Allison
On Thu, May 8, 2008 at 9:55 PM, chromatic <[EMAIL PROTECTED]> wrote:
> Your null-checking patch will work, but I don't want to add more checking to
> parrot_mark_hash() right now, as it's already full of special cases. Here's
> my inclination.
Looks good to me. I see you also get rid ot the v
On Thursday 08 May 2008 11:09:52 chromatic wrote:
> That to me seems like the real problem. Did anyone experiment with using
> hash_delete?
>
> > The problem can be fixed by checking in parrot_mark_hash that the key
> > is no null before calling pobject_lives. The attached path does it.
>
> That
On Thursday 08 May 2008 04:39:57 NotFound wrote:
> Last night in #parrot particle informed of a bug in a msvc++ build. By
> his suggestion, me and others were able to reproduce it in other
> platforms by using the gcdebug core:
>
> ./parrot --runcore=gcdebug t/pmc/orderedhash_9.pasm
>
> Looks like
# New Ticket Created by NotFound
# Please include the string: [perl #53890]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=53890 >
Last night in #parrot particle informed of a bug in a msvc++ build. By
his suggestion, me an
chromatic wrote:
These are the headerizer changes that bother me the most.
Feel free to revert them.
Allison
From: "chromatic via RT" <[EMAIL PROTECTED]>
Date: Tue, 06 May 2008 12:18:19 -0700
On Saturday 23 February 2008 15:48:23 Bob Rogers wrote:
> Oops; I spoke too soon. It turns out that r26025 causes the #50040 test
> case to break again (I checked that it still worked in r26024). S
On Fri Aug 03 13:43:42 2007, [EMAIL PROTECTED] wrote:
> On Friday 03 August 2007 13:29:53 Jerry Gay wrote:
>
> > i'm having trouble on x86_64. when running a 32bit parrot, i get
> > occasional deadlock at the OS level, after Parrot_exit. when running a
> > 64bit parrot, it segfaults within Parrot_
On Tuesday 06 May 2008 12:52:35 [EMAIL PROTECTED] wrote:
> Author: allison
> Date: Tue May 6 12:52:34 2008
> New Revision: 27357
>
> Log:
> [pdd25cx]
> * Several header changes from rerunning 'make headerizer'.
>
> Modified: branches/pdd25cx/compilers/imcc/optimizer.c
> =
On Saturday 23 February 2008 15:48:23 Bob Rogers wrote:
> Oops; I spoke too soon. It turns out that r26025 causes the #50040 test
> case to break again (I checked that it still worked in r26024). So
> perhaps the change chromatic made didn't actually fix it . . .
Are you still seeing breakage?
et/Display.html?id=53344 >
>
>
> I tripped over this while working on a stacks patch. It prevents
> compilation without debugging.
>
> --- parrot-svn/src/gc/dod.c Fri Apr 25 07:55:47 2008
> +++ parrot-andy/src/gc/dod.cFri Apr 25 09:29:55 2008
> @@ -2
ion without debugging.
--- parrot-svn/src/gc/dod.c Fri Apr 25 07:55:47 2008
+++ parrot-andy/src/gc/dod.cFri Apr 25 09:29:55 2008
@@ -218,8 +218,8 @@
else if (p->pmc_ext && PMC_metadata(p))
fprintf(stderr, "GC: error obj %p (%s) has properties\n",
Test 7 crashes with a signal 11
> > (segmentation fault), on my Gentoo Linux-x86 box. This is with svn
> > r18722.
>
> Hi Mark,
>
> is this still an issue?
Test 7 still crashes with a signal 11, yes. Tested with r26715 built
with --gc=libc on a Linux-amd64 box.
Mark
just making a dummy call on it, just to make
sure it is used
Regards,
Senaka
On Tue, Apr 1, 2008 at 6:28 AM, chromatic <[EMAIL PROTECTED]> wrote:
> On Monday 31 March 2008 14:10:13 Senaka Fernando wrote:
>
> > There is a build failure when using the configure option --gc=libc.
On Monday 31 March 2008 14:10:13 Senaka Fernando wrote:
> There is a build failure when using the configure option --gc=libc. The
> attached patch solves this issue.
Thanks, applied with a corresponding header tweak as r26678.
Ultimately we're better off unifying the API so that t
# New Ticket Created by "Senaka Fernando"
# Please include the string: [perl #52332]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=52332 >
There is a build failure when using the configure option --gc=libc.
I don't see this with Windows XP, VC++ 8.0, VC++ 9.0 or MinGW GCC 3.4.2,
using Parrot r26446. All three nmake/mingw32-make test in
languages/perl6 report:
All tests successful.
Files=27, Tests=223, 37 wallclock secs ( 0.13 usr + 0.00 sys = 0.13 CPU)
Result: PASS
The GC bug is either solv
Resolved in r26278. It was an alignment problem in the parrot_string_t
struct, triggered by 'Parrot_unmake_COW', when it does a 'memcpy' of the
string's original buffer to the copy's buffer. Fixed by moving the
UINTVAL 'bufused' after the char* 'strstart'.
The problem was in the conversion of pobj_t to the new flattened
structure for PDD17. I've reverted that part of r25266 for now (in
r26254). The problem is probably an incomplete conversion, with some
parts of the code still expecting the multi-level structure. I'll work
on a more complete conversi
Alright, I set up a windows box with MSVC and ActivePerl and did a
binary search. The commit that caused the breakage is r25266, when we
updated the PMC struct. Tomorrow I'll experiment with reverting parts of
that commit.
I can't duplicate the bug on any other platform, and can't pinpoint the
bug with the info I've got. I have access to a windows box for the next
few weeks. What compiler you were using?
y clone and its ultimate destination. To
wit: it's fine to copy PMC_EXT pointers from one to the other, but as the
temporary clone will get recycled right away, it can't keep that pointer lest
the GC free the PMC_EXT structure, which the clone that people care about
expects to last as
On Monday 03 March 2008 18:26:47 Will Coleda wrote:
> Tcl is exposing another GC bug (even on feather.)
>
> build tcl, then prove t/cmd_array.t
That didn't do anything for me. Deleting the Perl boilerplate in the file and
running the test through ../../parrot tcl.pbc did.
> B
# New Ticket Created by Will Coleda
# Please include the string: [perl #51390]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=51390 >
Tcl is exposing another GC bug (even on feather.)
build tcl, then prove t/cmd_arra
From: Bob Rogers <[EMAIL PROTECTED]>
Date: Sun, 2 Mar 2008 11:28:08 -0500
. . . if I revert string.pmc in r26175 (the one experiment I didn't
bother trying), it does in fact work . . .
And I notice that RT#50040 also no longer fails in r26175. (It had been
failing in periodic recheck
From: Bob Rogers <[EMAIL PROTECTED]>
Date: Sat, 23 Feb 2008 12:44:02 -0500
From: "Peter Gibbs via RT" <[EMAIL PROTECTED]>
Date: Sat, 23 Feb 2008 07:57:13 -0800
Hi Bob
Please try revision 26025. This should be a full fix for the problem I
started working on in
From: "Peter Gibbs via RT" <[EMAIL PROTECTED]>
Date: Sat, 23 Feb 2008 07:57:13 -0800
Hi Bob
Please try revision 26025. This should be a full fix for the problem I
started working on in r25990.
Regards
Peter Gibbs
Works like a champ in r26026. Thanks heaps for the swift t
From: "chromatic via RT" <[EMAIL PROTECTED]>
Date: Sat, 23 Feb 2008 01:29:53 -0800
On Friday 22 February 2008 19:52:29 Bob Rogers wrote:
> The "[loading list.pbc]" message shows that it is dying in the
> load_bytecode op for this file. (If the bug fails to manifest, the code
>
- Original Message -
From: "Bob Rogers (via RT)" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, February 23, 2008 5:52 AM
Subject: [perl #51122] GC bug in bytecode loading (again)
To reproduce, unpack the attached tarball as follows:
copy.
On Friday 22 February 2008 19:52:29 Bob Rogers wrote:
> The "[loading list.pbc]" message shows that it is dying in the
> load_bytecode op for this file. (If the bug fails to manifest, the code
> will fail to find a *.pbc file in fairly short order.)
>
>In GDB, the backtrace from the segfault
On Wednesday 20 February 2008 08:17:11 Jerry Gay wrote:
> i don't know why i didn't try this first... possibly lulled into a
> false sense of security by chromatic and andy's recent bug squashing
> efforts? anyway, after much debugging it turns out that
> t/dynoplibs/myops.t's test 7 is failing on
# New Ticket Created by Jerry Gay
# Please include the string: [perl #51028]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=51028 >
i don't know why i didn't try this first... possibly lulled into a
false sense of security
On Tuesday 19 February 2008 10:52:07 Jerry Gay wrote:
> with pdd17pmc branch r25870, i get a segfault in pge's build:
>
> ..\..\parrot.exe
> ..\..\runtime\parrot\library\PGE\Perl6Grammar.pir
> --output=PGE\builtins_gen.pir PGE\builtins.pg
> NMAKE : fatal error U1077: '..\..\parrot.exe' : r
# New Ticket Created by Jerry Gay
# Please include the string: [perl #50996]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=50996 >
with pdd17pmc branch r25870, i get a segfault in pge's build:
..\..\parrot.exe
..\
g, though. (Did you try it after renaming
> orig-structures.pir?)
>
>My sanity is still OK (as much as it ever was), because I can believe
> that Parrot compiled under OSX could be different enough to affect GC
> bugs. (If this is grasping at straws, I don't wanna hear it.
From: "Will Coleda via RT" <[EMAIL PROTECTED]>
Date: Wed, 23 Jan 2008 18:15:43 -0800
On Sun Jan 20 19:11:26 2008, rgrjr wrote:
>The attached tarball has a test case in which one file
> (gc-debug-test.pir) loads another (structures.pir), where the secon
On Sun Jan 20 19:11:26 2008, rgrjr wrote:
>The attached tarball has a test case in which one file
> (gc-debug-test.pir) loads another (structures.pir), where the second has
> a :load sub that calls a sub defined in the first file. The bug is
> that, under what must be fairly arcan
# New Ticket Created by Bob Rogers
# Please include the string: [perl #50040]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=50040 >
The attached tarball has a test case in which one file
(gc-debug-test.pir) lo
I've launched the GC PDD out of draft. Comments and suggestions welcome.
Allison
"Scalable Locality-Conscious Multithreaded Memory Allocation"
http://people.cs.vt.edu/~scschnei/papers/ismm06.pdf
From: Bob Rogers <[EMAIL PROTECTED]>
Date: Mon, 12 Nov 2007 21:32:15 -0500
From: chromatic <[EMAIL PROTECTED]>
Date: Mon, 12 Nov 2007 13:58:51 -0800
. . .
If someone reading this (not just Bob or me) cares to write up some basic
tests and can make a failure c
On Nov 29, 2007, at 10:13 PM, Patrick R. Michaud wrote:
Also, in case it matters, I'm on x86 (32-bit) for this.
Pm
Does it still occur after `ccache -C`? Since ccache uses md5, there's
always the possibility you inadvertently discovered a collision in md5.
Might want to back up ~/.ccac
- for one seemingly obscure json test,
> >- when running Parrot with the --gc-debug core (e.g., 'make test')
> >- for revisions after 23232
> ...
> Can you provide a backtrace that shows which dereference is invalid?
#0 0xb7cbe1ef in mark_vt
On Thursday 29 November 2007 18:05:32 Patrick R.Michaud wrote:
> Yes, that subject line is correct -- I've found a bug
> that shows itself _only_
>- when I build Parrot using ccache,
>- for one seemingly obscure json test,
>- when running Parrot with the --gc-deb
f _only_
- when I build Parrot using ccache,
- for one seemingly obscure json test,
- when running Parrot with the --gc-debug core (e.g., 'make test')
- for revisions after 23232
It's very consistent, however -- I can reproduce it reliably on
my system.
Here are the de
One of the branches that remains is
the 'gcm' branch, created by "heimdall" and last updated
on 2005-09-13. Supposedly this is an implementation of
a generational gc algorithm for Parrot.
Although it may be a bit of work because the branch is
so old, it may be worthwhile to brin
On Tue Mar 13 12:44:33 2007, particle wrote:
> in order to help find some long-standing garbage collector bugs, in
> r17470 i've just disabled the -G flag on three PGE test files. see the
> content of the patch below. this may cause test failures due to a gc
> bug.
>
>
From: chromatic <[EMAIL PROTECTED]>
Date: Mon, 12 Nov 2007 13:58:51 -0800
. . .
If someone reading this (not just Bob or me) cares to write up some basic
tests and can make a failure case, I'm very happy to debug and fix the
problem. I'm out of town for a couple of days and m
1 - 100 of 646 matches
Mail list logo
