From help-octave-request at bevo dot che dot wisc dot edu Fri Dec 19 06:21:12 2003
Subject: Investigating delaunay() segfault
From: Solignac <solignac at altern dot org>
To: help-octave <help-octave at bevo dot che dot wisc dot edu>
Date: Fri, 19 Dec 2003 13:15:02 +0100

Hi,

  I've encountered several octave crashes using Delaunay's triangulation
(qhull).

   Arch: Debian GNU/Linux 3.0r2 (ix86)
 Octave: 2.1.50 compiled from source (--enable-shared flag)
  Qhull: latest version (2002) compiled from source

  delaunayn.oct is built against libqhull.

  I've a rather small set of 7400 points (X,Y,Z) exported from Surfer, I
would like to make triangulation in the (X,Y) plane, it's a row-by-row set
of this kind:

<<<<<
  X_0 Y_0 Z(0,0)
  X_0 Y_1 Z(0,1)
  ...
  X_0 Y_m Z(0,n)
  X_1 Y_0 Z(1,0)
  ...
  X_1 Y_m Z(1,m)
  ...

  ...
  X_n Y_0 Z(n,0)
  ...
  X_n Y_m Z(n,m)
>>>>>
  
  I've set up a small routine that loads the semi-colon separated data in
octave's matrices. The data loaded set seems ok (I can plot it, make few
operation between rows, ...) but when I try something like:

  tri = delaunay(X,Y) ;

I've something like:
<<<<<
  panic: Segmentation fault -- stopping myself...
  attempting to save variables to `octave-core'...
  save to `octave-core' complete
>>>>>

  Seems odd to me since processing the data set with qhull from the command
line does not segfaults.

  Running octave within gdb gave me:

<<<<<
  octave-2.1.50:1> tmp
  Program received signal SIGSEGV, Segmentation fault.
  0x40bb3742 in Fdelaunayn (args= at 0x8a0bcd8) at delaunayn.cc:106
  106           FORALLfacets {
  Current language:  auto; currently c++
>>>>>

  Ok I know that's not enough to investigate, I'd like to know now:

   - is this a "known bug" of delaunay()/qhull function dealing with large
     data sets; the crashes are not fully reproductible: sometimes the
     triangulation of a smaller subset works, sometimes not; Matlab's 5.3
     delaunay() succeeds in the triangulation so it does not seem to be
     data-related,

   - does the points ordering in the delaunay() input matters (not on the
     algorithm side but for its implementation),

   - what could I do to investigate a little bit more; I've few skills in
     C++ (but what I really lack at the moment is time).

  The README files from octave's tarball say that gcc3 is needed to build
octave, but all went fine with Debian's one (2.95.x), and several messages
on the list also report it working... Could gcc's version be related to he
crashes? 

  Any help on the subject is welcome ;o)

\bye

-- 
 Let's call it an accidental feature.
  -- Larry Wall



-------------------------------------------------------------
Octave is freely available under the terms of the GNU GPL.

Octave's home on the web:  http://www.octave.org
How to fund new projects:  http://www.octave.org/funding.html
Subscription information:  http://www.octave.org/archive.html
-------------------------------------------------------------