bugGNU Octave - Bugs: bug #46449, Address-sanitizer triggered in...

 
 

bug #46449: Address-sanitizer triggered in scripts/sparse/ichol.m

Submitted by:  Robert Jenssen <morgawr>
Submitted on:  Sun 15 Nov 2015 09:34:47 AM UTC  
 
Category: InterpreterSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Segfault, Bus Error, etc.
Status: FixedAssigned to: Kai Torben Ohlhus <siko1056>
Originator Name: Robert JenssenOpen/Closed: Closed
Release: devOperating System: GNU/Linux

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

Wed 09 Mar 2016 05:58:51 PM UTC, comment #14:

This was real. For any sparse matrices that had columns of all zeros to the right of the last non-zero element the code was overstepping the ridx pointer array. This bug was in ichol as well as ilu (written by the same person so not surprising). I fixed that in this cset (http://hg.savannah.gnu.org/hgweb/octave/rev/13415264b9f8).

In order to test with the address sanitizer I had to compile using '--without-opengl' and '--disable-docs' because there are all kinds of problems associated with OpenGl. That should probably be a separate bug report.

Rik <rik5>
Project Administrator
Fri 20 Nov 2015 08:22:19 AM UTC, comment #13:

I'll have a look at it.

Kai Torben Ohlhus <siko1056>
Project MemberIn charge of this item.
Thu 19 Nov 2015 03:08:18 PM UTC, comment #12:

Also

So, structurally singular matrices are not handled properly by this algorithm. I'm not sure how to fix that.

Kai, I'm adding you to this report. Can you help to fix this problem?

John W. Eaton <jwe>
Project Administrator
Thu 19 Nov 2015 02:54:17 PM UTC, comment #11:

It seems that

will trigger the bug.

John W. Eaton <jwe>
Project Administrator
Thu 19 Nov 2015 02:41:35 PM UTC, comment #10:

If I use --disable-opengl, then building and running make check succeeds and I get to the ichol problem.

John W. Eaton <jwe>
Project Administrator
Thu 19 Nov 2015 06:02:27 AM UTC, comment #9:

Some anecdotal evidence in response to JWE's comment about OpenGL:

1. I find that when using the stock Fedora 23 build of octave-4.0.0 I get different numerical output from the same script run repeatedly. When I use an octave that I have built without native graphics I don't see this. (Where my octave uses the numerical libraries supplied by the Fedora 23 installation).

2. I have been trying to track down a similar problem with the SeDuMi_1_3 solver running under an octave built without native graphics. I think that maybe, possibly, I have solved this one by using address-sanitizer to find an error in which an array of doubles was read one location beyond the end (in cholonBlk()).

Robert Jenssen <morgawr>
Wed 18 Nov 2015 10:09:26 PM UTC, comment #8:

This definitely looks like a useful tool.
I hope that people agree that releases have to build
and run make check cleanly.

Lots of thanks to Robert Jenssen for pointing this
out.

Michael Godfrey <godfrey>
Project Member
Wed 18 Nov 2015 09:00:25 PM UTC, comment #7:

So, looking at that output, could some of our OpenGL crash issues be due to data in Octave functions being cleared and deleted when it is still in use in a separate thread? Hmm.

John W. Eaton <jwe>
Project Administrator
Wed 18 Nov 2015 08:56:47 PM UTC, comment #6:

I checked in the following change:

http://hg.savannah.gnu.org/hgweb/octave/rev/4a25c398ffa2

With these options, I can't build Octave because it crashes for me when attempting to generate figures.

If I use disable-docs, then it builds, but make check fails when trying to test some graphics features. The failure is happening in the OpenGL driver code. Sweet.

Here is the output at the point when make check stops for me:

John W. Eaton <jwe>
Project Administrator
Wed 18 Nov 2015 06:54:15 AM UTC, comment #5:

Better is, in autoconf.ac:

Then running the following gives a stack trace with line numbers, attached.

(file #35486)

Robert Jenssen <morgawr>
Tue 17 Nov 2015 12:08:35 PM UTC, comment #4:

The patch is OK except that we should not be directly altering CFLAGS, CXXFLAGS, FFLAGS, or LDFLAGS. Those are supposed to be left to the user to define without having to worry about wiping out flags that are set by configure. But Octave's build system already uses additional variables to handle this kind of thing, so the change should be fairly simple. Unless someone beats me to it, I can make the changes.

John W. Eaton <jwe>
Project Administrator
Tue 17 Nov 2015 09:26:56 AM UTC, comment #3:

Robert: That should do it. The build system has
been worked on quite a bit lately, so one of the
folks who know that code should be able to apply
the patches.

Thanks again!

Michael Godfrey <godfrey>
Project Member
Tue 17 Nov 2015 08:08:27 AM UTC, comment #2:

I know almost nothing about autoconf. I stole the following from:
http://bugs.python.org/review/21037/patch/11412/42165

I ran autoconf then configure with "--with-address-sanitizer". This causes all the conf tests to be compiled with
"-fsanitize=address" which may not be what the maintainers want. The resulting octave still fails "make check" at scripts/sparse/ichol.m as below.

Regarding my segfault problem: my test script copies the relevant files to a directory under /tmp, saves the expected results to a file, runs octave and compares the results with the saved file.
Surrounding octave with sync's works. Briefly:

Robert Jenssen <morgawr>
Mon 16 Nov 2015 11:55:01 PM UTC, comment #1:

This is very useful. It suggests an item that should
be added to the release checklist:

All releases must be "address-sanitizer" clean for
make check, at least.

There should be a build option, like: --address-sanitize-on
which implements the script below.

I think that everyone would be very happy if you would
take an interest in producing a patch that implements this.

Michael Godfrey <godfrey>
Project Member
Sun 15 Nov 2015 09:34:47 AM UTC, original submission:

I am running Fedora 23 with the packaged gcc-5.1.1-4 and octave-4.0.0. I have a project with a test suite of bash shell scripts, most of which run the octave interpreter and check the results. I have been getting seg-faults from octave. Usually, I would assume that this means that I have a hardware problem. I decided to check the octave interpreter with Address-Sanitizer. I built octave from the hg sources, as recommended in HACKING, with this shell script:
The "make check" ends when address-sanitizer finds a problem in scripts/sparse/ichol.m. The address-sanitizer stack trace is attached.

Robert Jenssen <morgawr>

 

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

Attach File(s):
   
   
Comment:
   

Attached Files
file #35464:  stack_trace.txt added by morgawr (45KiB - text/plain - Address sanitizer stack trace for failure in scripts/sparse/ichol.m)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by rik5 (Posted a comment)
  • -unavailable- added by siko1056 (Posted a comment)
  • -unavailable- added by jwe
  • -unavailable- added by jwe (Posted a comment)
  • -unavailable- added by godfrey (Posted a comment)
  • -unavailable- added by morgawr (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 6 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Wed 09 Mar 2016 05:58:51 PM UTCrik5StatusNone=>Fixed
      Open/ClosedOpen=>Closed
    Fri 26 Feb 2016 08:37:55 AM UTCsiko1056Assigned toNone=>siko1056
    Thu 19 Nov 2015 03:08:18 PM UTCjweCarbon-Copy-=>Added siko1056
    Wed 18 Nov 2015 06:54:15 AM UTCmorgawrAttached File-=>Added stack_trace_with_line_numbers.txt, #35486
    Sun 15 Nov 2015 09:34:47 AM UTCmorgawrAttached File-=>Added stack_trace.txt, #35464

    Back to the top


    Powered by Savane 3.1-cleanup1