From: Bram Geron (via RT) <[EMAIL PROTECTED]> Date: Sun, 01 Jul 2007 03:53:50 -0700
# New Ticket Created by Bram Geron # Please include the string: [perl #43462] # in the subject line of all future correspondence about this issue. # <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=43462 > . . . Secondly, I discovered that when you're using -D80, Parrot_free_context prints out the name of the 'sub' that the context was made for. I think we can't rely on the sub being there, as this example will show: - Create closure A over main. - Invoke closure A, creating context B. - Create closure C over closure A, storing a ref to context B (but not to closure A). Store it in a global var maybe. - Exit closure A. There is one less reference to context B. - Empty the global var holding closure C. - Free closure C. Now context B can be freed too: [free ctx 0x12345678 of sub '<accessing freed memory here>'] I got a segfault for it, but my test case is too large to attach and I think it will be hard to get the size down. It isn't very legible anyway. I think you will have to send me your test case, or at least a more detailed recipe. I do not see how the above sequence of events can lead to a dangling reference to a deleted sub -- unless there is also a GC bug, in which case I am unlikely to be able to reproduce the problem from just a description. If this is really a GC problem, then you may be able to get your test case smaller by inserting "sweep 1" shortly before the point that it fails. HTH, -- Bob
