Leopold Toetsch <[EMAIL PROTECTED]> writes: > Juergen Boemmels <[EMAIL PROTECTED]> wrote: > > But in t/pmc/io_2.pasm is a more nasty problem. The sweep 0 call does > > (sometimes) not trigger the destruction of the PMC containing the > > IO-Object, even though it is not connected to the root-set. > > > In trace_system_areas the variable env is not initialised, and in this > > area was a pointer to the File from a previous call. > > Shouldn't the setjmp(3) call fill the C<jmp_buf env> variable? Anyway, > if C<env> isn't filled totally, we would have the observed behavior. > But ...
This was also my first thought. But only a part of the structure is actually filled. Took me some time in the debugger to find this out. > > ... So the > > garbage-collector marked the File as live. > > ... we still have a *big* problem here. During marking the system area, > we might always detect stale objects and mark them live. This isn't a > problem for plain objects, but objects that need timely destruction will > not get destroyed properly. And whats even worse, these kind of bugs can be triggered by completele unrelated code. A little change in the call-chain and *bang*. > And valgrind still does report unitialized memory on the stack. Strange. I was sure they were gone when I tested it. Anyway there are more errors like this: t/op/interp_1.pasm and t/op/gc_1.t are the ones I know of. We will have much fun with bugs like this. bye boe -- Juergen Boemmels [EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
