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:  3 - Normal
Priority:  5 - Normal Item Group:  Segfault, Bus Error, etc.
Status:  Confirmed Assigned to:  None
Originator Name:  R.S.Carmenes Originator Email:  -email is unavailable-
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)

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 #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 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 11 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    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