[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Thu, 06 Dec 2001 09:15:10 +1100
On Wed, 5 Dec 2001 21:06:41 +0100, Volker Renneberg wrote:
> Hi - below you will find the stack trace of gdb. If you need some more
> test runs tell me.
> #0 0x400caba6 in chunk_free (ar_ptr=0x4017c4a0, p=0x855c130) at
> #1 0x400ca980 in __libc_free (mem=0x855c138) at malloc.c:3154
> #2 0x400bbce8 in _IO_new_fclose (fp=0x855c138) at iofclose.c:85
> #3 0x080ffc53 in FontRead (family_name=0x8561fc0 "cmsy",
> face_name=0x8561ff4 "Base", err=0x8539c10) at z37.c:958
Line 958 of z37.c is
That is, it's closing a file that was previously being successfully read.
The actual problem seems to be in the memory allocator. This could be
because your memory allocator has a problem, or it could be because Lout
has mis-handled its memory allocation earlier in the run.
I'm afraid I don't have any good ideas. Has anyone on the Lout list
seen anything like this?
- Re: lout-teq-Bug?,
Jeff Kingston <=