> kovert> > Didn't it help enough to make tmp_win->HiliteImage NULL? > kovert> > kovert> no. It still ended up freeing memory that was already freed. > kovert> I'm not quite clear on where it got the value from to pass in > kovert> after setting it to NULL. > > Wait, so you're saying that after you set it to NULL, some other > value is placed there?
yes, though it appears that the TwmWindow structure is still valid (it may be in unallocated but not yet reused memory; I haven't run it through a purify-like tool). > Aha, I think I know why. In events.c, HandleDestroyNotify doesn't > set Tmp_win to NULL, which means that the next call to it will try to > delete whatever it points at. In the mean time, that are of memory > has most likely been reallocated, making Tmp_win point at apparently > bogus data, most probably leading to a crash! So it's quite likely > that the following patch fixes this problem. Can you verify that > (remove your #id 0 and #endif)? unfortunately, the patch didn't fix it. The problem still materializes under the same circumstances with the same weirdness in gdb. -Todd
