Re: lout-teq-Bug?

[Wolfram Kahl]

Dear Jeff,

> 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 
> malloc.c:3242
>   > #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
> 
>   fclose(fp);
> 
> 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?

(Hi Volker!)


Now that I see this under the heading ``lout-teq-Bug'',
I must admit that this is a possibility.

I have been getting deterministic segmentation faults under Linux
for undiscernable reasons (some small changes to the document
and it suddenly crashes, lots of changes and it still crashes,
other changes and it doesn't crash anymore) for quite some time
(probably in several versions of lout, mostly in very long documents,
probably always with teq)
and the one time I started the debugger I also ended up at some fclose.

The same documents worked under Solaris, so I thought it might be a glibc bug.


The last time I had it it was a mathematics-free document,
and for some reason it occured to me to replace my standard teq by eq,
and the error went away. (And I was happy about that and had no time
to investigate.)
(I have also seen compiler optimisation produce disastrous results
on previous versions of lout, so I was quite surprised to see -O3
as default in the current version. However, before the installation of the
version without -O and with -g -DDEBUG was finished, removing teq
had produced the desired result, so I did not try the debugging version.)



By the way, could you fill up the empty slot in the colour table with
``orange''? I tried to use something like

{1.0 0.5 0.0} @SetColour @Box black @Color {Power cutoff}

to get an orange-framed box, but I did not get it ---
I then hacked bsf again, so that

orange @Colour @Box black @Color {Power cutoff}

did it. Sorry, but again I have not time to try to isolate or reproduce that.



Anyway, the resulting slides were much appreciated ---
thanks to Lout, the problem was definitely not producing the slides,
even what in the result looked like animations,
but thinking about their contents!
(
 Q.: ``How long did it take to produce these slides in powerpoint?''
 ---
 A.: ``I never use powerpoint;
       everything was done with functional programming! ;-)''
)

Many thanks for this wonderful tool!



All the best,

Wolfram



P.S.: While doing Overheads, when I insert a new slide,
      I get those undefined reference ...&following or whatever.
      That might be okay.
      But why do they produce huge question marks in the upper left corner
      of the slides concerned, even when I take all imaginable measures to
      make titles empty?

      Since I usually use up slide space, these question marks push the
      bottom line(s) off the slide onto a new slide,
      and a sixty-slide slide show needs sixty runs to stabilise!