Simon Glover <[EMAIL PROTECTED]> writes: > On Tue, 1 Jul 2003, Dan Sugalski wrote: > > > This dies on 9 tests on OS X, and I think from the complaints that > > valgrind will also be very unhappy, but I'm putting it in so it can > > be thumped by other folks as well as me. > > I think I might have figured out why valgrind's unhappy. We're > currently marking the ParrotIO PMC as needing active destruction, > so as to ensure that PIO_close gets called when the PMC gets garbage > collected. However, as far as I can see there's nothing to stop this > from happening even after we've called PIO_close explicitly ourselves, > so we can end up trying to free the same io structure twice. > > Does this make sense?
Finally I got valgrind running. I took a deeper look and Simons description of the error is correct. In the attached patch I solved this by active clearing the PMC_data and checking for this condition in the destroy-function. This solves the double free problem. 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. Valgrind was complaining about some conditional jumps based on uninitialized memory. After a long debugging session I found the offending code: In trace_system_areas the variable env is not initialised, and in this area was a pointer to the File from a previous call. So the garbage-collector marked the File as live. My changes in the IO-subsystem did not introduce this bug, but only uncovered it. I thinks this kind of bug will bite us more often. 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
