Bill Pringlemeir wrote: > On 17 Feb 2005, [EMAIL PROTECTED] wrote: > I have four passive > sessions running with auto-downloads in two of them. It doesn't seem > to matter which one I clear.
Ok, I've never ever used auto-downloads. I gave it a quick try but didn't have a crash so far. > unref_record in search.c always seems to be in the trace. So I set a > break point there and then did the clear. When it hit, the break > point I ran a back trace. As soon as I continued, I got a SEGV. I > had done this before and had to continue several times. Perhaps there > is a small probability of it happening for each record cleared? unref_record() is called everytime a search result is removed from the GUI - that is clear, close, delete, download trigger this. > Anyways does this first trace look corrupt? If so, what higher level > function might I break on first? [...] > #13 0x401bb8cb in gtk_tree_path_new_first () from /usr/lib/libgtk-x11-2.0.so.0 > #14 0x08ed9be0 in ?? () > (gdb) c > Continuing. > [WJP: why didn't that trace back to main?] It took me a while to figure out what WJP means. > Program received signal SIGSEGV, Segmentation fault. > 0x08137e61 in search_gui_hash_func (rc=0xae80e08) at search_common.c:363 > (gdb) bt > #0 0x08137e61 in search_gui_hash_func (rc=0xae80e08) at search_common.c:363 > #1 0x404102a4 in g_hash_table_lookup () from /usr/lib/libglib-2.0.so.0 > #2 0x6cdc6044 in ?? () > #3 0x08ed9be0 in ?? () > #4 0x08ed9be0 in ?? () > #5 0x4028ae40 in ?? () from /usr/lib/libgtk-x11-2.0.so.0 > #6 0x08ed9be0 in ?? () > #7 0x08ed9be0 in ?? () > #8 0xbfffe678 in ?? () > #9 0x0816011d in unref_record (model=0x0, path=0xc45c700, iter=0x8, > data=0x45c70000) at search.c:135 > Previous frame inner to this frame (corrupt stack?) > (gdb) I can reproduce such "looking broken" stack traces by pressing Control-C without having any crash at all as well at least with the GCC-SSP compiled executable. I guess that's really just an effect of SSP and/or optimization. Actually, mine looked weirder showing 0x00000c and similar addresses. The "??" may just be symbols with no debug information assigned to them. > Could it also be the Mandrake GTK2? That would be highly appreciated. [400 years later...] Well, I just added some magic to record_t and it's obvious that free'd records are being accessed. I could reproduce an assertion failure when closing a passive search. -- Christian
pgpbudvuuOdwA.pgp
Description: PGP signature
