Re: lout 3.21 core dumps when requesting PDF output

[Marketa Ceplova]

On 30 May 00, at 15:51, Valeriy E. Ushakov wrote:

> Huh.  The crash in fopen(3) was, as i understood, not related to PDF,
> right?

Yes. I have just tried, whether there is not any relation to my problem. It is not, so I am thinking what to do next. Local experts do not seem to be interested in lout (no response to my plea for help) so I choose, either to send my request somewhere else (comp.os.linux.???{misc???}, gnu.misc.discuss, ???) or to check whether there is not any other way how to deal with the problem. The very first idea, which hit my mind is whether there cannot be problem with my version of libc (glibc-2.1.1). What do you think about this -- do you think, that bug may be caused by malfunction in libc? It seemed to me, that the problem has been somewhere in libc, wasn't it?

I am sending carbon copy to the list, just to be sure, that I am not missinig some Linux programmer willing to try checking version 3.21 and talking with me about the bug I have found (I do not know, whether bug in lout or somewhere in Linux). Will I find him???

Have a nice day, all of you

Matej Cepl

P.S.: Enclosed you shall find Jeff's description of the problem.

-----------------------------------
Date forwarded: 	Fri, 19 May 2000 14:51:55 +0200
Forwarded by:   	=?iso-8859-2?Q?Mat=ECj_Cepl?= <address@hidden>
Forwarded to:   	address@hidden
From:           	address@hidden (Jeffrey Howard Kingston)
Date sent:      	Fri, 19 May 2000 13:51:17 +0100 (BST)
To:             	address@hidden
Subject:        	Re: Core dumps w/ lout 3.21!


Thanks for your files.

You sent me a file called LETTER, but your document includes a
file called "letter".  When I renamed "LETTER" to be "letter",
it still didn't work, because your letter that I am trying
to compile contains the line

@From ...

whereas in file LETTER the definition of @From is commented out.

So I have not done any more on that test of yours.

I've also looked carefully at your "where" output, and I'm
sorry to say that the problem really does look as though it
is down in Linux, as Uwe said briefly.  There is a call there,

#2  0x40084e5b in _IO_new_fopen (
filename=0xbfff6d30 "/usr/local/lib/lout/data/standard.ld",
mode=0x80ee36a "r") at iofopen.c:42

which seems to show without question that Lout has generated
a correct call to Linux, asking it to open the file
"/usr/local/lib/lout/data/standard.ld" for reading ("r").
This is something that Linux is supposed to be able to do,
and yet the program crashed before this call was completed.

I think your next step is to ask the Linux people what

malloc.c:2777: není souborem ani adresářem.

suggests to them is going on.  What is it that is neither
a file nor a directory, and what are the possible causes
of this problem?  Perhaps it is a known problem to them.

Also, "malloc" stands for "memory allocation" and it is
a very error-prone area.  There is a small chance that
Lout is doing something to wreck the memory allocation,
so that by the time _IO_new_fopen runs disaster is
lurking behind the scenes ready to strike at random.
If that is the problem then you will need to somehow
get hold of a version of malloc() that does lots of
checks to make sure that no-one is wrecking it.  There
are several such things around, perhaps Linux has one.
This hypothesis would explain several things, such as
the randomness of the effect, and why it has started
now (Lout has some new memory allocation code, added
when adding support for Latin2 character.  However I
have just read through that code very carefully indeed
and it seems very safe).

Good luck.  Please let me know how you get on with
the Linux people.

Jeff Kingston