bugGNU Octave - Bugs: bug #56952, segfault during compilation while...

 
 

bug #56952: segfault during compilation while processing doc/interpreter/genpropdoc.m

Submitted by:  None
Submitted on:  Wed 25 Sep 2019 06:31:15 PM UTC  
 
Category:  Plotting with OpenGL Severity:  5 - Blocker
Priority:  5 - Normal Item Group:  Segfault, Bus Error, etc.
Status:  Fixed Assigned to:  None
Originator Name:  R.S.Carmenes Originator Email:  -email is unavailable-
Open/Closed:  Closed Release:  6.0.90
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)

Mon 14 Sep 2020 08:27:24 AM UTC, comment #44: 

No problems with building the documentation on the buildbots.
Also, I'm not aware of any reports that this is failing for anybody.

Closing as fixed.

Markus Mützel <mmuetzel>
Project Member
Mon 24 Aug 2020 09:50:45 AM UTC, comment #43: 

The change for bug #57591 might also have helped fixing this.

What are the conditions to consider this fixed? Should this still block the RC for Octave 6?

Markus Mützel <mmuetzel>
Project Member
Fri 14 Aug 2020 02:48:01 PM UTC, comment #42: 

The crashes that happen when Octave is exiting the script might be fixed by the change I checked in for bug #58814.

John W. Eaton <jwe>
Project Administrator
Sun 07 Jun 2020 05:08:50 PM UTC, comment #41: 

I don't want to hijack this report if the crash is unrelated.

Maybe we should just wait if it was a one time error and open a new report in case it should recur?

Markus Mützel <mmuetzel>
Project Member
Sun 07 Jun 2020 01:42:19 PM UTC, comment #40: 

It was probably something else. This is what got captured in logs:

<<<<
Jun 07 05:42:41 i7 systemd-coredump[325850]: Process 325267 (lt-octave-gui) of user 1002 dumped core.

                                            

                                             Stack trace of thread 325827:
                                             #0  0x00007ffaabcb3a6d getenv (libc.so.6 + 0x3ea6d)
                                             #1  0x00007ffa994677bc internal_bus_get (libdbus-1.so.3 + 0x147bc)
                                             #2  0x00007ffa995a412a q_dbus_bus_get_private (libQt5DBus.so.5 + 0x1a12a)
                                             #3  0x00007ffab0ba1352 _ZN7QObject5eventEP6QEvent (libQt5Core.so.5 + 0x271352)
                                             #4  0x00007ffab0b7a8bb doNotify (libQt5Core.so.5 + 0x24a8bb)
                                             #5  0x00007ffab0b7db43 _ZN23QCoreApplicationPrivate16sendPostedEventsEP7QObjectiP11QThreadData (libQt5Core.so.5 + 0x24db43)
                                             #6  0x00007ffab0bc6187 postEventSourceDispatch (libQt5Core.so.5 + 0x296187)
                                             #7  0x00007ffaab0ca7af g_main_context_dispatch (libglib-2.0.so.0 + 0x527af)
                                             #8  0x00007ffaab0cab38 g_main_context_iterate.constprop.0 (libglib-2.0.so.0 + 0x52b38)
                                             #9  0x00007ffaab0cac03 g_main_context_iteration (libglib-2.0.so.0 + 0x52c03)
                                             #10 0x00007ffab0bc5c06 _ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE (libQt5Core.so.5 + 0x295c06)
                                             #11 0x00007ffab0b7921b _ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE (libQt5Core.so.5 + 0x24921b)
                                             #12 0x00007ffab09ed577 _ZN7QThread4execEv (libQt5Core.so.5 + 0xbd577)
                                             #13 0x00007ffa995a34da _ZN22QDBusConnectionManager3runEv (libQt5DBus.so.5 + 0x194da)
                                             #14 0x00007ffab09ee846 _ZN14QThreadPrivate5startEPv (libQt5Core.so.5 + 0xbe846)
                                             #15 0x00007ffaabe48432 start_thread (libpthread.so.0 + 0x9432)
                                             #16 0x00007ffaabd769d3 __clone (libc.so.6 + 0x1019d3)

                                            

                                             Stack trace of thread 325267:
                                             #0  0x00007ffaabd7143d syscall (libc.so.6 + 0xfc43d)
                                             #1  0x00007ffab09f0a81 _ZN12QtLinuxFutex8_q_futexEPiiiyS0_i (libQt5Core.so.5 + 0xc0a81)
                                             #2  0x00007ffab0ba08ce _ZN11QMetaObject8activateEP7QObjectiiPPv (libQt5Core.so.5 + 0x2708ce)
                                             #3  0x00007ffa995f4b83 _ZN22QDBusConnectionManager19connectionRequestedEPNS_21ConnectionRequestDataE (libQt5DBus.so.5 + 0x6ab83)
                                             #4  0x00007ffa995a1e98 _ZN22QDBusConnectionManager12connectToBusEN15QDBusConnection7BusTypeERK7QStringb (libQt5DBus.so.5 + 0x17e98)
                                             #5  0x00007ffa995a1fff _ZN22QDBusConnectionManager13busConnectionEN15QDBusConnection7BusTypeE (libQt5DBus.so.5 + 0x17fff)
                                             #6  0x00007ffa995a2dfa _ZN15QDBusConnection10sessionBusEv (libQt5DBus.so.5 + 0x18dfa)
                                             #7  0x00007ffa996e874d _ZN14DBusConnectionC1EP7QObject (libQt5XcbQpa.so.5 + 0xd674d)
                                             #8  0x00007ffa996df8a0 _ZN20QSpiAccessibleBridgeC1Ev (libQt5XcbQpa.so.5 + 0xcd8a0)
                                             #9  0x00007ffa9965e8ae _ZNK15QXcbIntegration13accessibilityEv (libQt5XcbQpa.so.5 + 0x4c8ae)
                                             #10 0x00007ffab0f0e3f8 _ZN11QAccessible13setRootObjectEP7QObject (libQt5Gui.so.5 + 0xe93f8)
                                             #11 0x00007ffab0f29867 _ZN15QGuiApplication4execEv (libQt5Gui.so.5 + 0x104867)
                                             #12 0x00007ffab335bad5 n/a (/home/buildbotu/fc25-x86_64/stable-clang-fedora/build/libgui/.libs/liboctgui.so.6.0.0 + 0x234ad5)
                                             #13 0x2f75746f62646c69 n/a (n/a + 0x0)
