[tlbuild] m-tx test fails on powerpc-linux

Johannes Hielscher jhielscher at posteo.de
Sat Apr 7 03:12:43 CEST 2018


Am Fri, 6 Apr 2018 23:01:44 GMT
schrieb Karl Berry <karl at freefriends.org>:

> Hi Johannes,
> 
>     The output comes from the fprintf call ending on "%d\n" at line
> 1131
> 
> I see that line ending with %s\n, not %d:
>   fprintf(outfile, " %s %8.5f %d %d %d %d %s\n",
Sorry, Freudian typo. I saw the "0" in the successful output file and
thought ``Who would store integers in a string variable?''
>   
> I suspect that the fracindent variable corresponding to the %s is NULL
> at the point of the fprintf,
fracindent is a char[256] and gets unconditionally filled with "0" in
preambleDefauilts(), cf. prepmx.c:782. The only place where something
not string-literal is strcpy()'d into fracindent is within
setIndent(): there it might get overwritten by the value cline[22].
cline itself consists of ordinary C strings of zero or finite length. So
at least the code side is seemingly unsuspicious

> and Thomas (Schmitz)'s libc (Debian 6)
> printed that as 0, and yours prints it as garbage. I.e., the bug was
> present before but hidden. 

Yeah, doesn't that mean that the test file has been badly chosen in the
first place, that it failed to detect the bug until now?
Someone who knows about M-Tx should have a look what is expected as
output from prepmtx on the sample file.

> 
> 1) Try compiling without optimization.
-O0 didn't make a difference, nor taking gcc-7.3.0 instead of gcc-5.5.0
> 
> 2) If you have valgrind or similar available, couldn't hurt to try
> running that.
> 
> 3) Failing that, I can only suggest running under the debugger and
> try to discern where the bad value comes from.

I'll have a try. Tomorrow.

> 
> I can ask Thomas if he happens to have binaries from last year with
> symbols included. (Or maybe you can get a debuggable 2017 binary from
> a Debian or other archive?) Then you could run the two side by side
> and see where they diverge. Or maybe try doing that with a
> supposedly-good binarch (e.g., your aarch64) and the failing powerpc.
I compiled m-tx from the 2017 branch sources, so I have such a
reference binary already by myself on the same machine.
> 
>     prepmx emits some more warnings during processing:
> 
> Sounds like something went wrong earlier :(. -k

The tests triggering those messages weren't introduced until m-tx v0.63
(TL SVN -r46254).



Thanks,
Johannes


More information about the tlbuild mailing list