Vladimir Lipsky [EMAIL PROTECTED] wrote:
Some time ago I mentioned I'd been gettin' one more segfault while the
Parrot debug mode was on. In fact, it proved to be an effect of the
same cause -- we have global resources sharable among interpreters,
that we try to free more than once. This time
From: Leopold Toetsch [EMAIL PROTECTED]
Did you recheck that after my fix to vtable freeing? My patch covered
encoding and chartype too.
No, I didn't. Did you fix the Parrot_loadbc function name? If didn't, I'll
have a go for Parrot_set_PackFile()
leo
0x4C56
Happy
.~.
Some time ago I mentioned I'd been gettin' one more segfault while the
Parrot
debug mode was on. In fact, it proved to be an effect of the same cause --
we
have global resources sharable among interpreters, that we try to free more
than
once. This time it's encoding_array. If you're going to
Dan Sugalski [EMAIL PROTECTED] wrote:
Well, bah. I'll disable the table freeing for now and that should
take care of the bug at the moment, though it certainly won't cure
the underlying memory leak.
The bug is already fixed. But we have to separate interpreter globals
and real globals
From: Leopold Toetsch [EMAIL PROTECTED]
Sent: Wednesday, December 03, 2003 12:05 PM
The bug is already fixed. But we have to separate interpreter globals
and real globals finally. Some time ago, I suggested to change the init
functions slightly to take a parent interpreter argument:
Do you
From: Dan Sugalski [EMAIL PROTECTED]
Sent: Tuesday, December 02, 2003 5:27 PM
Well, bah. I'll disable the table freeing for now and that should
take care of the bug at the moment, though it certainly won't cure
the underlying memory leak.
Arguably, and this is getting into the realm of
Vladimir Lipsky [EMAIL PROTECTED] wrote:
From: Leopold Toetsch [EMAIL PROTECTED]
Sent: Wednesday, December 03, 2003 12:05 PM
The bug is already fixed. But we have to separate interpreter globals
and real globals finally. Some time ago, I suggested to change the init
functions slightly to
At 1:52 AM +0300 12/2/03, Vladimir Lipsky wrote:
I'm done with it for now and I'm not the dan to say which way is the parrot
way to fix this bug
Well, bah. I'll disable the table freeing for now and that should
take care of the bug at the moment, though it certainly won't cure
the underlying
From: Leopold Toetsch [EMAIL PROTECTED]
Sent: Thursday, November 27, 2003 12:04 PM
PMC (in gdb speak):
b dod.c:525
r t/pmc/pmc_61.pasm
p *(PMC *) b
p *((PMC *) b)-vtable
c
...
Umm .. the problem is that this pmc doesn't have the vtable;
(*((PMC *)b)).vtable points to a block
Vladimir Lipsky [EMAIL PROTECTED] wrote:
Umm .. the problem is that this pmc doesn't have the vtable;
(*((PMC *)b)).vtable points to a block of memory which belonged
to the child interpreter's pool and has already been freed, I deduce
from examining the adresses. So it ends up with Access
more clear, I'll just simplify the code of test 61 and only extract the
problematic place.
new P0, .ParrotInterpreter
end
At the current time being, the above code ends up with the segfault on
Win32.
When I refered to a child interpreter, I meant the interpreter being
created by the new opcode.
Now
Vladimir Lipsky [EMAIL PROTECTED] wrote:
Well, currently, test 61 in t/pmc/pmc.t causes an abrupt stop of
the test session with the segfault box popping up.
if (PObj_active_destroy_TEST(b))
VTABLE_destroy(interpreter, (PMC *)b);
Well, currently, test 61 in t/pmc/pmc.t causes an abrupt stop of
the test session with the segfault box popping up. I haven't yet
taken a time to figure out what actually is the cause of trouble,
but I've already detected the precise place where that all happens.
It happens here
void
13 matches
Mail list logo
