bugGNU Octave - Bugs: bug #38996, Octave crashes when using...

 
 

bug #38996: Octave crashes when using parcellfun

Submitted by:  None
Submitted on:  Wed 15 May 2013 11:43:20 AM UTC  
 
Category: Octave Forge PackageSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Crash
Status: Need InfoAssigned to: None
Originator Name: Shan MignotOriginator Email: -unavailable-
Open/Closed: OpenRelease: 3.6.4
Operating System: GNU/Linux

Add a New Comment (Rich MarkupRich 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)

Sat 01 Jun 2013 12:17:46 PM UTC, comment #6:

Same thing happens on Mac OS X with homebrew (and the latest version of octave).
The problem appeared after last update.

Octave crashes with error message
octave(16413) malloc: *** error for object 0x111fa17c0: pointer being freed was not allocated

      • set a breakpoint in malloc_error_break to debug

panic: Abort trap: 6 -- stopping myself...
attempting to save variables to 'octave-core'...
save to 'octave-core' complete
Abort trap: 6

Octave also leaves the child processes running.

Henrik J. Asplund <brufor>
Thu 23 May 2013 11:29:20 AM UTC, comment #5:

I have tried to split the computation by taking slices in the large NDArray to avoid having to rely on the 64-bit addressing (see the code_snippet2.m). Changing N from 1 (which is equivalent to code_snippet.m) to any other greater value makes the bug disappear although 64-bit addressing is required while N < 16. I cannot accordingly run the code causing the bug with 32-bit addressing.

I have carefully followed the instructions and built octave with 64-bit addressing with lapack-3.4.2, qrupdate-1.1.2 and SuiteSparse-4.2.0 as instructed. Would you happen to have precompiled 64-bit Octave and dependencies I could use confirm that the problem does not result from the build process ?

(file #28147)

Anonymous
Wed 15 May 2013 03:26:51 PM UTC, comment #4:

All right.

I will try to split my large arrays into several ones. Can you tell me what is precisely the maximum admissible index range for 32-bit indexing ?

Anonymous
Wed 15 May 2013 02:30:13 PM UTC, comment #3:

It is easy to miscompile Octave with --enable-64. This is why I want to make sure that this isn't the problem.

You did carefully follow instructions and ensured that all necessary dependencies were properly recompiled with 64-bit-indexing?

We may have a bug with 64-bit indexing (it's still an experimental feature), or there may be a peculiarity in the way that you compiled Octave. Or it may be completely unrelated. Are you able to reproduce this problem on a build with 32-bit indexing?

Jordi GutiƩrrez Hermoso <jordigh>
Project Administrator
Wed 15 May 2013 01:28:42 PM UTC, comment #2:

Oops... Sorry, here is the exp_arg.m function.

I compiled with --enable-64 because otherwise "x" is has so many elements that I get: "error: memory exhausted or requested size too large for range of Octave's index type -- trying to return to prompt". I have not seen anything suspicious while compiling and Octave runs fine except for the bug I reported.

I should also mention that reducing the number of elements in "isochrones" by a factor two makes the bug disappear, try:

> isochrones = rand (floor (73160/2), 29);

(file #28086)

Anonymous
Wed 15 May 2013 01:10:37 PM UTC, comment #1:

The octave-core file isn't a core dump, so it's not that useful for debugging. It's just whatever variables you had defined in Octave at the time it crashed. In the development version, it's been renamed to octave-workspace.

So are you sure you compiled with --enable-64 correctly? Can you reproduce this problem without --enable-64?

What is the exp_arg function doing?

Jordi GutiƩrrez Hermoso <jordigh>
Project Administrator
Wed 15 May 2013 11:43:20 AM UTC, original submission:

Hi,

I run the following code snippet on Octave 3.6.4 compiled from source with the --enable-64 option (according to http://www.gnu.org/software/octave/doc/interpreter/Compiling-Octave-with-64_002dbit-Indexing.html) on a large volume of data (4D NDArray of several GB).

The computation generates two child processes and things seem to be working well until octave collects results for them. Then it terminates with a segmentation fault. It also turns out that if the last assignment is dropped (ie. I call > parcellfun(...) instead of > x = parcellfun(...)) octave does not segfault but I cannot retrieve the result since the ans variable is absent from the current scope.

Unfortunately the server on which I run this does not have debugging symbols so I cannot easily investigate the cause (but I could provide the octave-core file ~18 MB).

Thanks,

Shan

Anonymous

 

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

Attach File(s):
   
   
Comment:
   

Attached Files
file #28147:  code_snippet2.m added by None (1kB - application/octet-stream)
file #28086:  exp_arg.m added by None (163B - application/octet-stream)
file #28084:  code_snippet.m added by None (597B - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by brufor (Posted a comment)
  • -unavailable- added by jordigh (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 4 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Thu 23 May 2013 11:29:20 AM UTCNoneAttached File-=>Added code_snippet2.m, #28147
    Wed 15 May 2013 01:28:42 PM UTCNoneAttached File-=>Added exp_arg.m, #28086
    Wed 15 May 2013 01:10:37 PM UTCjordighStatusNone=>Need Info
    Wed 15 May 2013 11:43:20 AM UTCNoneAttached File-=>Added code_snippet.m, #28084

    Back to the top


    Powered by Savane 3.1-cleanup