bugGNU Octave - Bugs: bug #55225, building doc figures in .eps or...

 
 

bug #55225: building doc figures in .eps or .pdf format occasionally silently fails

Submitted by:  Mike Miller <mtmiller>
Submitted on:  Fri 14 Dec 2018 07:27:08 PM UTC  
 
Category:  Plotting with OpenGL Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Build Failure
Status:  Confirmed Assigned to:  None
Originator Name:  Open/Closed:  Open
Release:  dev Operating System:  GNU/Linux

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

( Jump to the original submission)

Fri 15 Nov 2019 12:21:17 AM UTC, comment #29: 

Yeah, so the important error messages buried in those 600 lines are

No file octave.cps.
No file octave.fns.
No file octave.ops.
No file octave.prs.

Your error is unrelated to this bug, and is probably due to a problem in texinfo's texindex. Like I said on the mailing list, I used to see this error randomly on Debian some number of weeks / months ago, but it's gone away for me, probably fixed by a newer version of texinfo. If you want you can open a new bug report, but the fix may end up being to avoid particular versions of texinfo. Which would be good to know in general.

Mike Miller <mtmiller>
Project Administrator
Thu 14 Nov 2019 11:16:17 PM UTC, comment #28: 

It seems like it's the latter for me, that octave.dvi always fails to build.

Attached is the verbose log.

(file #47870)

Nir Krakauer <nir_krakauer>
Thu 14 Nov 2019 09:40:48 PM UTC, comment #27: 

The easiest way to tell if you are hitting this bug is to try 'make all' again. If it's this bug, you will see something like

...
  GEN      doc/interpreter/interpft.eps
  TEXI2DVI doc/interpreter/octave.dvi

and then octave.dvi will build successfully. Keep repeating until all images are built and exist, and eventually octave.dvi will build without error.

If you run 'make' again and it only tries to build octave.dvi and it fails again and again, then it's probably not this bug, but a different problem.

You can always get the full output from texi2dvi and TeX by running 'make V=1' or looking in doc/interpreter/octave.t2d/doc!interpreter!octave.t2d/dvi/build/octave.log.

Mike Miller <mtmiller>
Project Administrator
Thu 14 Nov 2019 08:57:23 PM UTC, comment #26: 

I'm not sure. I don't see any message about an EPS file not existing. It's basically just

  TEXI2DVI doc/interpreter/octave.dvi
/usr/bin/texi2dvi: etex exited with bad status, quitting.

Nir Krakauer <nir_krakauer>
Thu 14 Nov 2019 07:35:33 PM UTC, comment #25: 

The Texinfo version shouldn't matter if this is the same bug.

Nir - are you sure you are experiencing this bug? Specifically, do you see make report that it's building, for example, interpft.eps, followed by an error building octave.dvi, and then you can confirm that interpft.eps doesn't exist?

The specific symptom that this bug report is about is not just Texinfo failing to build for some reason (like in your message to the mailing list), but that Octave is asked to build an image file in doc/interpreter, it exits with success, make continues, but the image file was not actually generated.

Mike Miller <mtmiller>
Project Administrator
Thu 14 Nov 2019 07:31:52 PM UTC, comment #24: 

`texi2dvi --version` gives `6.6`

Nir Krakauer <nir_krakauer>
Thu 14 Nov 2019 07:17:12 PM UTC, comment #23: 

Nir -- What is your texinfo version?

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Thu 14 Nov 2019 07:12:14 PM UTC, comment #22: 

I experienced the same error with both `-j2` and `-j1`, cf. https://octave.1599824.n4.nabble.com/Problem-building-Octave-td4694553.html

Nir Krakauer <nir_krakauer>
Wed 16 Oct 2019 07:04:33 PM UTC, comment #21: 

This happens with buildbot as well. E.g.:

http://buildbot.octave.org:8010/#/builders/11/builds/1162/steps/5/logs/stdio

Dmitri.

Dmitri A. Sergatskov <dasergatskov>
Wed 16 Oct 2019 06:34:24 PM UTC, comment #20: 

This bug still affects me. Right now, this is very highly reproducible for me, and it seems highly correlated to building with "make -jN". However, I am still sometimes able to reproduce this with serial "make -j1".

Here are some examples from my current build tree, using a sampling of image files that happened to fail to build for me:

## parallel build

$ rm -f doc/interpreter/{convhull,errorbar,hist,mesh,polar}.eps
$ make -j8 doc/interpreter/{convhull,errorbar,hist,mesh,polar}.eps
  GEN      doc/interpreter/convhull.eps
  GEN      doc/interpreter/errorbar.eps
  GEN      doc/interpreter/hist.eps
  GEN      doc/interpreter/mesh.eps
  GEN      doc/interpreter/polar.eps
$ ls -l doc/interpreter/{convhull,errorbar,hist,mesh,polar}.eps
ls: cannot access 'doc/interpreter/errorbar.eps': No such file or directory
ls: cannot access 'doc/interpreter/mesh.eps': No such file or directory
ls: cannot access 'doc/interpreter/polar.eps': No such file or directory
-rw-r--r-- 1 mike mike 17553 Oct 16 11:29 doc/interpreter/convhull.eps
-rw-r--r-- 1 mike mike 13134 Oct 16 11:29 doc/interpreter/hist.eps

## serial build

$ rm -f doc/interpreter/{convhull,errorbar,hist,mesh,polar}.eps
$ make -j1 doc/interpreter/{convhull,errorbar,hist,mesh,polar}.eps
  GEN      doc/interpreter/convhull.eps
  GEN      doc/interpreter/errorbar.eps
  GEN      doc/interpreter/hist.eps
  GEN      doc/interpreter/mesh.eps
  GEN      doc/interpreter/polar.eps
$ ls -l doc/interpreter/{convhull,errorbar,hist,mesh,polar}.eps
ls: cannot access 'doc/interpreter/errorbar.eps': No such file or directory
-rw-r--r-- 1 mike mike  17553 Oct 16 11:31 doc/interpreter/convhull.eps
-rw-r--r-- 1 mike mike  13134 Oct 16 11:31 doc/interpreter/hist.eps
-rw-r--r-- 1 mike mike 839976 Oct 16 11:31 doc/interpreter/mesh.eps
-rw-r--r-- 1 mike mike  19259 Oct 16 11:31 doc/interpreter/polar.eps

As you can see, Octave does not report an error when the command fails to produce a .eps file, and it exits with success, so there is no indication to make that anything failed. The error is caught later when octave.dvi fails to build.

Mike Miller <mtmiller>
Project Administrator
Mon 18 Mar 2019 11:26:13 PM UTC, comment #19: 

I filed bug #55952 for the "seealso already defined" build error.

Mike Miller <mtmiller>
Project Administrator
Mon 18 Mar 2019 11:17:05 PM UTC, comment #18: 

On a second look, this is just your build directory, so the problem must be somewhere else...

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Mon 18 Mar 2019 11:12:17 PM UTC, comment #17: 

Neither buildbots nor me have sundials 4.x so we do not see this problem...

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Mon 18 Mar 2019 10:42:58 PM UTC, comment #16: 

I'm hitting the same error as Stefan now in my last build

../doc/interpreter/macro
s.texi:51: Macro name seealso already defined.
@macroxxx ...@the @macname @space already defined}
                                                  @fi @global @cslet {macsav...
l.51 @macro seealso {args}

? ^C/home/mike/src/octave/default/+build-default-sundials4/../doc/interpreter/macro
s.texi:51: Interruption.
<to be read again>
                   @global
@macroxxx ...e @space already defined}@fi @global
                                                  @cslet {macsave.@the @macn...
l.51 @macro seealso {args}

?

Aside from the top-level error being the same "/usr/bin/texi2dvi: etex exited with bad status, quitting.", this does not look like the same bug that this report is about.

Mike Miller <mtmiller>
Project Administrator
Mon 18 Mar 2019 05:48:32 PM UTC, comment #15: 

Make sure you do not have corrupted files left over from previous failed builds. Start with a fresh new clone...

Dmitri.

Dmitri A. Sergatskov <dasergatskov>
Mon 18 Mar 2019 05:32:29 PM UTC, comment #14: 

With -j1 V=1 I now get this:

'''
texi2dvi  --build-dir=doc/interpreter/octave.t2d -o doc/interpreter/octave.dvi  \
`test -f 'doc/interpreter/octave.texi' || echo '/home/haawda/paketierung/meine_Pakete/octave-hg/src/octave/build/../'`doc/interpreter/octave.texi
This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) (preloaded format=etex)
 restricted \write18 enabled.
entering extended mode

(/home/haawda/paketierung/meine_Pakete/octave-hg/src/octave/build/../doc/interp
reter/octave.texi
(/home/haawda/paketierung/meine_Pakete/octave-hg/src/octave/build-aux/texinfo.t
ex Loading texinfo [version 2019-03-16.20]: pdf, fonts, markup, glyphs,
page headings, tables, conditionals, indexing, sectioning, toc, environments,
defuns, macros, cross references, insertions,
(/usr/local/texlive/2019/texmf-dist/tex/generic/epsf/epsf.tex
This is `epsf.tex' v2.7.4 <14 February 2011>
) localization, formatting, and turning on texinfo input format.)
(/home/haawda/paketierung/meine_Pakete/octave-hg/src/octave/build/../doc/interp
reter/macros.texi
/home/haawda/paketierung/meine_Pakete/octave-hg/src/octave/build/../doc/interpr
eter/macros.texi:51: Macro name seealso already defined.
@macroxxx ...@the @macname @space already defined}
                                                  @fi @global @cslet {macsav...
l.51 @macro seealso {args}

                         

?

Stefan Husmann <haawda>
Tue 12 Mar 2019 09:03:18 PM UTC, comment #13: 

Here is what I see in logs:

Mar 11 17:15:48 amd systemd-coredump[23808]: Process 22665 (lt-octave-gui) of user 1002 dumped core.

                                             Stack trace of thread 22665:
                                             #0  0x00007f9aea6b26a0 n/a (n/a)
                                             #1  0x00007f9b09b1d285 _ZN19QApplicationPrivate13notify_helperEP7QObjectP6QEvent (libQt5Widgets.so.5)
                                             #2  0x00007f9b09b249a0 _ZN12QApplication6notifyEP7QObjectP6QEvent (libQt5Widgets.so.5)
                                             #3  0x00007f9b0b7b6660 n/a (/home/buildbotu/fc25-x86_64/clang-fedora/build/libgui/.libs/liboctgui.so.5.0.0)
Mar 11 17:15:48 amd audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-coredump@13-23806-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=?>
Mar 11 17:15:49 amd abrt-server[23862]: Deleting problem directory ccpp-2019-03-11-17:15:48.614346-22665 (dup of ccpp-2019-02-20-16:56:03.416525-6133)
Mar 11 17:15:50 amd abrt-notification[23915]: Process 6133 (lt-octave-gui) crashed in ??()
Mar 11 17:15:55 amd qcollectiongenerator-qt5[24063]: QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-buildbotu'

Dmitri.

Dmitri A. Sergatskov <dasergatskov>
Tue 12 Mar 2019 08:15:26 PM UTC, comment #12: 

I suspect that it happens when computer is heavily loaded. The buildbots running multiple parallel builds when this happens.
I cannot reproduce it if I just re-run make on this computer.

(You can also see that this is not a single occurence:
http://buildbot.octave.org:8010/#/builders/9
)

Dmitri.

Dmitri A. Sergatskov <dasergatskov>
Tue 12 Mar 2019 06:09:04 PM UTC, comment #11: 

Marking the bug confirmed, even though I can't reproduce, and reopening this report.

Pantxo Diribarne <pantxo>
Project Member
Tue 12 Mar 2019 06:07:38 PM UTC, comment #10: 

It looks like creating and destroying ui objects synchronously was not a definite fix, but rather made this bug less probable.

This shows that the issue was clearly not what I though it was (I was sure this bug could simply not happen anymore). Furthermore the synchronous approach made things slower. I'll work on this when I find some time.

@Dmitri: It is strange that creating txt files (that don't even involve creating a figure) crash Octave. This may be a different issue.

Pantxo Diribarne <pantxo>
Project Member
Tue 12 Mar 2019 05:00:08 PM UTC, comment #9: 

Some buildbots are crashing (with sigfault) too:

http://buildbot.octave.org:8010/#/builders/9/builds/770

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Tue 12 Mar 2019 03:16:21 PM UTC, comment #8: 

After some month where everythink worked as expected I now encounter this again, building from stable mercurial branch or from develop branch.

Stefan Husmann <haawda>
Fri 21 Dec 2018 06:57:32 PM UTC, comment #7: 

This is fixed for me with the current stable branch, thanks.

Mike Miller <mtmiller>
Project Administrator
Fri 21 Dec 2018 06:45:13 PM UTC, comment #6: 

The patch for bug #55926 has been pushed. Marking this one ready for test.

Pantxo Diribarne <pantxo>
Project Member
Mon 17 Dec 2018 07:19:42 PM UTC, comment #5: 

The patch for bug #55226 also fixes this bug for me.

Mike Miller <mtmiller>
Project Administrator
Fri 14 Dec 2018 08:50:49 PM UTC, comment #4: 

The bug.sh also fails for me:
...
51: -rw-rw-r--. 1 10512 Dec 14 14:49 doc/interpreter/plot.eps
52: -rw-rw-r--. 1 10512 Dec 14 14:49 doc/interpreter/plot.eps
53: -rw-rw-r--. 1 10512 Dec 14 14:49 doc/interpreter/plot.eps
54: ls: cannot access 'doc/interpreter/plot.eps': No such file or directory

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Fri 14 Dec 2018 08:46:13 PM UTC, comment #3: 

This is a problem even with 'make -j1' as I showed in the initial comment. Now it may still be a problem with system load causing some kind of racy timeout condition, and it may get worse with more build jobs running in parallel, but it is not specifically due to two simultaneous instances of Octave and not solved with '-j1'.

Updated shell script to test this more easily with different figures and different file formats:

#!/bin/sh
# bug.sh
d=doc/interpreter
e=eps
f=plot
n=1
o=./run-octave
s=plotimages
fn="$d/$f.$e"
touch $fn
while [ -e $fn ]; do
  rm -f $fn \
    && $o -qfH --path ../$d --eval "$s ('$d/', '$f', '$e');" \
    && echo -n "$n: " \
    && ls -lgo $fn \
    && n=$((n+1))
done

With this I am able to observe that I get the same type of failure with the file format set to either eps or pdf. With either format, after some number of iterations, Octave silently fails to write the intended output file and exits with success.

There is a similar but different error with png format figures that I will report separately.

Mike Miller <mtmiller>
Project Administrator
Fri 14 Dec 2018 08:34:22 PM UTC, comment #2: 

I wonder if it is related to the problem I see with parallel builds. It seems to be hardware dependent. It is almost 100%
reproduciable on i5-4570 (Intel GPU) and Nehalem Xeon
(with Nvidia GPU though I use software rendering).

In my case it is always a problem with "make -j4" and even
"make -j4 V=1" fixes it. Building with gnuplot (instead of qt)
always works fine as well.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Fri 14 Dec 2018 07:39:06 PM UTC, comment #1: 

As a follow up, the following shell script snippet also reveals this error pretty clearly for me

$ cat bug.sh
n=1
touch doc/interpreter/plot.eps
while [ -e doc/interpreter/plot.eps ]; do
  rm -f doc/interpreter/plot.eps \
    && ./run-octave -qfH --path ../doc/interpreter --eval "plotimages ('doc/interpreter/', 'plot', 'eps');" \
    && echo -n "$n: " \
    && ls -lgo doc/interpreter/plot.eps \
    && n=$((n+1))
done
$ ./bug.sh
1: -rw-r--r-- 1 10512 Dec 14 11:37 doc/interpreter/plot.eps
2: -rw-r--r-- 1 10512 Dec 14 11:37 doc/interpreter/plot.eps

39: ls: cannot access 'doc/interpreter/plot.eps': No such file or directory

There is no indication from Octave or from the shell exit status that anything went wrong, just that the file plot.eps doesn't exist.

Mike Miller <mtmiller>
Project Administrator
Fri 14 Dec 2018 07:27:08 PM UTC, original submission:  

On my system, building the figures for the user manual in the .eps format occasionally fails with no error message and no output file produced. The error only becomes apparent when octave.dvi is built, at which point TeX complains about the missing include file.

This is reproducible, although not 100% of the time, and is not always the same figures. The most recent example on my system:

$ rm -f doc/interpreter/*.{dvi,eps,pdf,png}
$ make -j1 V=1 all

…/doc/interpreter/poly.texi:838: Could not open file splinefit2.eps, ignoring it.

/usr/bin/texi2dvi: etex exited with bad status, quitting.

And sure enough, the file doc/interpreter/splinefit2.eps is missing. Scrolling up through the build output, I do see the following command

/bin/bash run-octave --norc --silent --no-history --path …/doc/interpreter/ --eval "splineimages ('doc/interpreter/', 'splinefit2', 'eps');"

With no error or indication that the command failed, simply no output file produced.

On a second or third repeat of the same sequence, it may work, or there may be a different set of 1 or 2 images missing.

This is with a real display, Intel integrated graphics, Qt toolkit, Qt 5.11.2, gl2ps 1.4.0.

Mike Miller <mtmiller>
Project Administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #47870:  buildlog1.txt added by nir_krakauer (28KiB - text/plain)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by nir_krakauer (Posted a comment)
  • -email is unavailable- added by haawda (Posted a comment)
  • -email is unavailable- added by pantxo (Posted a comment)
  • -email is unavailable- added by haawda (same here)
  • -email is unavailable- added by dasergatskov (Posted a comment)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

     

     

    Follow 9 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-11-14 nir_krakauer Attached File- => Added buildlog1.txt, #47870
    2019-03-12 pantxo StatusFixed => Confirmed
        Open/ClosedClosed => Open
    2018-12-21 mtmiller StatusReady For Test => Fixed
        Open/ClosedOpen => Closed
    2018-12-21 pantxo StatusNone => Ready For Test
    2018-12-15 haawda Carbon-Copy- => Added stefan-husmann@t-online.de
    2018-12-14 mtmiller Summarybuilding doc figures in .eps format occasionally silently fails => building doc figures in .eps or .pdf format occasionally silently fails
    2018-12-14 mtmiller Carbon-CopyRemoved 80942 => -

    Back to the top


    Powered by Savane 3.5