bugGNU Octave - Bugs: bug #57529, Crash with qhull v7.3.2 (2019.1)

 
 

bug #57529: Crash with qhull v7.3.2 (2019.1)

Submitted by:  Guillaume <gyom>
Submitted on:  Fri 03 Jan 2020 05:04:59 PM UTC  
 
Category:  Octave Function Severity:  2 - Minor
Priority:  3 - Low Item Group:  Segfault, Bus Error, etc.
Status:  Invalid Assigned to:  None
Originator Name:  Guillaume Open/Closed:  Closed
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)

Wed 08 Jan 2020 02:08:41 AM UTC, comment #18: 

@Guillaume: Is there anything left to be done/checked?  Then I close this item as invalid and Octave can happily survive the new qhull version ;-)

Off topic: I also experienced some trouble with the science repository and incompatible library versions last year and decided to stay "vanilla" with openSUSE 15.1.  I build the few required newer library versions myself.

Kai Torben Ohlhus <siko1056>
Project Member
Tue 07 Jan 2020 04:58:13 PM UTC, comment #17: 

Many thanks, I managed to build qhull from source with debugging symbols (jumping through a few more hoops than you...) and it worked fine with it. This made me realize the issue, which was as you predicted: a mismatch version between the Qhull libraries (7.2.0) and header files (7.3.2) in the installed packages. I'm not sure to understand how my system ended up like this but I must have missed something during my last upgrade or when I switched vendors (for the "science" repository). For future reference, the two libraries that must match are qhull-devel and libqhull*-*_*_*.

Guillaume <gyom>
Tue 07 Jan 2020 04:28:42 PM UTC, comment #16: 

I built a copy of qhull 2019.1 from source and initially had some strange crashes.  When I looked at the data in gdb it looked fine, but then would crash with segfaults while looping over vertices.

Then I noticed that the layouts of some internal structures like the global qh_qh object that we use (struct qhT in libqhull.h) have changed and I was trying to just use the new libqhull.so that I built as a drop-in replacement with my already built copy of Octave that was compiled with an older version of Qhull.  But that won't work because the structure layouts have changed.  So you must rebuild and execute with a consistent set of Qhull libraries and header files.  Once I did that, it seems to work properly again.

The functions that use Qhull are .oct files, so those must be rebuilt and linked with the correct and consistent version of Qhull headers and libraries.

Of course there may be other issues, but I'm currently unable to duplicate the crash.

If you can build Qhull with debugging symbols can you also try without the address sanitizer and instead just use gdb and get a stack trace at the point of the segfault?

I build Qhull with debugging symbols using

cd qhull-2019.1/build
cmake -DCMAKE_INSTALL_PREFIX=/home/jwe/build/qhull -DCMAKE_BUILD_TYPE=Debug ..
make
make install

and then built and executed Octave with

LD_LIBRARY_PATH=/home/jwe/build/qhull/lib /path/to/configure ... CPPFLAGS="-I/home/jwe/build/qhull/include" LDFLAGS="-L/home/jwe/build/qhull/lib"

LD_LIBRARY_PATH=/home/jwe/build/qhull/lib ./run-octave

John W. Eaton <jwe>
Project Administrator
Tue 07 Jan 2020 03:59:10 PM UTC, comment #15: 

Can you build the qhull library with debugging symbols so we can know exactly where in qh_setsize it is failing?

John W. Eaton <jwe>
Project Administrator
Tue 07 Jan 2020 10:26:59 AM UTC, comment #14: 

Here is the stacktrace I obtain when calling voronoi:

