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

[James Keenan via RT]

Bram, chromatic:

There's been no activity in this thread since last August.  Can you give
us an update on the issues at hand?

Thank you very much.
kid51

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

[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 Geron

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

[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 out the name of the sub) we may segfault,
 because the Parrot_sub structure is already freed.
 
 That's definitely a problem, but I hate to disable tracing.
The tracing is turned off during interpreter destruction, I reckoned
that it's not necessary any more by then. All structures are going to
die anyway.

 This patch is slightly less invasive; does it solve the problem
 anyway?
No. doomed-name seems to be (STRING *) 0x0 in my test case. What would
work in my case is something like this,

 fprintf(stderr, [free  ctx %p of sub '%s']\n,
 (void *)ctxp,
-(doomed-name == (void*)0xdeadbeef
+(doomed-name == (void*) 0
+ || doomed-name == (void*)0xdeadbeef
  ? ???
  : (char*)doomed-name-strstart));
 }

but the Parrot_sub structure seems quite messed up:

   {seg = 0x81d0028, start_offs = 3735928559, end_offs = 524288,
HLL_id = -559038737, namespace_name = 0x81d00d0,
namespace_stash = 0xdeadbeef, name = 0x0, vtable_index = -559038737,
multi_signature = 0x200, n_regs_used = {134722656, 136118504, 0, 1},
lex_info = 0xdeadbeef, outer_sub = 0x45400600, eval_pmc = 0x8315728,
ctx = 0x81d0100, comp_flags = 136218632, outer_ctx = 0x1}

Of these fields, [start_offs, HLL_id, namespace_stash, vtable_index,
lex_info] are 0xdeadbeef. I'd say the other fields are pretty unreliable
too. Who knows what might be in doomed-name next time?

In another test case, Parrot didn't crash. Maybe doomed-name-strstart
pointed to destroyed buffer memory, because it outputted all funny
chars. (tail:
http://vuurtje.dazjorz.com/~brammo/debug_ctx_destroy_during_cleanup.png)

The funny chars haven't been a problem, so I'd be happy with either
solution.

chromatic's patch:
 === src/gc/register.c
 ==
 --- src/gc/register.c (revision 5201)
 +++ src/gc/register.c (local)
 @@ -498,7 +498,7 @@

  fprintf(stderr, [free  ctx %p of sub '%s']\n,
  (void *)ctxp,
 -(doomed-name == (void*)0xdeadbeef
 +(doomed  doomed-name == (void*)0xdeadbeef
   ? ???
   : (char*)doomed-name-strstart));
  }

-- 
Bram Geron | GPG 0xE7B9E65E

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

[chromatic]

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
 out the name of the sub) we may segfault, because the Parrot_sub
 structure is already freed.

That's definitely a problem, but I hate to disable tracing.  This patch is 
slightly less invasive; does it solve the problem anyway?

-- c

=== src/gc/register.c
==
--- src/gc/register.c	(revision 5201)
+++ src/gc/register.c	(local)
@@ -498,7 +498,7 @@
 
 fprintf(stderr, [free  ctx %p of sub '%s']\n,
 (void *)ctxp,
-(doomed-name == (void*)0xdeadbeef
+(doomed  doomed-name == (void*)0xdeadbeef
  ? ???
  : (char*)doomed-name-strstart));
 }

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

[via RT]

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


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
out the name of the sub) we may segfault, because the Parrot_sub
structure is already freed.

This patch fixes the segfault by turning off -D80 just before
force-freeing all PObjs.

 inter_create.c |8 
 1 file changed, 8 insertions(+)

This patch is unified after applying the patch from bug #44351. You
probably want to apply that first, or you will get warnings from patch(1).

-- 
Bram Geron | GPG 0xE7B9E65E




diff --git a/src/inter_create.c b/src/inter_create.c
index 307fa71..6a6c4aa 100644
--- a/src/inter_create.c
+++ b/src/inter_create.c
@@ -315,6 +315,14 @@ Parrot_really_destroy(PARROT_INTERP, SHIM(int exit_code), SHIM(void *arg))
 interp-arena_base-DOD_block_level =
 interp-arena_base-GC_block_level = 0;
 
+if (Interp_debug_TEST(interp, PARROT_CTX_DESTROY_DEBUG_FLAG)) {
+PIO_eprintf(interp, We are about to exit and force-free subs, so turning off -D%x. It might\n
+generate segfaults when we destroy a context of which the sub is already\n
+dead.\n,
+PARROT_CTX_DESTROY_DEBUG_FLAG);
+Interp_debug_CLEAR(interp, PARROT_CTX_DESTROY_DEBUG_FLAG);
+}
+
 if (Interp_trace_TEST(interp, ~0)) {
 PIO_eprintf(interp, ParrotIO objects (like stdout and stderr) are about to be closed, so clearing trace flags.\n);
 Interp_trace_CLEAR(interp, ~0);