At Sun, 15 Dec 2002 05:51:42 +0200 (EET),
Martin--b�ric Racine wrote:
> > > From this report, you also got another report's tracking number, where I include
> > > a gdb trace (sylpheed). At least bother reading it, before saying that I did
> > > not include anything to justify this.
> >
> > Did you mean #110091? The reason I ignored it is that the original report
> > mixes the issue with libc6 2.2.x and libc6 2.3.x. If other applications
> > have the same behavior, I'm afraid it's not glibc but X11/GTK+1.2 problem.
>
> Downgrading libc6 version fixes it, so it's a no brainer: the problem is libc6
> 2.3.1, not xlib or gtk.
Your trace says:
#0 0x40521e92 in mallopt () from /lib/libc.so.6
#1 0x40520e6a in free () from /lib/libc.so.6 <-
#2 0x40846f6f in _Xutf8DefaultDrawImageString () from <-
/usr/X11R6/lib/X11/locale/common/xomGeneric.so.2
So... I guess free() is double called, or so. Try below program with gdb:
#include <stdlib.h>
main()
{
int *i = (int *)malloc(100);
free(i);
free(i);
}
gotom@celesta:~/tmp> gdb ./a.out
(gdb) run
Starting program: /home/gotom/tmp/a.out
Program received signal SIGSEGV, Segmentation fault.
0x40095e65 in mallopt () from /lib/libc.so.6
(gdb) bt
#0 0x40095e65 in mallopt () from /lib/libc.so.6
#1 0x40094e6a in free () from /lib/libc.so.6
#2 0x08048447 in main () at test.c:6
I guess your libc upgrade expose a hidden application bug because
glibc malloc routine is changed partly from 2.2 to 2.3.
Could you track down the X11/GTK+1.2 memory handling behavior with gdb?
-- gotom
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