octave:1> x = rand (10, 1); y = rand (10, 1); tri = delaunay (x, y);
octave:2> [vx, vy] = voronoi (x, y, tri);
ASAN:DEADLYSIGNAL
=================================================================
==23063==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7fb0544642e7 bp 0x7fb056d995d0 sp 0x7fb056d98c78 T18)
==23063==The signal is caused by a READ memory access.
==23063==Hint: address points to the zero page.
    #0 0x7fb0544642e6 in qh_setsize (/usr/lib64/libqhull.so.7+0x312e6)
    #1 0x7fb054177a06 in F__voronoi__(octave_value_list const&, int) ../libinterp/dldfcn/__voronoi__.cc:199
    #2 0x7fb0a422360d in octave_builtin::call(octave::tree_evaluator&, int, octave_value_list const&) ../libinterp/octave-value/ov-builtin.cc:66
    #3 0x7fb0a4667608 in octave::tree_index_expression::evaluate_n(octave::tree_evaluator&, int) ../libinterp/parse-tree/pt-idx.cc:522
    #4 0x7fb0a45f69cb in octave::tree_multi_assignment::evaluate_n(octave::tree_evaluator&, int) ../libinterp/parse-tree/pt-assign.cc:202
    #5 0x7fb0a45fa685 in octave::tree_multi_assignment::evaluate(octave::tree_evaluator&, int) (/octave/dbg-octave/libinterp/.libs/liboctinterp.so.7+0x1777685)
    #6 0x7fb0a46247e9 in octave::tree_evaluator::visit_statement(octave::tree_statement&) ../libinterp/parse-tree/pt-eval.cc:2761
    #7 0x7fb0a4683fa8 in octave::tree_statement::accept(octave::tree_walker&) ../libinterp/parse-tree/pt-stmt.h:125
    #8 0x7fb0a4624dae in octave::tree_evaluator::visit_statement_list(octave::tree_statement_list&) ../libinterp/parse-tree/pt-eval.cc:2820
    #9 0x7fb0a415f262 in octave::tree_statement_list::accept(octave::tree_walker&) ../libinterp/parse-tree/pt-stmt.h:202
    #10 0x7fb0a46227a5 in octave::tree_evaluator::execute_user_function(octave_user_function&, int, octave_value_list const&, octave::stack_frame*) ../libinterp/parse-tree/pt-eval.cc:2481
    #11 0x7fb0a43ffae9 in octave_user_function::call(octave::tree_evaluator&, int, octave_value_list const&, octave::stack_frame*) ../libinterp/octave-value/ov-usr-fcn.cc:468
    #12 0x7fb0a4406f07 in octave_user_function::call(octave::tree_evaluator&, int, octave_value_list const&) ../libinterp/octave-value/ov-usr-fcn.h:380
    #13 0x7fb0a4667608 in octave::tree_index_expression::evaluate_n(octave::tree_evaluator&, int) ../libinterp/parse-tree/pt-idx.cc:522
    #14 0x7fb0a45f69cb in octave::tree_multi_assignment::evaluate_n(octave::tree_evaluator&, int) ../libinterp/parse-tree/pt-assign.cc:202
    #15 0x7fb0a45fa685 in octave::tree_multi_assignment::evaluate(octave::tree_evaluator&, int) (/octave/dbg-octave/libinterp/.libs/liboctinterp.so.7+0x1777685)
    #16 0x7fb0a46247e9 in octave::tree_evaluator::visit_statement(octave::tree_statement&) ../libinterp/parse-tree/pt-eval.cc:2761
    #17 0x7fb0a4683fa8 in octave::tree_statement::accept(octave::tree_walker&) ../libinterp/parse-tree/pt-stmt.h:125
    #18 0x7fb0a4624dae in octave::tree_evaluator::visit_statement_list(octave::tree_statement_list&) ../libinterp/parse-tree/pt-eval.cc:2820
    #19 0x7fb0a415f262 in octave::tree_statement_list::accept(octave::tree_walker&) ../libinterp/parse-tree/pt-stmt.h:202
    #20 0x7fb0a461073f in octave::tree_evaluator::eval(std::shared_ptr<octave::tree_statement_list>&, bool) ../libinterp/parse-tree/pt-eval.cc:403
    #21 0x7fb0a4e671a7 in octave::interpreter::main_loop() ../libinterp/corefcn/interpreter.cc:1138
    #22 0x7fb0a4e634f8 in octave::interpreter::execute() ../libinterp/corefcn/interpreter.cc:800
    #23 0x7fb0a5f82733 in octave::interpreter_qobject::execute() ../libgui/src/interpreter-qobject.cc:88
    #24 0x7fb0a62184de in octave::interpreter_qobject::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) libgui/src/moc-interpreter-qobject.cc:88
    #25 0x7fb0a0593a41 in QObject::event(QEvent*) (/usr/lib64/libQt5Core.so.5+0x2b1a41)
    #26 0x7fb0a12f5e8b in QApplicationPrivate::notify_helper(QObject*, QEvent*) (/usr/lib64/libQt5Widgets.so.5+0x16be8b)
    #27 0x7fb0a12fd243 in QApplication::notify(QObject*, QEvent*) (/usr/lib64/libQt5Widgets.so.5+0x173243)
    #28 0x7fb0a608258b in octave::octave_qapplication::notify(QObject*, QEvent*) ../libgui/src/octave-qobject.cc:133
    #29 0x7fb0a0565a87 in QCoreApplication::notifyInternal2(QObject*, QEvent*) (/usr/lib64/libQt5Core.so.5+0x283a87)
    #30 0x7fb0a0568074 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) (/usr/lib64/libQt5Core.so.5+0x286074)
    #31 0x7fb0a05bc582  (/usr/lib64/libQt5Core.so.5+0x2da582)
    #32 0x7fb0944fff06 in g_main_context_dispatch (/usr/lib64/libglib-2.0.so.0+0x4df06)
    #33 0x7fb0945002af  (/usr/lib64/libglib-2.0.so.0+0x4e2af)
    #34 0x7fb09450033b in g_main_context_iteration (/usr/lib64/libglib-2.0.so.0+0x4e33b)
    #35 0x7fb0a05bbbfe in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) (/usr/lib64/libQt5Core.so.5+0x2d9bfe)
    #36 0x7fb0a0564099 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) (/usr/lib64/libQt5Core.so.5+0x282099)
    #37 0x7fb0a03934d9 in QThread::exec() (/usr/lib64/libQt5Core.so.5+0xb14d9)
    #38 0x7fb0a03980cd  (/usr/lib64/libQt5Core.so.5+0xb60cd)
    #39 0x7fb0968af568 in start_thread (/lib64/libpthread.so.0+0x7568)
    #40 0x7fb0965e6a2e in __GI___clone (/lib64/libc.so.6+0xf8a2e)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV (/usr/lib64/libqhull.so.7+0x312e6) in qh_setsize
