[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gplot.txt
From: |
Ben Abbott |
Subject: |
Re: gplot.txt |
Date: |
Sat, 05 Mar 2016 19:46:28 -0500 |
> On Mar 5, 2016, at 7:35 PM, Daniel J Sebald <address@hidden> wrote:
>
> 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?
I’m using Apple’s clang.
$ clang --version
Apple LLVM version 7.0.2 (clang-700.1.81)
Target: x86_64-apple-darwin14.5.0
Thread model: posix
Does this link help?
http://stackoverflow.com/questions/1617877/how-to-detect-llvm-and-its-version-through-define-directives
Ben
- Re: gplot.txt, (continued)
- Re: gplot.txt, Ben Abbott, 2016/03/04
- Re: gplot.txt, Ben Abbott, 2016/03/04
- Re: gplot.txt, Daniel J Sebald, 2016/03/04
- Re: gplot.txt, Daniel J Sebald, 2016/03/05
- Re: gplot.txt, Ben Abbott, 2016/03/05
- Re: gplot.txt, Daniel J Sebald, 2016/03/05
- Re: gplot.txt, Ben Abbott, 2016/03/05
- Re: gplot.txt, Daniel J Sebald, 2016/03/05
- Re: gplot.txt, Ben Abbott, 2016/03/05
- Re: gplot.txt, Daniel J Sebald, 2016/03/05
- Re: gplot.txt,
Ben Abbott <=
- Re: gplot.txt, Ben Abbott, 2016/03/06
- Re: gplot.txt, Rik, 2016/03/06
- Message not available
- Re: gplot.txt, Rik, 2016/03/07
- Re: gplot.txt, Daniel J Sebald, 2016/03/07
- Re: gplot.txt, Ben Abbott, 2016/03/07
- Re: gplot.txt, Ben Abbott, 2016/03/07
- Re: gplot.txt, Daniel J Sebald, 2016/03/04
- Re: gplot.txt, Daniel J Sebald, 2016/03/04
- Re: gplot.txt, Lachlan Andrew, 2016/03/02
- Re: gplot.txt, Daniel J Sebald, 2016/03/02