Re: gplot.txt

[Daniel J Sebald]

On 03/02/2016 12:37 PM, Rik wrote:
> On 03/01/2016 05:12 PM, Ben Abbott wrote:
> > > On Mar 1, 2016, at 3:07 PM, Ben Abbott<address@hidden>  wrote:
> > >
> > > On Mar 1, 2016, at 15:04, Ben Abbott<address@hidden>  wrote:
> > >
> > > > > On Mar 1, 2016, at 11:02, Rik<address@hidden>  wrote:
> > > > >
> > > > > 3/1/16
> > > > >
> > > > > Ben,
> > > > >
> > > > > Things can get weird when tinkering with the build system, and jwe has been
> > > > > doing a lot recently to improve it.  One way to test things cleanly is to
> > > > > get rid of all the cruft in your source tree and try a fresh build.
> > > > >
> > > > > I do
> > > > >
> > > > > make maintainer-clean
> > > > > hg stat -u -i>  unknown.list
> > > > > #look through unknown.list and delete things you don't need like leftover
> > > > > .o object files.
> > > > > bootstrap
> > > > > configure
> > > > > make
> > > > >
> > > > > However, a quicker test is to update your source repository and then clone
> > > > > it to a new directory.  That will get you only the files under version
> > > > > control, and skip all the cruft.
> > > > >
> > > > > cd octave-src
> > > > > hg pull
> > > > > hg update
> > > > > cd ..
> > > > > hg clone octave-src octave-tmp
> > > > > cd octave-tmp
> > > > > bootstrap
> > > > > configure
> > > > > make
> > > > >
> > > > > --Rik
> > > > Good idea. I tried the first approach, but the problems persist. I'll try a 
> > > > fresh archive next (just to be sure)
> > > >
> > > > Ben
> > > Oops, I spoke too soon. The gui runs for me now! :-)
> > >
> > > Ben
> > Building default still runs into trouble in doc/interpreter. The first 
> > seg-fault occurs for gplot.txt. It tracked the problem to speye().
> >
> > speye(10)
> > panic: Segmentation fault: 11 -- stopping myself...
> > attempting to save variables to 'octave-workspace'...
> > save to 'octave-workspace' complete
> > Segmentation fault: 11
> Ugh.  So is the code to create the problem as simple as this?
>
> make
> ./run-octave
> speye (10)
>
> If so, I'm going to have to suggest bisecting.  You know the tip is broken,
> I would try going back to 623fc7d08cc6 as the first possible working
> revision.  jwe has done a lot in liboctave recently to revamp the
> factorization classes and there have necessarily been some changes to
> sparse matrices.
>
> --Rik

There has been discussion about speeding compilation by avoiding 
multiple compilation of code in header files.  My general feeling is 
that re-compiling Octave is too slow for development.  To make a minor 
change takes on the order of a minute or more to recompile.  This wasn't 
always the case--maybe a couple years ago this became the norm.

I wonder, is there some type of optimization now that slows things down? 
 Is it the way that file dates are checked by the make facility?  Is 
there a way to have a development build configuration which is faster 
and a release build that is slower with optimizations?

Anyway, the slow recompile makes bisecting slow.  As an alternative, I 
typically first search through the changesets that might have caused the 
problem.  One can simplify this process by identifying which file it 
might be where the problem lies, i.e., some file that would have to be 
altered if it were related to the function.  To do this, go to the 
mercurial log of the project and navigate to the file of interest using 
the "browse" link.  From the file, click on the "changeset" link to see 
the difference from the parent.  If nothing looks problematic, follow 
the link backward and select the parent.  Click "changeset" again, etc. 
 Do that until roughly the date you think the problem might have occurred.

Or, there is a more elegant Mercurial feature that will display the log 
history for just a particular file.  In this case, try the Sparse.cc file:

http://hg.savannah.gnu.org/hgweb/octave/log/40de9f8f23a6/liboctave/array/Sparse.cc

From the list one revision I would think to look at is this changeset:

http://hg.savannah.gnu.org/hgweb/octave/rev/af8118df8292

The mod has to do with indexing, which is typically a source of 
seg-fault problems.  In particular, the following is the sort of thing 
that would fall into question:

octave_idx_type i_old_rm = static_cast<octave_idx_type> (-old_nr);

I don't know if that is a problem, but the casting of a negative value 
might be different between compilers.

I just don't want to dig into the code right now, so maybe Lachlan could 
have a brief look at the above changeset and determine if there might be 
a problem.

Dan