From help-octave-request at bevo dot che dot wisc dot edu Fri Dec 19 10:30:31 2003 Subject: Re: Investigating delaunay() segfault From: Dirk Eddelbuettel To: Solignac Cc: help-octave , rafael@debian.org Date: Fri, 19 Dec 2003 10:30:15 -0600 On Fri, Dec 19, 2003 at 01:15:02PM +0100, Solignac wrote: > 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. As others have said, all of these are available pre-built for Debian testing. Note that you _can_ mix testing and stable; many people do. The newer libc6 you are appear to be afraid of will be used only for the newer packages installed from testing. This is perfectly controllable, but it may be a 'somewhat advanced' topic as far as Debian usage and admin goes. Now, for the bug: why don't you send out a _small reprocible example_ so that we can see if the bug exists also in the packages produced by Rafael and myself? Dirk > 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 > ------------------------------------------------------------- > > -- Those are my principles, and if you don't like them... well, I have others. -- Groucho Marx ------------------------------------------------------------- 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 -------------------------------------------------------------