Thread T18 (QThread) created by T0 here:
    #0 0x7fb0a67b0c80 in pthread_create (/usr/lib64/libasan.so.4+0x39c80)
    #1 0x7fb0a0397615 in QThread::start(QThread::Priority) (/usr/lib64/libQt5Core.so.5+0xb5615)

==23063==ABORTING

Guillaume <gyom>
Tue 07 Jan 2020 10:01:57 AM UTC, comment #13: 

@Kai: Thanks for looking into this. I am indeed using the "science"-repository. Following your suggestion, I started again a clean build and was expecting to confirm your findings but I still reproduce the issue 100% of the time.

octave:1> x = -3:0.05:3; y = abs (sin (x)); k = convhull (x, y);
error: =: nonconformant arguments (op1 is 1x1, op2 is 358x1)
error: called from
    convhull at line 158 column 14
octave:2> x = rand (10, 1); y = rand (10, 1); tri = delaunay (x, y); [vx, vy] = voronoi (x, y, tri);
fatal: caught signal Segmentation fault -- stopping myself...
Segmentation fault (core dumped)

I am still not ruling out a specific issue on my machine(s) but I will try to run the debugger and get a stacktrace as suggested by Rik.

Information for package qhull:
------------------------------
Repository     : science
Name           : qhull
Version        : 2019.1-lp150.6.1
Arch           : x86_64
Vendor         : obs://build.opensuse.org/science
Installed Size : 3.5 MiB
Installed      : Yes
Status         : up-to-date
Source package : qhull-2019.1-lp150.6.1.src
Summary        : Computing convex hulls, Delaunay triangulations and Voronoi diagrams

Guillaume <gyom>
Tue 07 Jan 2020 07:01:23 AM UTC, comment #12: 

I had to upgrade to Fedora 31 on the weekend. I had also a segfault when calling geometryimages. But it did segfault when calling figure(). Also segfaults when i did call figure() in a ./run-octave shell. I completed the make by changing the graphicstoolkit to fltk. After installation and reboot i wasn't able to reproduce any segfaults at all (since two days now).