Jun 07 05:42:41 i7 audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-coredump@0-325830-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=s>
Jun 07 05:42:41 i7 systemd[1]: systemd-coredump@0-325830-0.service: Succeeded.

>>>>


I have the coredump as well, but it looks useless w/o binary.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Sun 07 Jun 2020 01:30:42 PM UTC, comment #39: 

Since this is a segfault, marking as a blocker for Octave 6.
Please modify if you don't agree.

Markus Mützel <mmuetzel>
Project Member
Sun 07 Jun 2020 01:28:22 PM UTC, comment #38: 

This seems to be still an issue. The "stable-clang-fedora" worker crashed with a similar error:
http://buildbot.octave.org:8010/#/builders/30/builds/13/steps/6/logs/stdio

/bin/sh run-octave --norc --silent --no-history --path /home/buildbotu/fc25-x86_64/stable-clang-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/stable-clang-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/stable-clang-fedora/build/../src/doc/interpreter/ --eval "geometryimages ('doc/interpreter/', 'griddata', 'eps');"
fatal: caught signal Segmentation fault -- stopping myself...
make[2]: *** [Makefile:31164: doc/interpreter/triplot.eps] Segmentation fault (core dumped)
make[2]: *** Waiting for unfinished jobs....
make[2]: Leaving directory '/home/buildbotu/fc25-x86_64/stable-clang-fedora/build'
make[1]: *** [Makefile:27411: all-recursive] Error 1
make[1]: Leaving directory '/home/buildbotu/fc25-x86_64/stable-clang-fedora/build'
make: *** [Makefile:11046: all] Error 2
program finished with exit code 2

Markus Mützel <mmuetzel>
Project Member
Sat 23 May 2020 01:53:25 PM UTC, comment #37: 

I pushed one more changeset to fix a failing test:

http://hg.savannah.gnu.org/hgweb/octave/rev/60f3b8702ab7

John W. Eaton <jwe>
Project Administrator
Sat 23 May 2020 05:01:39 AM UTC, comment #36: 

That failure looks like bug 55225.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Sat 23 May 2020 04:01:07 AM UTC, comment #35: 

Also if I unset display, it finishes, but it uses gnuplot backend.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Sat 23 May 2020 03:48:17 AM UTC, comment #34: 

This is on default (c6d10df71863 tip @) on my workstation (CentOS) with display set.

You can see that fedora buildbots are failing in similar fasion.

No coredumps.

Also I tried the parallel test:

