[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #51527] Make race issue when MikTeX htlatex is used

From: Vincent Belaïche
Subject: [bug #51527] Make race issue when MikTeX htlatex is used
Date: Fri, 21 Jul 2017 11:00:15 -0400 (EDT)
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0


                 Summary: Make race issue when MikTeX htlatex is used
                 Project: make
            Submitted by: vincentb1
            Submitted on: Fri 21 Jul 2017 03:00:13 PM UTC
                Severity: 3 - Normal
              Item Group: Bug
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
       Component Version: None
        Operating System: None
           Fixed Release: None
           Triage Status: None



= Introduction =


* First of all, I came into this bug with MikTeX htlatex utility, but I think
that this would happen with any compiler that works the same way as htlatex
(see end of this report), not only MikTeX, and not only from the latex

However, the problem may be easier to fix in htlatex by designing file access
in a more clever way, than in make itself.

* Second, this bug is systematic, but reproducing it needs some very specific
setting. I cannot provide a minimal example for the time being

* Third, I am using a probably outdated MSYS port of GNU make, here is its

$ make --version
GNU Make 3.81
Copyright (C) 2006  Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A

This program built for i686-pc-msys

Although this port might be outdated, I suspect that the issue I am reporting
may happen with the current make provided that (1) the .NOTPARALLEL phony
target is not there, and that (2) there is some compiler working in the same
way as htlatex. 

The reason for such thinking is that I had a looked at the latest version of
the gnu make manual on the git repo, and nothing is said about such issue.

= Bug description =

I came a accross a very strange issue. There seems to be some real time issue
in triggering rules that in some circumstances cause a deadlock that fails the

== Fact 1 ==
I provide two files with the log of a make session, one file log_uds.txt is
successful, and the other log_nosd.txt is failed. In one case I pass some
USE_DOCSTRIP=yes argument on the command line and the make works, and in the
other case I do not pass this argument and the make fails. However passing or
not this variable setting on the cmd-line should not do any change because
pretty early in the Makefile I have some USE_DOCSTRIP?=yes statement that
makes yes the default setting !

This means to me that the only change is that the the make memory dynamic
allocation is slightly changed and some race issue does not happen the same
way with USE_DOCSTRIP=yes. Please note that I can repeat the test many times,
and the one without USE_DOCSTRIP=yes in the command line will always fail.

== Fact 2 ==
If I run the failing test in another directory with exactly same content, but
w/o the same filename lengths in the root directory path, it does not fail !!
But is the root directory path has the same length for each direcory in it,
then it fails.

To me this means that because some absolute path saved by make in its memory
do not have the same length, then the memory allocation is slightly different
and this prevent failing.

I attached a script doit.sh that reproduce the bug if you are on MSYS and
place doit.sh in a directory with the right filename lengths in its path (see
comment in doit.sh).

== Fact 3 ==
If I set variable USE_DOCSTRIP to other allowed values no or awk, this changes
the ways the LaTeX stylefiles used by the test are docstripped, but this
should not have any effect in the latex compilation result itself because
basically this only changes the amount of comments ignored by LaTeX that are
in the style-files processed in the test. However this alternative setting of
USE_DOCSTRIP also prevents the make from failing. I understand that once again
if I do that the make will not allocate dynamic memory the same way and I do
not fall in the pitfall.

= Fact analysis and guessing the source of problem =

Let us see in more details what happens: when you type make fmtord.log in the
trunk/test subdirectory, then the makefile is supposed to do the following 3

1) it creates with the MiKTeX htlatex.exe program some file
test-fmtord-l.html from test-fmtord-l.tex in the subdirectory

2) it produces test-fmtord-l-nodate.html from test-fmtord-l.html with a
lightweight AWK script to strip out any date-timestamp information.

3) Finally it compares test-fmtord-l-nodate.html to a reference file in
subdirectory trunk/test/references, and the outcome of comparison give the
test verdict.

My guess is the following : htlatex.exe produces test-fmtord-l.html by running
latex 2 or 3 times in sequence in subprocesses. Make detects that
test-fmtord-l.html is ready after firs 1st or 2nd suprocess is over and
launches the date-timestamp awk scripts *before* htlatex is actually over.
This creates an interlock between the latex and the awk programs trying to
write-access the same file at the same time, and causes the problem.

I don't know how this happens, and I don't know either whether GNU Make or
MiKTeX htlatex port is to blame. But I think that any compiler that have a
similar behaviour as htlatex (ie doing several output pass of the same target
files by some subprocessing) will be at the same risk.


File Attachments:

Date: Fri 21 Jul 2017 03:00:13 PM UTC  Name: log_nosd.txt  Size: 152KiB   By:

Date: Fri 21 Jul 2017 03:00:13 PM UTC  Name: doit.sh  Size: 563B   By:

Date: Fri 21 Jul 2017 03:00:13 PM UTC  Name: log_uds.txt  Size: 152KiB   By:



Reply to this item at:


  Message sent via/by Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]