Re: gplot.txt

[Daniel J Sebald]

On 03/05/2016 05:08 PM, Ben Abbott wrote:
> > On Mar 4, 2016, at 8:44 AM, Ben Abbott<address@hidden>  wrote:
> >
> > On Mar 4, 2016, at 07:00, Ben Abbott<address@hidden>  wrote:
> >
> > > > On Mar 4, 2016, at 1:26 AM, Lachlan Andrew<address@hidden>  wrote:
> > > >
> > > > > On 4 March 2016 at 16:37, Daniel J Sebald<address@hidden>  wrote:
> > > > >
> > > > > assign memory even from the start--not a bad strategy.  However, at that
> > > > > point, the member pointers r and d are initialized as r(0) and d(0).  And
> > > > > 2)
> > > > >     delete [] r;
> > > > >
> > > > > Now, the first line of code is more questionable.  Typically one isn't
> > > > > supposed to delete a NULL pointer.
> > > >
> > > > Good catch, but deleting NULL pointers is valid in all
> > > > standards-compliant compilers, and some people advocate that rather
> > > > than checking for NULL first.  See the discussion at
> > > >
> > > > http://stackoverflow.com/questions/4190703/is-it-safe-to-delete-a-null-pointer#4190737
> > > >
> > > > Cheers,
> > > > Lachlan
> > >
> > > I tried bisecting again. The results I got is below. Many changes needed to be 
> > > skipped because the default branch wouldn’t build on Mac OS X.
> > >
> > > Due to skipped revisions, the first bad revision could be any of:
> > > changeset:   21210:4f7d3989c462
> > > user:        John W. Eaton<address@hidden>
> > > date:        Sat Feb 06 07:43:32 2016 -0500
> > > summary:     move UMFPACK_DNAME and UMFPACK_ZNAME macros to oct-sparse.h
> > >
> > > changeset:   21211:2cf8bc5c7017
> > > user:        John W. Eaton<address@hidden>
> > > date:        Sat Feb 06 08:48:47 2016 -0500
> > > summary:     use "#if defined (HAVE_FOO)" instead of "#if HAVE_FOO" for feature 
> > > tests
> > >
> > > changeset:   21212:7eca4ba9bb6d
> > > user:        John W. Eaton<address@hidden>
> > > date:        Sat Feb 06 19:18:59 2016 -0500
> > > summary:     also distribute octave.css from source tree
> > >
> > > changeset:   21213:f7d1050b9b53
> > > user:        Rik<address@hidden>
> > > date:        Sat Feb 06 18:22:32 2016 -0800
> > > summary:     maint: Clean up various usages of #ifdef.
> > >
> > > changeset:   21214:7be1f58f9dd7
> > > user:        John W. Eaton<address@hidden>
> > > date:        Sun Feb 07 02:03:58 2016 -0500
> > > summary:     don't strip pipe character from command in drawnow function
> > >
> > > changeset:   21215:04866fac690a
> > > user:        Ben Abbott<address@hidden>
> > > date:        Sun Feb 07 02:21:37 2016 -0500
> > > summary:     use template keyword to handle dependent template names
> > >
> > > I’ll try Dan’s patch (since I’m using Apple’s clang, and they often don’t 
> > > conform to other “standards”. Then I’ll try backingout the above changes until 
> > > I find the culprit.
> > >
> > > Ben
> >
> > Dan's patch didn't resolve the speye segfault. I'll move on to the changesets 
> > isolated by bisecting.
> >
> > Ben
>
> I was unable to confirm the bisecting results, so I went through the process 
> again. This time, I single changeset was implicated. I haven’t had time to 
> examine it yet.
>
> hg bisect --reset
> hg bisect init
> hg bisect --bad 67d2965af0b5
> hg bisect --bad a223cce1daa4
> hg bisect --bad 76e0ef020dae
> hg bisect --good 53bded18aba6
> hg bisect --good 2d7f658daa58
> hg bisect --good f5b17eb2508b
> hg bisect --good 54527108599a
> hg bisect --good 7cac4e7458f2
> hg bisect --bad  538b57866b90
> hg bisect --bad  623fc7d08cc6
> hg bisect --bad  623fc7d08cc6
> The first bad revision is:
> changeset:   21137:623fc7d08cc6
> user:        Rik<address@hidden>
> date:        Sat Jan 23 17:44:57 2016 -0800
> summary:     maint: Clean up compile warnings in liboctave from cset 
> 7cac4e7458f2.

Lot of work, Ben...

OK, getting interesting.  The changeset is here:

http://hg.savannah.gnu.org/hgweb/octave/rev/623fc7d08cc6

The OCTAVE_NORETURN that Rik added is meant to suppress compiler 
warnings about the function not properly return when it is compiled. 
AND, maybe it does more substantive stuff like not set up something on 
the stack, who knows exactly?

These functions:

OCTAVE_NORETURN T range_error (const char *fcn, octave_idx_type n) const;
OCTAVE_NORETURN T& range_error (const char *fcn, octave_idx_type n);
OCTAVE_NORETURN T range_error (const char *fcn,
OCTAVE_NORETURN T& range_error (const char *fcn,
OCTAVE_NORETURN T range_error (const char *fcn,
OCTAVE_NORETURN T& range_error (const char *fcn,

are all error messages that don't return.  Fine, plus they aren't being 
used in your case because there is no error--it's a proper speye(10).

Similarly, these two in idx-vector.h don't return:

OCTAVE_NORETURN virtual Array<octave_idx_type> as_array (void);
OCTAVE_NORETURN idx_base_rep *sort_idx (Array<octave_idx_type>&);

Here they are:

Array<octave_idx_type>
idx_vector::idx_base_rep::as_array (void)
{
  (*current_liboctave_error_handler)
    ("internal error: as_array not allowed for this index class");
}

idx_vector::idx_base_rep *
idx_vector::idx_colon_rep::sort_idx (Array<octave_idx_type>&)
{
  (*current_liboctave_error_handler)
    ("internal error: idx_colon_rep::sort_idx");
}

I'm not sure what the problem is exactly, but notice that the "as_array" 
function plays a role in the code I sent a patch for yesterday.  Here it is:

const octave_idx_type *
idx_vector::raw (void)
{
fprintf(stderr, "Before object creation and copy:  rep = %ld\n", rep);
  if (rep->idx_class () != class_vector)
    *this = idx_vector (as_array (), extent (0));
fprintf(stderr, "After object creation and copy:  rep = %ld\n", rep);

  idx_vector_rep * r = dynamic_cast<idx_vector_rep *> (rep);

  assert (r != 0);

  return r->get_data ();
}

Notice that above between the two fprintf's is a call to as_array(). 
That makes me think if you were to run the patch I sent yesterday you 
would see the first fprintf() statement about the rep address just 
before the program crashes.

So, I'm going to speculate here, and ask on Rik for input:

1) Could it be that __GNUC__ is not defined for Ben's compiler and as a 
result OCTAVE_NORETURN ends up being blank?  Is that a problem?

2) Is it a problem that a virtual base class is __attribute__ 
((__noreturn__)) but it's overriding classes are not?  (That is the case 
here.)  I mean, the idea of virtual base class is that a substitute 
function is called determined at run-time.  But how can the compiler 
know in one case it should set up the stack as if there is no return and 
in another case as if there is a return?

3) If this is a legitimate construct (noreturn virtual while return for 
the derived class member function) is it arcane enough that there might 
be a bug in Ben's compiler?

4) Also, the *this= construct.  Is there a nicer way of doing that? 
From what I remember of learning C++ way back when, the this pointer 
was something to use sparingly.

In any case, Ben nice work, looks like we are closing in on the problem.

Dan