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

 
 

bug #30514: Array indexing error?

Submitted by:  None
Submitted on:  Wed 21 Jul 2010 11:59:32 PM UTC  
 
Category: InterpreterSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Other
Status: FixedAssigned to: Jaroslav Hajek <highegg>
Originator Name: NeilOriginator Email: -unavailable-
Open/Closed: ClosedRelease: 3.2.4
Operating System: Microsoft Windows

Add a New Comment(Rich Markup)
   

You are not logged in

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

 

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

Jaroslav, your fix looks OK to me.

John W. Eaton <jwe>
Project 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,
$ 4M+MM+MAX( M, 2M-4, NRHS, N-3M ) )

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>In charge of this item.
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 File(s):
   
   
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
  • -unavailable- added by jwe (Posted a comment)
  • -unavailable- added by highegg (Posted a comment)
  • -unavailable- added by None (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 5 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Thu 22 Jul 2010 08:07:35 AM UTChigheggCategoryNone=>Interpreter
      StatusNone=>Fixed
      Assigned toNone=>highegg
      Open/ClosedOpen=>Closed
    Wed 21 Jul 2010 11:59:32 PM UTCNoneAttached File-=>Added OctaveCrash.GIF, #21032

    Back to the top


    Powered by Savane 3.1-cleanup1