ghull library directory rearrangements (was Re: Mountain Lion Build)

[Daniel J Sebald]

On 08/22/2012 12:58 AM, Daniel J Sebald wrote:
> On 08/21/2012 11:52 PM, Robinson, Melvin D wrote:
> > Hello,
> >
> > I'm in the final stages of the build on Mountain Lion, but am coming up
> > with these errors:
> >
> > Making all in interpreter
> > ../../run-octave -f -q -H -p . --eval "geometryimages ('voronoi',
> > 'txt');"
> > ../../run-octave -f -q -H -p . --eval "geometryimages ('triplot',
> > 'txt');"
> > ../../run-octave -f -q -H -p . --eval "geometryimages ('griddata',
> > 'txt');"
> > ../../run-octave -f -q -H -p . --eval "geometryimages ('convhull',
> > 'txt');"
> > octave(30583,0x7fff7563d180) malloc: *** error for object 0x1074c56a0:
> > pointer being freed was not allocated
> > *** set a breakpoint in malloc_error_break to debug
> > octave(30582,0x7fff7563d180) malloc: *** error for object 0x110dc16a0:
> > pointer being freed was not allocated
> > *** set a breakpoint in malloc_error_break to debug
> > octave(30581,0x7fff7563d180) malloc: *** error for object 0x1131896a0:
> > pointer being freed was not allocated
> > *** set a breakpoint in malloc_error_break to debug
> > octave(30580,0x7fff7563d180) malloc: *** error for object 0x11678b6a0:
> > pointer being freed was not allocated
> > *** set a breakpoint in malloc_error_break to debug
> > make[3]: *** [convhull.txt] Abort trap: 6
> > make[3]: *** Waiting for unfinished jobs....
> > make[3]: *** [triplot.txt] Abort trap: 6
> > make[3]: *** [griddata.txt] Abort trap: 6
> > make[3]: *** [voronoi.txt] Abort trap: 6
> > make[2]: *** [all-recursive] Error 1
> > make[1]: *** [all-recursive] Error 1
> > make: *** [all] Error 2
> >
> >
> > The problem seems be something within Qhull, but the build crashes too
> > spectacularly for me to even get a handle on what could be happening. Do
> > you have any suggestions?
> >
> > Signed,
> > Confused in Sugar Land
>
> CISL,
>
> I see no "free ()" commands in the code associated with that failure.
> There is a qh_freeqhull() used several times, and I'm guessing that is
> where the actually "free" is done. So it is crashing inside the library,
> I'm guessing. The two problems that come to mind are
>
> 1) Bogus pointer passed into the qh_freeqhull() routine that is Octave's
> code fault.
> 2) A bug in the qhull library

Or, there might be a third possibility of some bogus pointer in Octave 
causing random problems in code space.  Are you working with the latest 
Hg code?  The history of the files that do a qh_freeqhull()

__voronoi__.cc
__delaunayn__.cc
convhulln.cc

don't have any changes to code, but there is a recent diff from a day or 
two ago where the files were rearranged into a new directory.  That's 
interesting.  There was a discussion the other week titled "JIT test 
crash" that described odd behavior out of the blue.  The discussion 
seemed to end without being resolved--not sure if it went away on its own.

Dan