bugGNU Octave - Bugs: bug #30514, Array indexing error?

 
 

bug #30514: Array indexing error?

Submitter:  None
Submitted:  Wed 21 Jul 2010 11:59:32 PM UTC
   
 
Category:  Interpreter Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Other
Status:  Fixed Assigned to:  highegg
Originator Name:  Neil Originator Email:  -email is unavailable-
Open/Closed:  * Closed Release:  * 3.2.4
Operating System:  * Microsoft Windows Fixed Release:  None
Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Fri 23 Jul 2010 05:12:22 PM UTC, comment #2: 

Jaroslav, your fix looks OK to me.

John W. Eaton <jwe>
Group administrator
Thu 22 Jul 2010 08:07:35 AM UTC, comment #1: 

The crashes after the out-of-memory error are probably Windows-specific, because I don't see them on Linux neither in 3.3.51+ nor 3.2.4. Most likely related to some OctaveForge packages.


The out-of-memory itself is a bug in a workaround for LAPACK's bug in workspace query. The dependence on number of rows is caused by integer overflows. Indexing has nothing to do with this.


John, apparently it was you who introduced it with 7486:6a6d2abe51ff for some reason, so I invite you to take a look at my fix:
http://hg.savannah.gnu.org/hgweb/octave/rev/2c2d4a2f1047

I think the workaround needs only be triggered when both n > m and n >= mnthrs, because that's the only case when the following block from dgelsd in lapack 3.2 is met:

!     XXX: Ensure the Path 2a case below is triggered.  The workspace
!     calculation should use queries for all routines eventually.
               MAXWRK = MAX( MAXWRK,
     $              4*M+M*M+MAX( M, 2*M-4, NRHS, N-3*M ) )

and this seems to be the only block that was missing throughout 3.0.0 - 3.1.1. I didn't check earlier LAPACKs.

Jaroslav Hajek <highegg>
Wed 21 Jul 2010 11:59:32 PM UTC, original submission:  

Running 3.2.4 on 32 bit Vista SP2.  Tested the following on 2 Vista machines with 4GB memory and > 2 GB free:

data = zeros(180000, 6, 'single'); % ~ 4 MB
data1 = data(60000:180000, :);     % subset of range
detrend(data1, 0);                 % anything forcing copy crashes

At this point I get the 'error: memory exhausted or requested size too large . . ." message. 

The system is now unstable and "clear all" will frequently crash with 'panic: Segmentation violation -- stopping myself...'  (see GIF attached)

Installed with SSE2 (FFTW3 & ATLAS) and all Octave Forge Libs.

Error occurs in many variations.  Seems to coincide with completion of lazy copy.  Error does not occur on full range copies or when the row range is a only, say, 10000 rows.

Anonymous

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #21032:  OctaveCrash.GIF added by None (33KiB - image/gif)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by highegg (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 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2010-07-22 highegg CategoryNone Interpreter
        StatusNone Fixed
        Assigned toNone highegg
        Open/ClosedOpen Closed
    2010-07-21 None Attached File- Added OctaveCrash.GIF, #21032

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code