Discussion:
[tex-k] Problem with trip trap test
Norbert Preining
2011-08-03 07:58:00 UTC
Permalink
Hi everyone,

this is a follow up to some postings on tldistro at tug.org, but I guess
it is of interest here.

I am trying to build TeX Live packages for Debian, so I adjust the
search paths in texmf.cnf in texk/kpathsea to the paths as used
in Debian (/usr/share/texmf, /var/lib/texmf, etc). The generated paths.h
contained a lot of /noneexists or so directories, which comes from
the awk script that converts the texmf.cnf file to paths.h. Now if
I change also that to generate the correct paths.h (or at least one
with the right definitions for Debian systems), and build tex, at
the end the trip trap test breaks.

It seems that the generation of the format (trip.fmt) is not working.

If I try to create trip.fmt according to the triptrap test:
./tex --progname=initex --ini <../../../texk/web2c/triptrap/trip1.in >tripin.fot
I *do* get a format file (135135 bytes) but the log file tripin.fot
is a bit strange:
---- tripin.fot -----
This is TeX, Version 3.1415926 (TeX Live 2011/Debian) (INITEX)
**Please type the name of your input file.
**(./trip.tex
! Bad character code (256).
<to be read again>
-
l.26 \nonstopmode\lccode256-
0\mathchardef\a="8000\def\a{ SCALED 3~2769}
! Bad mathchar (32768).
<to be read again>
\def
l.26 ...opmode\lccode256-0\mathchardef\a="8000\def
\a{ SCALED 3~2769}
! Illegal magnification has been changed to 1000 (32769).
.....
--------------------------

After that, running the next trip test fails with memory allocation. This
test is in principle:
./tex '&trip trip'
which prodcues:
This is TeX, Version 3.1415926 (TeX Live 2011/Debian)
fatal: memory exhausted (xmalloc of 18446744071564067984 bytes).

Ouchhhh....

Does anyone have an idea where the first problem comes from? I guess that
it has to be related with the searching of trip/trap/whatever files.

Thanks for any suggestion

Best wishes

Norbert
------------------------------------------------------------------------
Norbert Preining preining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
------------------------------------------------------------------------
WHAPLODE DROVE (n.)
A homicidal golf stroke.
--- Douglas Adams, The Meaning of Liff
Peter Breitenlohner
2011-08-03 10:16:00 UTC
Permalink
Post by Norbert Preining
I change also that to generate the correct paths.h (or at least one
with the right definitions for Debian systems), and build tex, at
the end the trip trap test breaks.
It seems that the generation of the format (trip.fmt) is not working.
./tex --progname=initex --ini <../../../texk/web2c/triptrap/trip1.in >tripin.fot
I *do* get a format file (135135 bytes) but the log file tripin.fot
---- tripin.fot -----
This is TeX, Version 3.1415926 (TeX Live 2011/Debian) (INITEX)
**Please type the name of your input file.
**(./trip.tex
! Bad character code (256).
<to be read again>
-
l.26 \nonstopmode\lccode256-
0\mathchardef\a="8000\def\a{ SCALED 3~2769}
! Bad mathchar (32768).
<to be read again>
\def
l.26 ...opmode\lccode256-0\mathchardef\a="8000\def
\a{ SCALED 3~2769}
! Illegal magnification has been changed to 1000 (32769).
.....
Hi Norbert,

this is exactly the expected output, and I also get trip.fmt with 135135
bytes.
Post by Norbert Preining
--------------------------
After that, running the next trip test fails with memory allocation. This
./tex '&trip trip'
This is TeX, Version 3.1415926 (TeX Live 2011/Debian)
fatal: memory exhausted (xmalloc of 18446744071564067984 bytes).
Ouchhhh....
Ouchhhh, indeed. This number is approx 2^64-2*10^9, so assuming you are on
x86_64, this could be -2*10^9 converted to size_t (which would be `long
unsiged int'). No idea where that negative number would come from.
Post by Norbert Preining
Does anyone have an idea where the first problem comes from?
There is no first problem (except that possibly the content of trip.fmt
contains garbage).

Regards
Peter Breitenlohner <peb at mppmu.mpg.de>
Norbert Preining
2011-08-03 13:43:11 UTC
Permalink
Hi Peter,
Post by Peter Breitenlohner
Ouchhhh, indeed. This number is approx 2^64-2*10^9, so assuming you are on
x86_64, this could be -2*10^9 converted to size_t (which would be `long
unsiged int'). No idea where that negative number would come from.
Sorry for the noise ... I only say one thing:

-for i:=0 to 128 do mubyte_cswrite[i]:=null;
+for i:=0 to 127 do mubyte_cswrite[i]:=null;

?/&$/?&$***

Forgot that. Sorry for the noise.


Best wishes

Norbert
------------------------------------------------------------------------
Norbert Preining preining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
------------------------------------------------------------------------
FARNHAM (n.)
The feeling you get about four o'clock in the afternoon when you
haven't got enough done.
--- Douglas Adams, The Meaning of Liff

Loading...