[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Wed, 5 Dec 2001 23:41:30 +0100 (MET)
On Thu, 6 Dec 2001, Jeff Kingston wrote:
> 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.
When does this problem occur?
Is there a special lout-document, which is available (which produces problems)?
And which lout-version is it?
If I have some free time, I can look inside of the code.