Bill Pringlemeir wrote: > On 16 Feb 2005, [EMAIL PROTECTED] wrote: > >> #9 0x0816011d in unref_record (model=0x10435055, path=0x2015241, > >> iter=0x45424543, data=0x5602c300) at search.c:135 > >> rc = (record_t *) 0x18 > >> dups = (GHashTable *) 0x58
> Sorry, the pointer address was on the stack. First I did "frame 9", > then I did "print &iter". Then I did "x /32 &iter" and then I did > 'printf "%s", &iter'. The stack address is not a malloc/heap > location. In this case, the ASCII might just be trash of a previous function call to GGEP related code but don't ask me how it got there. > So, it wasn't what was pointed at that was foobar, it was the actual > pointer. Small probability that static CGEP data has smashed the > stack. Seems more likely the values aren't correct. Yes, a smashed stack doesn't look likely at this place. > I guess you will try a passive with GTK1? I've tried to reproduce the crash with passive searches and GTK2 but had no success at all. GTKG ran perfectly fine for 9 hrs in UP mode. However, after opening 20 passive searches the GUI became so horribly unresponsive that I shut it down forcefully. In a short session I had a like-wise weird crash (hadn't any crashes for quite a while now) where the passed-through pointer suddenly changed from one frame to another. I'm not sure whether the output of gdb wasn't just junk. So in both cases the symptoms indicate a smashed stack but that seems rather unlikely here, IMO. Thus, Purify would come in quite handy as I don't really have an idea where to start looking at all. -- Christian
pgpyHusStv2t3.pgp
Description: PGP signature
