Re: [perl #44363] [PATCH] -D80 + bad luck = segfault

2008-03-16 Thread Bram Geron
James Keenan via RT wrote: There's been no activity in this thread since last August. Can you give us an update on the issues at hand? I haven't got the problem in a while, so I think it's disappeared. I haven't watched the list closely enough to say why, but I guess it's over. Cheers, Bram

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

2007-10-21 Thread Bram Geron
, -- Bram Geron | GPG 0xE7B9E65E diff --git a/src/sub.c b/src/sub.c index bde6b3b..17461c4 100644 --- a/src/sub.c +++ b/src/sub.c @@ -58,6 +58,8 @@ mark_context(PARROT_INTERP, NOTNULL(parrot_context_t* ctx)) obj = (PObj*)ctx-current_cont; if (obj !PObj_live_TEST(obj

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

2007-10-21 Thread Bram Geron
chromatic wrote: On Sunday 21 October 2007 07:57:58 Bram Geron wrote: Attached patch fixes the segfault for me. (And no memory leak too.) The problem was that mark_context didn't mark ctx-caller_ctx, which is used in get_params. Usually the caller context is accessible through current_cont

Re: [perl #45695] [PATCH] Remove seemingly unnecessary Parrot_cont-from_ctx

2007-09-25 Thread Bram Geron
dead on the next gc run. And since that didn't produce bugs, we can also assume that from_ctx is redundant. -- Bram Geron | GPG 0xE7B9E65E

Re: [perl #44363] [PATCH] -D80 + bad luck = segfault

2007-08-05 Thread Bram Geron
chromatic via RT wrote: On Friday 03 August 2007 05:15:33 Bram Geron wrote: At Parrot exit, we force-destroy all PObjs. It can happen that a context is destroyed after its sub is destroyed. Usually that's not a problem, but if you run with -D80 (show when contexts are destroyed, and print

stack tracing (was: PMC/GC help needed)

2007-07-31 Thread Bram Geron
on trace_system_areas to mark C variables, why have it in the first place? It probably only obscures bugs on other platforms, making it harder to port. leo -- Bram Geron | GPG 0xE7B9E65E

[perl #43462] [PATCH] some clearups, illegal memory accessing

2007-07-02 Thread Bram Geron
. -- Bram Geron | GPG 0xE7B9E65E

Re: [perl #43462] [PATCH] some clearups, illegal memory accessing

2007-07-02 Thread Bram Geron
Bob Rogers via RT wrote: From: Bram Geron [EMAIL PROTECTED] Date: Mon, 02 Jul 2007 23:19:39 +0200 I'm sorry -- I wrongly assumed that marking a context doesn't mark its current_sub, but it does. I thought it wasn't necessary (lexpad holds all the info we'd need). The segfault

Re: parrot question and stacked patches

2007-06-30 Thread Bram Geron
(interp, offs, interp-code, file, line) { here, file and line are set correctly. string_cstring_free(file); } else { we get here if we can't retrieve file:line. } I think it would be good if the patch were applied. 0:) Thanks, -- Bram Geron | GPG 0xE7B9E65E --- a/src/sub.c

Re: [perl #43006] Tail call force-frees current context

2007-06-09 Thread Bram Geron
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 (sorry for the late reply) Leopold Toetsch wrote: Am Sonntag, 20. Mai 2007 21:51 schrieb Bram Geron: Bram Geron wrote: The patch in parrot.solution1.patch fixes the problem for me. I realized that contexts currently initially have a ref_count

Re: [perl #43006] Tail call force-frees current context

2007-05-20 Thread Bram Geron
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bram Geron wrote: The patch in parrot.solution1.patch fixes the problem for me. I realized that contexts currently initially have a ref_count of 0, if they're not used as :outer targets for other subs. So in 'normal' situations, the caller's

[perl #41583] [PATCH] Tail calls from within vtable methods broken

2007-05-07 Thread Bram Geron
, Bram Geron diffstat: include/parrot/interpreter.h |5 +- include/parrot/register.h|6 +- src/gc/register.c| 43 src/inter_call.c |2 src/inter_run.c | 89 +-- src/ops/core.ops

[perl #32667] [PATCH] IMCC - documentation needs updating

2007-01-16 Thread Bram Geron via RT
Attached patch adds new syntax documentation to docs/imcc/syntax.pod and fixes some typos there. It now also indicates where various flags are explained. Is the shorthand syntax for function calls (($P0, a :slurpy) = foo(3, b :flat)) clear, or can we better use examples there? -- bgeron Index: