bugGNU Octave - Bugs: bug #42825, Memory corruption in sparse matrix...

 
 

bug #42825: Memory corruption in sparse matrix operation

Submitter:  None
Submitted:  Tue 22 Jul 2014 10:57:40 AM UTC
   
 
Category:  Octave Function Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Regression
Status:  Fixed Assigned to:  lachlan
Originator Name:  Chong Yidong Originator Email:  -email is unavailable-
Open/Closed:  * Closed Release:  * dev
Operating System:  * Any Fixed Release:  None
Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sun 14 Feb 2016 06:54:47 AM UTC, comment #11: 

I love that the solution was as simple as replacing std::copy with std::copy_backward.  I applied the patch to the stable branch here (http://hg.savannah.gnu.org/hgweb/octave/rev/6209f428426c) with the slight simplification of


li + rnz + nz - ui
=>
new_nz


Marking as fixed and closing report.

Rik <rik5>
Group administrator
Fri 12 Feb 2016 06:02:06 AM UTC, comment #10: 

Thanks for the confirmation, Carlos.

Lachlan Andrew <lachlan>
Fri 12 Feb 2016 04:12:17 AM UTC, comment #9: 

I am having a similar problem, and the patch fixes it.

Here are the details:

> M = sparse([], [], [], 3, 3, 21);
> M(1, 3) = 1;
> M(2, 3) = 2;
> M
M =

Compressed Column Sparse (rows = 3, cols = 3, nnz = 2 [22%])

  (1, 3) ->  1
  (2, 3) ->  2
> M(2, 2) = -i;
> M
M =

Compressed Column Sparse (rows = 3, cols = 3, nnz = 3 [33%])

  (2, 2) -> -0 - 1i
  (1, 3) ->  1 + 0i
  (2, 3) ->  1 + 0i


Carlos Dyonisio <carlosdyonisio>
Tue 12 Jan 2016 12:57:05 AM UTC, comment #8: 

@Lachlan: People do "misuse" incorrect result, so maybe
something else is needed. But, the category needs to
be less misuse prone then incorrect result. wrong answer
does not seem to be much better than incorrect result.

maybe: fatal error

Other ideas?

Michael Godfrey <godfrey>
Group Member
Tue 12 Jan 2016 12:34:11 AM UTC, comment #7: 

@Lachlan: Yes, move this to the Maintainer's list.  Sometimes I also have trouble deciding how to categorize a bug.

--Rik

Rik <rik5>
Group administrator
Tue 12 Jan 2016 12:19:20 AM UTC, comment #6: 

Michael, I've realised part of the problem.  If a person is submitting, say, a GUI bug, they need to select one from "item group", and there is no option that simply says "unexpected behaviour", so they are forced to select "incorrect result".

Would it be possible to split "incorrect result" into "unexpected behaviour" and "wrong answer", or to find some other way to search on only numerical "incorrect result" bugs?

An alternative would be for a core developer to assign priorities to bugs -- currently most have the default priority, and casual developers like me can't change that.

Should we move this to the developers mailing list?

Lachlan Andrew <lachlan>
Tue 12 Jan 2016 12:07:20 AM UTC, comment #5: 

Michael, it seems not to be clear enough.

I interpret "incorrect result" as a "gross numerical error", but browsing the bugs that have that type shows that others interpret it to mean "it didn't do what I expected", including "command window blank", "gripe error appearing", "unable to create classes", "need better configure test" etc.

What is worse is that this bug (clearly an "incorrect result") was (also correctly) labelled as "regression".  That label is useful for identifying the cause of the bug, but not for selecting which bugs to fix.  It would be nice to be able to mark a bug as both "wrong number" and "regression".

I'm starting a wiki page http://wiki.octave.org/Status_of_bugs where I'm recommending changes to the status etc of groups.  Perhaps I'll start recommending reclassification of "incorrect result" bugs once I've gone through all the "patch submitted" bugs :)

Lachlan Andrew <lachlan>
Sat 09 Jan 2016 10:39:41 AM UTC, comment #4: 

@Lachlan: The group "incorrect result" is intended
for this. Do you think that it is not clear enough?

Michael Godfrey <godfrey>
Group Member
Sat 09 Jan 2016 09:49:13 AM UTC, comment #3: 

The attached changeset seem to fix the problem.  The code segment to make room for the new data was using std::copy instead of std::copy_backward.

I have no idea why the bug didn't show up if the initial assignment was complex, or indeed why this bug didn't show up more often.

I think that bugs like this that produce totally erroneous results with no error deserve their own item group.  It is really important to be able to trust the numbers that Octave produces; that is even more important than not segfaulting.

(file #35953)

Lachlan Andrew <lachlan>
Wed 23 Jul 2014 11:54:37 PM UTC, comment #2: 

My guess is that this has something to do with the auto-conversion of the array from SparseMatrix to SparseComplexMatrix when there are outstanding free values allocated by spalloc.

The code works if there are no such values: spalloc called with nnz < 3 for third argument.  It also works if the first assignment is first made to  a complex value, and then to a real value.

Rik <rik5>
Group administrator
Tue 22 Jul 2014 09:53:18 PM UTC, comment #1: 

Confirmed with a recent tip (ed3cb9f81145).  This is a regression as the code worked in version 3.2.4 and fails in 3.4.3 and subsequent versions.

Rik <rik5>
Group administrator
Tue 22 Jul 2014 10:57:40 AM UTC, original submission:  

Run the following:

octave:1> H = spalloc(800,800,10);
octave:2> H(1,401) = 1;
octave:3> H(1,40) = 1i;
octave:4> H(2,21) = 1i;
octave:5> H(1,401)
ans = Compressed Column Sparse (rows = 1, cols = 1, nnz = 1 [100%])

  (1, 1) ->  0 + 1i

Expected result: H(1,401) should be 1.

Observed in Octave 3.8.1 as well as latest hg version (4.1.0+, 22-Jul-2014).

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #35953:  bug_42825.cset added by lachlan (1KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by carlosdyonisio (Posted a comment)
  • -email is unavailable- added by godfrey (Posted a comment)
  • -email is unavailable- added by lachlan (Updated the item)
  • -email is unavailable- added by mtmiller (Updated the item)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by None (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 11 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-02-14 rik5 StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2016-02-08 lachlan Assigned toNone lachlan
    2016-02-08 lachlan StatusPatch Submitted Ready For Test
    2016-02-08 lachlan StatusConfirmed Patch Submitted
        Release3.8.1 dev
        Operating SystemGNU/Linux Any
    2016-01-09 lachlan Attached File- Added bug_42825.cset, #35953
    2014-11-15 mtmiller CategoryNone Octave Function
    2014-07-22 rik5 Item GroupIncorrect Result Regression
        StatusNone Confirmed

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code