rm -rf /tmp/t1/*
parallel -j 64 -N0 -q ./run-octave --norc --silent --no-history --eval 'figure(1, "visible", "off"); plot (1:2); pause(1); print(tempname("/tmp/t1", "t1-")); pause(1);' ::: {1..128}
ls -c /tmp/t1/ | wc -l
113

I expected to get 128 randomly-named files in /tmp/t1...
But perhaps i mis-understood how parallel works.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Sat 23 May 2020 03:07:25 AM UTC, comment #33: 

Is that with DISPLAY or not?

Are you using the stable or default branch?

I can't seem to duplicate that failure now, even with -j100, with or without DISPLAY set, and with either stable or default.

John W. Eaton <jwe>
Project Administrator
Sat 23 May 2020 02:46:17 AM UTC, comment #32: 

Now I am back to

/bin/sh run-octave --norc --silent --no-history --path /home/dima/src/octave/gcc_def/../doc/interpreter/ --eval "sparseimages ('doc/interpreter/', 'grid', 'png');"
error: imwrite: invalid empty image
error: called from
    _imwrite_ at line 40 column 5
    imwrite at line 125 column 5
    print at line 755 column 13
    plotimages at line 55 column 5
/bin/sh run-octave --norc --silent --no-history --path /home/dima/src/octave/gcc_def/../doc/interpreter/ --eval "sparseimages ('doc/interpreter/', 'spmatrix', 'png');"
make[2]: *** [Makefile:31282: doc/interpreter/hist.png] Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: Leaving directory '/home/dima/src/octave/gcc_def'
make[1]: *** [Makefile:27418: all-recursive] Error 1
make[1]: Leaving directory '/home/dima/src/octave/gcc_def'
make: *** [Makefile:11053: all] Error 2

or

/home/dima/src/octave/gcc_def/doc/interpreter/plot.texi:433: Could not open fil
e hist.eps, ignoring it.
@epsfgetbb ...Could not open file #1, ignoring it}
                                                  @else {@chardef @other = 1...

@next #1->@epsfgetbb {#1}
                         @epsfsetgraph {#1}
@imagexxx ...ysize =#3@relax @fi @epsfbox {#1.eps}
                                                  @else @doxeteximage {#1}{#...

@image ...true @fi @else @imagexxx #1,,,,,@finish
                                                  @fi
<argument> @hfil @ignorespaces @image {hist,4in}
                                                @unskip @hfil
@centersub ...enalty @fi @line {@kern @leftskip #1
                                                  @kern @rightskip }
...
l.433 @center @image{hist,4in}

                             

?
/home/dima/src/octave/gcc_def/doc/interpreter/plot.texi:433: Emergency stop.
@epsfgetbb ...Could not open file #1, ignoring it}
                                                  @else {@chardef @other = 1...

@next #1->@epsfgetbb {#1}
                         @epsfsetgraph {#1}
@imagexxx ...ysize =#3@relax @fi @epsfbox {#1.eps}
                                                  @else @doxeteximage {#1}{#...

@image ...true @fi @else @imagexxx #1,,,,,@finish
                                                  @fi
<argument> @hfil @ignorespaces @image {hist,4in}
                                                @unskip @hfil
 [9@centersub ...enalty @fi @line {@kern @leftskip #1
                                                  @kern @rightskip }
...
l.433 @center @image{hist,4in}

                             

Output written on octave.dvi (321 pages, 906860 bytes).
Transcript written on octave.log.
] [10/usr/bin/texi2dvi: etex exited with bad status, quitting.
make[2]: *** [Makefile:31091: doc/interpreter/octave.dvi] Error 1
make[2]: *** Waiting for unfinished jobs....
] [11])
(/home/dima/src/octave/doc/liboctave/intro.texi Chapter 2 [12])
(/home/dima/src/octave/doc/liboctave/array.texi Chapter 3 [13]

(I have to run a pretty high number of job, more than 8 or so,
to get it.)

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Sat 23 May 2020 02:30:07 AM UTC, comment #31: 

I pushed the following changeset to fix the crash I was seeing with octave-cli:

http://hg.savannah.gnu.org/hgweb/octave/rev/8513a18439ca

John W. Eaton <jwe>
Project Administrator
Sat 23 May 2020 02:03:40 AM UTC, comment #30: 

Actually on console, I get coredump by just starting and quitting octave. So perhaps it is something different.

Dmitri.

Dmitri A. Sergatskov <dasergatskov>
Sat 23 May 2020 01:53:34 AM UTC, comment #29: 

If I do this (e.g. run in console) I get crash with simplified
(parallel) test even with a few jobs.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Sat 23 May 2020 01:23:19 AM UTC, comment #28: 

I see some of those buildbot crashes are on some of my systems that are configured the same way as the system that I normally use to build and I wasn't seeing any crashes when I'm building Octave, so that seems odd.  Then I tried without a graphics display and make immediately and repeatably crashed for me when generating figures.  Running make with Xvfb avoided the problem.

The difference is that without the display available, I'm getting octave-cli.  But the stack trace attached to comment #25 appears to be for octave-gui, so now I'm just confused.

In any case, maybe I can at least fix the octave-cli crash...

John W. Eaton <jwe>
Project Administrator
Sat 23 May 2020 12:38:27 AM UTC, comment #27: 

OK.  The crash recorded in the stack trace from comment #25 looks much the same as the one I've seen before with the GUI thread calling QtHandles::qt_graphics_toolkit::create_object through a signal/slot connection but this time, the interpreter thread hasn't finished executing the --eval option code.  So maybe this is due to incorrect locking/unlocking of handle graphics objects between the GUI and interpreter threads?

John W. Eaton <jwe>
Project Administrator
Fri 22 May 2020 08:56:13 PM UTC, comment #26: 

all buildbots seems to be failing too

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Fri 22 May 2020 08:51:38 PM UTC, comment #25: 

The test passes for me too, but building docs still crashes:

 GEN      doc/interpreter/plot-uitoggletoolproperties.texi
  GEN      doc/interpreter/doc-cache
  GEN      doc/interpreter/voronoi.eps
  GEN      doc/interpreter/triplot.eps
  GEN      doc/interpreter/griddata.eps
fatal: caught signal Segmentation fault -- stopping myself...
  GEN      doc/interpreter/convhull.eps
  GEN      doc/interpreter/delaunay.eps
  GEN      doc/interpreter/inpolygon.eps
  GEN      doc/interpreter/interpft.eps
/bin/sh: line 1:  2828 Segmentation fault      (core dumped) /bin/sh run-octave --norc --silent --no-history --path ../doc/interpreter --eval "genpropdoc ('uitoolbar');" > doc/interpreter/plot-uitoolbarproperties.texi-t
make[2]: *** [Makefile:31018: doc/interpreter/plot-uitoolbarproperties.texi] Error 139
make[2]: *** Waiting for unfinished jobs....
make[2]: Leaving directory '/home/dima/src/octave/gcc_def'
make[1]: *** [Makefile:27418: all-recursive] Error 1
make[1]: Leaving directory '/home/dima/src/octave/gcc_def'
make: *** [Makefile:11053: all] Error 2

bt is attached, though not sure if it is too useful (compiled with def flags).

Dmitri.
--

(file #49147)

Dmitri A. Sergatskov <dasergatskov>
Fri 22 May 2020 08:28:20 PM UTC, comment #24: 

I pushed the following changeset

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 described here in the maintainers mailing list thread here:

https://lists.gnu.org/archive/html/octave-maintainers/2020-05/msg00091.html

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}

John W. Eaton <jwe>
Project Administrator
Sat 16 Nov 2019 06:24:16 AM UTC, comment #23: 

Hmm.  Still failing on the Fedora buildbot...

John W. Eaton <jwe>
Project Administrator
Sat 16 Nov 2019 05:54:22 AM UTC, comment #22: 

I backed out two previous changesets here:

  http://hg.savannah.gnu.org/hgweb/octave/rev/5e8891dceec7

and pushed this simpler change:

  http://hg.savannah.gnu.org/hgweb/octave/rev/f65b1666e650

I still don't think this is a complete fix, or that it will always avoid problems, and am still struggling a bit with how to properly close the interpreter and release all resources.

John W. Eaton <jwe>
Project Administrator
Fri 15 Nov 2019 06:53:26 PM UTC, comment #21: 

Oops, I just noticed that the unwind_action that I added in the patch attached to comment #20 doesn't have a variable attached to it, so it is not being executing at the correct time.  Doh.  I'm looking at a possible better solution now and will post another attempt at a fix soon.

John W. Eaton <jwe>
Project Administrator
Fri 15 Nov 2019 04:12:21 PM UTC, comment #20: 

I pushed the following changeset:

  https://hg.savannah.gnu.org/hgweb/octave/rev/cdb681adc85a

I can't say for sure that this fixes everything (let's wait for a few trips through the buildbots first) but on a system that was reliably failing with make -j9, I haven't seen any further segfaults.

John W. Eaton <jwe>
Project Administrator
Wed 16 Oct 2019 12:36:11 AM UTC, comment #19: 

I still sometimes see segfaults but from examining core files, they seem happening in other places.  It looks to me like there are issues with the sequence of events that happen in the interpreter destructor.  I'm not sure how to fix that yet.  I'm out of time right now but will try to describe the problem tomorrow.

John W. Eaton <jwe>
Project Administrator
Wed 16 Oct 2019 12:26:22 AM UTC, comment #18: 
Dmitri A. Sergatskov <dasergatskov>
Wed 16 Oct 2019 12:11:02 AM UTC, comment #17: 

Oops, that last comment was meant for bug #50025.

John W. Eaton <jwe>
Project Administrator
Wed 16 Oct 2019 12:10:01 AM UTC, comment #16: 

I'm also seeing a crash at exit when executing a script file (related to bug #56952, it seems) that also appears to be "fixed" by not connecting m_interpreter_qobj->octave_finished_signal to m_main_thread->quit and making the call to m_main_thread->quit directly in the base_qobject::handle_octave_finished function.

Printing "\n" to stderr doesn't seem to be needed.  What does that do on MacOS?  Is it needed to actually print the newline at exit?

In any case, it looks like there is some general call sequence and threading issue here.  I pushed the following changeset:

  http://hg.savannah.gnu.org/hgweb/octave/rev/1a4defb4dfc2

John W. Eaton <jwe>
Project Administrator
Wed 16 Oct 2019 12:09:48 AM UTC, comment #15: 

As part of the fix for this problem, I pushed the following changeset:

  http://hg.savannah.gnu.org/hgweb/octave/rev/1a4defb4dfc2

See also bug #50025

John W. Eaton <jwe>
Project Administrator
Sat 12 Oct 2019 10:09:12 PM UTC, comment #14: 

You can see fedora buildbots are failing most of the time now days due to the same problem. The actual file varies time to time

http://buildbot.octave.org:8010/#/builders

It used to be that clang-fedora has this problem sporadically.
Now it got much worse -- not sure if it is due to
OS update or changes in octave.

Dmitri.

Dmitri A. Sergatskov <dasergatskov>
Sat 12 Oct 2019 08:58:27 PM UTC, comment #13: 

Just restarted a complete new build due to a fix in configure.ac. Here is what I get:

  CXXLD    src/octave-cli
  GEN      src/octave-cli-6.0.0
  CXXLD    src/octave-gui
  GEN      src/octave-gui-6.0.0
  GEN      doc/interpreter/voronoi.txt
  GEN      doc/interpreter/triplot.txt
  GEN      doc/interpreter/griddata.txt
  GEN      doc/interpreter/convhull.txt
  GEN      doc/interpreter/delaunay.txt
  GEN      doc/interpreter/inpolygon.txt
  GEN      doc/interpreter/interpft.txt
  GEN      doc/interpreter/interpn.txt
fatal: caught signal Segmentation fault -- stopping myself...
/bin/sh: line 1: 19301 Segmentation fault      (core dumped) /bin/sh run-octave --norc --silent --no-history --path /home/philip/devel/octdev/oct600+/../dev_p/doc/interpreter/ --eval "geometryimages ('doc/interpreter/', 'griddata', 'txt');"
make[2]: *** [Makefile:31191: doc/interpreter/griddata.txt] Error 139
make[2]: *** Waiting for unfinished jobs....
make[2]: Leaving directory '/home/philip/devel/octdev/oct600+'
make[1]: *** [Makefile:27402: all-recursive] Error 1
make[1]: Leaving directory '/home/philip/devel/octdev/oct600+'
make: *** [Makefile:11034: all] Error 2
[philip@lx230 oct600+]$

... so it's actually the 8th .txt file where things go wrong. But further down it's .png and .texi files, unless make is restarted with just one job.

Does "Category" need to be set to "Configuration and build system" ?

Philip Nienhuis <philipnienhuis>
Project Member
Sat 12 Oct 2019 07:48:02 PM UTC, comment #12: 

FWIW, I've been seeing this, or something like this, for many months, completely reproducibly, after starting a completely fresh build with "make -jx" where x = 4 or 5, and always in the stage of (AFAIU) generating the figures for the docs. Usually the crash happens after the second or third figure.

Restarting with make -j1 solves it (AFAICS at that stage of the build there's not much gain anymore in using -j4).

I didn't bother as:

  • I figured it was an issue on my boxes (maybe "make -j4' is too much for an older core i5)
  • I start a new build tree only every other month or so
  • restarting with make or "make -j1" reliably solved it
  • ensuing cross-builds always went fine.

(Mageia 6 and Mageia 7, core i5, 8 GB RAM)
(and on SSD drives. It once made me think of a bug report about (IIRC) (g)zip or unpack issues on very fast SSD drives. But obviously this is a very blind guess :-) )

Philip Nienhuis <philipnienhuis>
Project Member
Sat 12 Oct 2019 02:48:51 AM UTC, comment #11: 

Perhaps the following is more useful.
Compiled with -O0.
Start 


TSAN_OPTIONS=second_deadlock_stack=1 ./run-octave -q-f

(saved output to o_start_O0_thread.txt)
and quit (o_quit_O0_thread.txt)

Dmitri.

(file #47655, file #47656)

Dmitri A. Sergatskov <dasergatskov>
Sat 12 Oct 2019 12:41:18 AM UTC, comment #10: 

Here is my try with

../configure CFLAGS="-ggdb3 -O2 -fsanitize=thread" CXXFLAGS="-ggdb3 -O2 -fsanitize=thread"  FFLAGS="-ggdb3 -O2 -fsanitize=thread"

After the initial make -j4 crashed. I run
make V=1 > make_gcc_O2_tsan.txt and the output is attached.

Dmitri.

(file #47654)

Dmitri A. Sergatskov <dasergatskov>
Fri 11 Oct 2019 11:58:14 PM UTC, comment #9: 

If this is a threading issue, would running Octave with the thread sanitizer help with debugging?  Has anyone tried building Octave with -fsanitize=thread?

John W. Eaton <jwe>
Project Administrator
Thu 10 Oct 2019 05:29:12 PM UTC, comment #8: 

Hello, answering to comments #2 and #3, that request additional info:

  • What OS are you using?

Linux x86_64 on a slackware-current derivative:

uname -a returns this:

Linux porteus.example.net 5.2.14-porteus #1 SMP PREEMPT Sat Sep 14 21:57:21 CEST 2019 x86_64 Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz GenuineIntel GNU/Linux

  • What OpenGL driver in case you don't use the default MESA implementation?

mesa-19.1.7-x86_64-1 (from slackware-current)

  • Just to be sure, when you compile Octave from an hg repo, what branch do you use, stable (future 5.2) or default (future 6.1)?

the default branch, I tried again with a fresh clone downloaded on oct 8.

  • Does test.m also produce a crash from within an Octave session (not only when evaluated using --eval)? If so can you provide us with the stack trace of the crash:

    build/dir& ./run-octave -g
    (gdb) run
    octave:1> cd where/your/test_script/is/
    octave:2> test

My latest compilation does not crash with this stripped-down test.m, but it continue to crash with the full test set when it gets to the test file 'libinterp/corefcn/A_graphics.cc-tst' (remark test.m was a stripped-down version of the full test file).

I have attached the output of the debug run you indicated.

  • 1) What does 'hg id' return for the source directory you are using?

458adc344819 tip @

  • 2) Definitely rename "test.m" to something else (maybe "test56952.m") so that there is no oddness caused by the original test.m file in scripts/test.

Agreed, although not really relevant to this case. The relevant point is that crashes occur with original test 'libinterp/corefcn/A_graphics.cc-tst'.

I must add that when repeating that standard test several times in a row, from time to time it can go through without errors, but the following run gets wrong again.

I am myself clueless ...

(file #47642)

Anonymous
Fri 27 Sep 2019 11:09:43 PM UTC, comment #7: 

I'm also able to duplicate it sometimes but it is not reproducible.

John W. Eaton <jwe>
Project Administrator
Fri 27 Sep 2019 09:10:04 PM UTC, comment #6: 

I have seen very similar crashed. More often recently.
E.g. see all fedora buildbot crashes.
I also got them on my workstation(s).

After freashly built octave:

$ rm -rf doc/
$ make V=1 -j8
/bin/sh config.status oct-conf-post.h-tmp oct-conf-post.h
/bin/sh config.status liboctave/mk-version-h.sh-tmp liboctave/mk-version-h.sh
/bin/sh config.status libinterp/corefcn/mk-mxarray-h.sh-tmp libinterp/corefcn/mk-mxarray-h.sh
/bin/sh config.status build-aux/subst-script-vals.sh-tmp build-aux/subst-script-vals.sh
/usr/bin/mkdir -p doc/doxyhtml && \
: > doc/doxyhtml/.octave-dirstamp
/usr/bin/mkdir -p doc/interpreter && \
: > doc/interpreter/.octave-dirstamp
/usr/bin/mkdir -p doc/liboctave && \
: > doc/liboctave/.octave-dirstamp
/usr/bin/mkdir -p doc/refcard && \
: > doc/refcard/.octave-dirstamp
rm -f bits/stl_algo.h
config.status: creating liboctave/mk-version-h.sh-tmp
config.status: creating oct-conf-post.h-tmp
config.status: creating libinterp/corefcn/mk-mxarray-h.sh-tmp

<...deleted...>

config.status: executing build-aux/subst-script-vals.sh commands
/bin/sh run-octave --norc --silent --no-history --path /d2/home/dima/src/octave/gcc_def/../doc/interpreter/ --eval "interpimages ('doc/interpreter/', 'interpft', 'txt');"
/bin/sh run-octave --norc --silent --no-history --path /d2/home/dima/src/octave/gcc_def/../doc/interpreter/ --eval "interpimages ('doc/interpreter/', 'interpn', 'txt');"
/bin/sh run-octave --norc --silent --no-history --path /d2/home/dima/src/octave/gcc_def/../doc/interpreter/ --eval "interpimages ('doc/interpreter/', 'interpderiv1', 'txt');"
/bin/sh run-octave --norc --silent --no-history --path /d2/home/dima/src/octave/gcc_def/../doc/interpreter/ --eval "interpimages ('doc/interpreter/', 'interpderiv2', 'txt');"
/bin/sh run-octave --norc --silent --no-history --path /d2/home/dima/src/octave/gcc_def/../doc/interpreter/ --eval "plotimages ('doc/interpreter/', 'plot', 'txt');"
fatal: caught signal Segmentation fault -- stopping myself...
/bin/sh run-octave --norc --silent --no-history --path /d2/home/dima/src/octave/gcc_def/../doc/interpreter/ --eval "plotimages ('doc/interpreter/', 'hist', 'txt');"
/bin/sh run-octave --norc --silent --no-history --path /d2/home/dima/src/octave/gcc_def/../doc/interpreter/ --eval "plotimages ('doc/interpreter/', 'errorbar', 'txt');"
/bin/sh run-octave --norc --silent --no-history --path /d2/home/dima/src/octave/gcc_def/../doc/interpreter/ --eval "plotimages ('doc/interpreter/', 'polar', 'txt');"
/bin/sh run-octave --norc --silent --no-history --path /d2/home/dima/src/octave/gcc_def/../doc/interpreter/ --eval "plotimages ('doc/interpreter/', 'mesh', 'txt');"
make[2]: *** [Makefile:31205: doc/interpreter/convhull.txt] Segmentation fault (core dumped)
make[2]: *** Deleting file 'doc/interpreter/convhull.txt'
make[2]: *** Waiting for unfinished jobs....
make[2]: Leaving directory '/d2/home/dima/src/octave/gcc_def'
make[1]: *** [Makefile:27412: all-recursive] Error 1
make[1]: Leaving directory '/d2/home/dima/src/octave/gcc_def'
make: *** [Makefile:11034: all] Error 2

Attached is the trace as captured by system logger.

I wonder is the "hgsave weirdness" as discussed on maint list
is somewhat related to this as well.

Dmitri.

(file #47584)

Dmitri A. Sergatskov <dasergatskov>
Fri 27 Sep 2019 08:38:29 PM UTC, comment #5: 

Attaching a full backtrace from the segfault I showed in comment #4, if that helps anyone. At a glance, it looks to me like Qt objects are being deleted concurrently in 2 different threads, the Octave interpreter thread and the Qt event loop main thread.

(file #47583)

Mike Miller <mtmiller>
Project Administrator
Fri 27 Sep 2019 08:22:38 PM UTC, comment #4: 

I can reproduce this error, only occasionally, by deleting all generated files in doc/interpreter and running make again. I always build with 'make -jN' where N is 4 or 6 or 8.

Example output on my system with 'make -j6 V=1':

...
rm -f doc/interpreter/plot-rootproperties.texi-t doc/interpreter/plot-rootproperties.texi && /bin/bash run-octave --norc --silent --no-history --path ../doc/interpreter --eval "genpropdoc ('root');" > doc/interpreter/plot-rootproperties.texi-t && mv doc/interpreter/plot-rootproperties.texi-t doc/interpreter/plot-rootproperties.texi
rm -f doc/interpreter/plot-surfaceproperties.texi-t doc/interpreter/plot-surfaceproperties.texi && /bin/bash run-octave --norc --silent --no-history --path ../doc/interpreter --eval "genpropdoc ('surface');" > doc/interpreter/plot-surfaceproperties.texi-t && mv doc/interpreter/plot-surfaceproperties.texi-t doc/interpreter/plot-surfaceproperties.texi
rm -f doc/interpreter/plot-textproperties.texi-t doc/interpreter/plot-textproperties.texi && /bin/bash run-octave --norc --silent --no-history --path ../doc/interpreter --eval "genpropdoc ('text');" > doc/interpreter/plot-textproperties.texi-t && mv doc/interpreter/plot-textproperties.texi-t doc/interpreter/plot-textproperties.texi
rm -f doc/interpreter/plot-uimenuproperties.texi-t doc/interpreter/plot-uimenuproperties.texi && /bin/bash run-octave --norc --silent --no-history --path ../doc/interpreter --eval "genpropdoc ('uimenu');" > doc/interpreter/plot-uimenuproperties.texi-t && mv doc/interpreter/plot-uimenuproperties.texi-t doc/interpreter/plot-uimenuproperties.texi
fatal: caught signal Segmentation fault -- stopping myself...
rm -f doc/interpreter/plot-uibuttongroupproperties.texi-t doc/interpreter/plot-uibuttongroupproperties.texi && /bin/bash run-octave --norc --silent --no-history --path ../doc/interpreter --eval "genpropdoc ('uibuttongroup');" > doc/interpreter/plot-uibuttongroupproperties.texi-t && mv doc/interpreter/plot-uibuttongroupproperties.texi-t doc/interpreter/plot-uibuttongroupproperties.texi
rm -f doc/interpreter/plot-uicontextmenuproperties.texi-t doc/interpreter/plot-uicontextmenuproperties.texi && /bin/bash run-octave --norc --silent --no-history --path ../doc/interpreter --eval "genpropdoc ('uicontextmenu');" > doc/interpreter/plot-uicontextmenuproperties.texi-t && mv doc/interpreter/plot-uicontextmenuproperties.texi-t doc/interpreter/plot-uicontextmenuproperties.texi
rm -f doc/interpreter/plot-uipanelproperties.texi-t doc/interpreter/plot-uipanelproperties.texi && /bin/bash run-octave --norc --silent --no-history --path ../doc/interpreter --eval "genpropdoc ('uipanel');" > doc/interpreter/plot-uipanelproperties.texi-t && mv doc/interpreter/plot-uipanelproperties.texi-t doc/interpreter/plot-uipanelproperties.texi
rm -f doc/interpreter/plot-uicontrolproperties.texi-t doc/interpreter/plot-uicontrolproperties.texi && /bin/bash run-octave --norc --silent --no-history --path ../doc/interpreter --eval "genpropdoc ('uicontrol');" > doc/interpreter/plot-uicontrolproperties.texi-t && mv doc/interpreter/plot-uicontrolproperties.texi-t doc/interpreter/plot-uicontrolproperties.texi
/bin/bash: line 1:  1278 Segmentation fault      (core dumped) /bin/bash run-octave --norc --silent --no-history --path ../doc/interpreter --eval "genpropdoc ('root');" > doc/interpreter/plot-rootproperties.texi-t
make[2]: *** [Makefile:31001: doc/interpreter/plot-rootproperties.texi] Error 139
make[2]: *** Waiting for unfinished jobs....

On my system it is not reproducible every time, and it is not a blocker, it's an annoyance. Restarting the build usually succeeds.

Debian testing, x86_64, Intel integrated graphics with Mesa 19.1.6. And this is from an up to date clone of the default branch.

Mike Miller <mtmiller>
Project Administrator
Fri 27 Sep 2019 04:18:47 PM UTC, comment #3: 

Adding two points to comment #2

1) What does 'hg id' return for the source directory you are using?

2) Definitely rename "test.m" to something else (maybe "test56952.m") so that there is no oddness caused by the original test.m file in scripts/test.

Rik <rik5>
Project Administrator
Thu 26 Sep 2019 01:27:50 PM UTC, comment #2: 

This works for me on default as well as with Octave 5.1. I have a few questions:

  • What OS are you using?
  • What OpenGL driver in case you don't use the default MESA implementation?
  • Just to be sure, when you compile Octave from an hg repo, what branch do you use, stable (future 5.2) or default (future 6.1)?
  • Does test.m also produce a crash from within an Octave session (not only when evaluated using --eval)? If so can you provide us with the stack trace of the crash:

build/dir& ./run-octave -g
(gdb) run
octave:1> cd where/your/test_script/is/
octave:2> test

BTW, test.m already exists in Octave sources so renaming yours to mytest.m would not hurt in preventing oddities.

I changed the category to "Plotting with OpenGL".

Pantxo Diribarne <pantxo>
Project Member
Wed 25 Sep 2019 11:26:05 PM UTC, comment #1: 

An update that focuses the problem (now I would say it is a run-time problem, not a compile problem):

Adding --disable-docs the lines that crashed on my iniital report are skipped and I can complete compilation. However the resulting binaries crashed at some tests, in particular ibinterp/corefcn/graphics.cc-tst

We may reproduce the crash running manually octave against a simplified test, for example:

octave --norc test.m

with test.m:

hf = figure ("visible", "off");
set (gca (), "xticklabel", [0, 0.2, 0.4, 0.6, 0.8, 1]);
xticklabel = get (gca (), "xticklabel");
close (hf);
assert (class (xticklabel), "char");
assert (size (xticklabel), [6, 3]);

No crash is produced commenting out the lines with the hf handle.

This test is ok with octave 5.1.0 compiled on the same environment.

Anonymous
Wed 25 Sep 2019 06:31:15 PM UTC, original submission:  

Hello,

During compilation on a fresh x86_64 i7 environment, I am consistently getting a segmentation fault, always at the same point:

  GEN      doc/interpreter/plot-axesproperties.texi
fatal: caught signal Segmentation fault -- stopping myself...
/bin/sh: line 1: 23107 Segmentation fault      /bin/sh run-octave --norc --silent --no-history --path ../doc/interpreter --eval "genpropdoc ('axes');" > doc/interpreter/plot-axesproperties.texi-t
make[2]: *** [Makefile:30949: doc/interpreter/plot-axesproperties.texi] Error 139
make[2]: Leaving directory '/tmp/SBo/octave-hg/.build'
make[1]: *** [Makefile:27397: all-recursive] Error 1
make[1]: Leaving directory '/tmp/SBo/octave-hg/.build'
make: *** [Makefile:11030: all] Error 2

I can reproduce the crash by running manually the faulty line from the .build directory:

/bin/sh run-octave --norc --silent --no-history --path ../doc/interpreter --eval "genpropdoc ('axes');"

The same happens on a 32-bit environment (under VritualBox), but at a later line.
I tried different snapshots that I keep and the exact line they crash varies, but it is allways with some --eval "genpropdoc('something');".
Sometimes, running the crashing line manually several times can give a successful run or a crash, randomly.

Any idea?

I have attached the config report for x86_64.

Anonymous

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #49147:  bt_20200522.txt.gz added by dasergatskov (3KiB - application/gzip)
file #47642:  test.dbg added by None (6KiB - application/octet-stream)
file #47584:  das_crash.txt added by dasergatskov (18KiB - text/plain)
file #47583:  backtrace.txt added by mtmiller (32KiB - text/plain)
file #47573:  bug-config added by None (8KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by dasergatskov (Updated the item)
  • -email is unavailable- added by pantxo (Posted a comment)
  • -email is unavailable- added by None (Submitted the item)
  •  

    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 17 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-09-14 mmuetzel StatusReady For Test => Fixed
        Open/ClosedOpen => Closed
    2020-06-07 mmuetzel Severity3 - Normal => 5 - Blocker
        Releasedev => 6.0.90
    2020-05-22 dasergatskov Attached File- => Added bt_20200522.txt.gz, #49147
    2020-05-22 jwe StatusConfirmed => Ready For Test
    2019-10-12 pantxo StatusWorks For Me => Confirmed
    2019-10-12 dasergatskov Attached File- => Added o_start_O0_thread.txt, #47655
        Attached File- => Added o_quit_O0_thread.txt, #47656
    2019-10-12 dasergatskov Attached File- => Added make_gcc_O2_tsan.txt, #47654
    2019-10-10 rik5 Carbon-CopyRemoved 72865 => -
    2019-10-10 None Attached File- => Added test.dbg, #47642
    2019-09-27 dasergatskov Attached File- => Added das_crash.txt, #47584
    2019-09-27 mtmiller Attached File- => Added backtrace.txt, #47583
    2019-09-26 pantxo CategoryConfiguration and Build System => Plotting with OpenGL
        StatusNone => Works For Me
    2019-09-25 None Attached File- => Added bug-config, #47573

    Back to the top


    Powered by Savane 3.5