Don't know if this info causes more confusion ...

Hg200 <hg200>
Tue 07 Jan 2020 05:44:57 AM UTC, comment #11: 

There were some runs when the statements of comment #9 and comment #0 worked without crash and did no longer trust my findings.

I started over with a clean build of all Octave 6 and now I find myself in the total opposite front of 0% reproduce ability for comment #9.  Thus lowering the priority again.  Build problems with the doc seems to refer to bug #56952, as comment #0 is not the reason for crashes.

I confirm, that my openSUSE 15.1 has "qhull", "qhull-devel" on version 2019.1-lp150.6.1, with no other upgrades from the "science"-repo. All oct-files using qhull are linking to that shared library.

@Guillaume: Does a clean built tree work for you or do you see problems, when running the content of "geometryimages()" manually?

Kai Torben Ohlhus <siko1056>
Project Member
Tue 07 Jan 2020 04:24:19 AM UTC, comment #10: 

Can you run under a debugger and get a backtrace?

Also, seems like the ChangeLog for Qhull version 7.3.X should be checked.  Maybe they changed the calling API.

Rik <rik5>
Project Administrator
Tue 07 Jan 2020 04:20:27 AM UTC, comment #9: 

With the recent qhull-library version v7.3.2 (2019.1), I can confirm this 100% crash of comment #0.

I renamed this bug report and maybe others with more recent versions of qhull can confirm this too.

>> x = -3:0.05:3; y = abs (sin (x)); k = convhull (x, y);
fatal: caught signal Segmentation fault -- stopping myself...
Segmentation fault (core dumped)

Kai Torben Ohlhus <siko1056>
Project Member
Tue 07 Jan 2020 03:56:24 AM UTC, comment #8: 

Guillaume, I think you are using openSUSE's the "science"-repository, right?  Without it, I have like Dmitri an even older version installed:

