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

Thanks, 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/

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bram Geron wrote: > The patch in 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

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

-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 fixes the problem for me. >> I realized that contexts currently initially h

Re: parrot question and stacked patches

you can call it like this: char *file; int line; if (Parrot_offs_get_info(interp, offs, interp->code, &file, &line) { string_cstring_free(file); } else { } I think it would be good if the patch were applied. 0:) Thanks, -- Bram Geron | GPG 0xE7B9E65E --- a/src

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

from another GC bug. Thanks for checking my patch. -- Bram Geron | GPG 0xE7B9E65E

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

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 hol

stack tracing (was: PMC/GC help needed)

eas() If we can't rely 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

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

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 w

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

collect the from_ctx. This means that if some context was kept live only with from_ctx, it would be marked 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 #42790] [BUG] Tailcall with slurpy argument passing causes a memory leak

k 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->to_ctx, but in a tail call it isn't, causing DOD to mark registers in the context dead and setting their vtable to 0x

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

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 call

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

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 gues

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

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: