Re: segfaults building documentation when machine under load

Am Freitag, 22. Mai 2020 um 22:52 Uhr schrieb "John W. Eaton":
> After much confusion, I think I arrived at a solution.  I pushed the
> following changeset to stable and merged with default:
>
>    http://hg.savannah.gnu.org/hgweb/octave/rev/00a9a49c7670
>
> on stable and merged with default.
>
> These most recent changes appear to improve the situation for the test
> case shown above.  I'm not longer able to cause a segfault with the
> following parallel execution:
>
>      parallel -j 50 -N0 -q octave --norc --silent --no-history --eval
> 'figure (1, "visible", "off");' ::: {1..1000}
>
> Here's the summary from the changset commit message:
>
> ----
> This change is a further attempt to avoid segfaults when shutting down
> the interpreter and exiting the GUI event loop.  The latest approach is
> to have the interpreter signal that it is finished with "normal" command
> execution (REPL, command line script, or --eval option code), then let
> the GUI thread process any remaining functions in its event loop(s) then
> signal back to the interpreter that it is OK to shutdown.  Once the
> shutdown has happened (which may involve further calls to the GUI thread
> while executing atexit functions or finish.m or other shutdown code, the
> interpreter signals back to the GUI that shutdown is complete.  At that
> point, the GUI can delete the interpreter object and exit.
> ----
>
> Before this change, the GUI could still be processing events (displaying
> the figure window, for example) while the interpreter was being deleted.
>   Obviously, that causes trouble.
>
> Although we recognized this problem before, none of the previous
> solutions have really worked.  See the commit message for
> https://hg.savannah.gnu.org/hgweb/octave/rev/cdb681adc85a, for example,
> where I noted that
>
>    ... the crash described in bug report #56952 appeared to be happening
> when the Qt event loop was calling
> QtHandles::qt_graphics_toolkit::create_object when the interpreter was
> being deleted and the gh_manager object was already invalid, ...
>
> I noticed this again and finally realized that we could probably use the
> Qt event queue to ensure that pending graphics events are allowed to
> finish before shutting down the interpreter.  It seems to work for all
> the tests I've tried so far, including creating a figure in the finish.m
> script or using "atexit ('sombrero')".

The Fedora buildbots seem to stop after the recent changes when they try to create the plots for the manual.
E.g.:
http://buildbot.octave.org:8010/#/builders/25/builds/1547/steps/5/logs/stdio

/bin/sh run-octave --norc --silent --no-history --path /home/buildbotu/fc25-x86_64/gcc-lto-fedora/build/../src/doc/interpreter/ --eval "geometryimages ('doc/interpreter/', 'voronoi', 'eps');"
/bin/sh run-octave --norc --silent --no-history --path /home/buildbotu/fc25-x86_64/gcc-lto-fedora/build/../src/doc/interpreter/ --eval "geometryimages ('doc/interpreter/', 'triplot', 'eps');"
/bin/sh run-octave --norc --silent --no-history --path /home/buildbotu/fc25-x86_64/gcc-lto-fedora/build/../src/doc/interpreter/ --eval "geometryimages ('doc/interpreter/', 'griddata', 'eps');"
/bin/sh run-octave --norc --silent --no-history --path /home/buildbotu/fc25-x86_64/gcc-lto-fedora/build/../src/doc/interpreter/ --eval "geometryimages ('doc/interpreter/', 'convhull', 'eps');"
command timed out: 1200 seconds without output running [b'nice', b'-n', b'10', b'make', b'V=1', b'-j4'], attempting to kill
process killed by signal 9
program finished with exit code -1
elapsedTime=2309.509019

Maybe the threads wait for a signal from each other and got stuck?

Are the Fedora buildbots headless like the Debian ones?

Markus