qhull-2015-src-7.2.0.tgz (a.k.a. 2015.2 https://github.com/qhull/qhull/releases)

Thus I cannot reproduce the 100% failure of your comment #0 with this version of qhull.

Maybe this is an upstream issue that will show up for Octave very soon, as all distributions are going to this version with their upcoming releases =(

But things are still not fine with me neither, suffering from bug #56952 with openSUSE, like the Fedora users.

Kai Torben Ohlhus <siko1056>
Project Member
Mon 06 Jan 2020 04:56:24 PM UTC, comment #7: 

On Fedora qhull is older:

qhull

qhull- compute convex hulls and related structures.  Qhull 2015.2.r 2016/01/18

rpm -qi qhull.x86_64
Name        : qhull
Epoch       : 1
Version     : 7.2.1
Release     : 2.fc31

...

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Mon 06 Jan 2020 04:47:08 PM UTC, comment #6: 

Sorry if I've been unclear. QHull is installed on my machine (2019.1-lp150.6.1) and detected by configure:

checking libqhull/libqhull.h usability... yes
checking libqhull/libqhull.h presence... yes
checking for libqhull/libqhull.h... yes
checking for qh_qhull in -lqhull... yes
checking for qh_version in -lqhull... yes
checking whether the qhull library works... yes

I copy Kai into this report as he is also using openSUSE and could therefore perhaps comment whether he is observing the same issue than me.

Guillaume <gyom>
Mon 06 Jan 2020 03:52:16 PM UTC, comment #5: 

This sounds like it is machine or OS specific.

A build machine for Octave which will produce a distributable tar.gz file is expected to have basic prerequisites like QHull.

There is a test for that, but it is only tested if the user tries to make a distribution using 'make dist'.  The code is in doc/libinterp/module.mk

# Prevent packaging of distribution unless all libraries
# necessary to create documentation are present
doc-interpreter-dist-hook:
        @$(GREP) '#define HAVE_COLAMD 1' $(top_builddir)/config.h > /dev/null || { echo "Documentation creation requires missing COLAMD library.  Cannot package distribution!" ; exit 1; }
        @$(GREP) '#define HAVE_CHOLMOD 1' $(top_builddir)/config.h > /dev/null || { echo "Documentation creation requires missing CHOLMOD library.  Cannot package distribution!" ; exit 1; }
        @$(GREP) '#define HAVE_UMFPACK 1' $(top_builddir)/config.h > /dev/null || { echo "Documentation creation requires missing UMFPACK library.  Cannot package distribution!" ; exit 1; }
        @$(GREP) '#define HAVE_QHULL 1' $(top_builddir)/config.h > /dev/null || { echo "Documentation creation requires missing QHULL library.  Cannot package distribution!" ; exit 1; }
        @$(GREP) '#define HAVE_QT_OFFSCREEN 1' $(top_builddir)/config.h > /dev/null || { echo "Documentation creation requires Qt offscreen OpenGL rendering.  Cannot package distribution!" ; exit 1; }

Perhaps we should move these tests in to configure somehow so that if the required libraries are not available it acts as if "--disable-doc" was given.

Rik <rik5>
Project Administrator
Mon 06 Jan 2020 10:55:44 AM UTC, comment #4: 

@Dmitri: Yes, it also happen when I execute interactively the relevant code from geometryimages. That's why I think this issue is in relation with the qhull library and this report should be retitled to reflect it's not directly related to building the documentation.

Guillaume <gyom>
Mon 06 Jan 2020 10:18:01 AM UTC, comment #3: 

Does it happen with serial make ("make -j1")?

Dmitri.

Dmitri A. Sergatskov <dasergatskov>
Mon 06 Jan 2020 10:13:24 AM UTC, comment #2: 

This happens 100% of the time. I thought this was similar to what you reported here last year:
https://lists.gnu.org/archive/html/octave-maintainers/2019-12/msg00094.html
but it doesn't seem to be the case. Instead I now suspect a specific issue with openSUSE and the qhull library. I notice that the packaged version of octave (5.1.0) for that distribution was not built with qhull (error: convhulln/__delaunayn__: support for Qhull was unavailable or disabled when Octave was built) so maybe it's a known issue.

Guillaume <gyom>
Sun 05 Jan 2020 11:45:43 PM UTC, comment #1: 

Is this 100% repeatable, or does it sometimes pass / sometimes fail?

Rik <rik5>
Project Administrator
Fri 03 Jan 2020 05:04:59 PM UTC, original submission:  

I think it was mentioned recently in a mailing list but cannot find a bug report for it: I observe reproducible crashes when building the documentation, during the creation of the voronoi and convhull images:

octave:2> geometryimages ('doc/interpreter','voronoi','eps')
fatal: caught signal Segmentation fault -- stopping myself...
Segmentation fault (core dumped)

octave:3> geometryimages ('doc/interpreter','convhull','eps')
error: =: nonconformant arguments (op1 is 1x1, op2 is 175x1)
error: called from
    convhull at line 154 column 14
    geometryimages at line 76 column 7

They have in common that they both rely on Qhull; the version installed on my system is 2019.1-lp150.6.1.

Guillaume <gyom>

 

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

Attach Files:
   
   
Comment:
   

No files currently attached

 

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 hg200 (Posted a comment)
  • -email is unavailable- added by siko1056 (Posted a comment)
  • -email is unavailable- added by gyom
  • -email is unavailable- added by dasergatskov (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by gyom (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 14 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-01-08 siko1056 StatusNeed Info => Invalid
        Open/ClosedOpen => Closed
    2020-01-07 siko1056 Severity4 - Important => 2 - Minor
        Priority5 - Normal => 3 - Low
        StatusConfirmed => Need Info
    2020-01-07 siko1056 StatusNeed Info => Confirmed
    2020-01-07 siko1056 Severity3 - Normal => 4 - Important
        Priority3 - Low => 5 - Normal
    2020-01-07 siko1056 CategoryConfiguration and Build System => Octave Function
        SummaryError when building documentation with voronoi and convhull => Crash with qhull v7.3.2 (2019.1)
    2020-01-06 gyom Carbon-Copy- => Added siko1056
    2020-01-06 rik5 CategoryNone => Configuration and Build System
        Priority5 - Normal => 3 - Low
    2020-01-05 rik5 StatusNone => Need Info

    Back to the top


    Powered by Savane 3.5