Re: gaim segfault while blocking someone

[Erik Wikström <erik-wikstrom@xxxxxxxxx>]

On 2006-08-29 14:28, Petr Janda wrote:
> Here is the gdb backtrace:
>
> (gdb) backtrace
> #0  0x28a109b8 in kill () from /usr/lib/libc.so.6
> #1  0x28a658e8 in abort () from /usr/lib/libc.so.6
> #2  0x28a2f4c7 in reallocf () from /usr/lib/libc.so.6
> #3  0x28a2f507 in reallocf () from /usr/lib/libc.so.6
> #4  0x28a30ad1 in reallocf () from /usr/lib/libc.so.6
> #5  0x28a308a6 in reallocf () from /usr/lib/libc.so.6
> #6  0x28a3140c in free () from /usr/lib/libc.so.6
> #7  0x2885a1b0 in g_free () from /usr/pkg/lib/libglib-2.0.so.0
> #8  0x0808722d in gaim_privacy_permit_remove ()
> #9  0x28e9d8a0 in msn_got_lst_user (session=0x290a5880, user=0x2919cc40, 
> list_op=13, group_ids=0x29032de8) at userlist.c:380

I'm sure that there's someone better at gdb who might give you a better 
answer but here I would (in gdb) type "frame 8" to make the last stack- 
frame not in glib the active one and then type "list" which ought to 
print the part of the code that calls g_free, preferably with a name of 
the source-file and a line-number. Then I would probably take a look at 
that source-file and see if something looked obviously wrong.

Unfortunately things are seldom that simple so one would have to follow 
the stack trace backwards and watch the value of the pointer that is 
being freed and try to find a place where it's changed in a wrong way. 
You might have more luck getting in touch with the gaim developers.

--
Erik Wikström