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
>> The pointer iter looks like ascii data to me. I am not familiar >> with GDB, but looking at this memory might be helpful. The text >> around this location is "CEBEARUPCDUBFoX". > That looks like GGEP data but it doesn't really indicate anything > beyond this being an already recycled memory chunk. 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. It is where parameters iter is stored on the stack from the caller. This is over-run data that is causing some problem (either that or the stack back trace is messed up; quite likely). 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. I guess you will try a passive with GTK1? thx, Bill Pringlemeir. ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Gtk-gnutella-devel mailing list Gtk-gnutella-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel
