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

 
 

bug #38996: Octave crashes when using parcellfun

Submitter:  None
Submitted:  Wed 15 May 2013 11:43:20 AM UTC
   
 
Category:  Octave Package Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Segfault, Bus Error, etc.
Status:  Invalid / Not an Octave Bug Assigned to:  None
Originator Name:  Shan Mignot Originator Email:  -email is unavailable-
Open/Closed:  * Closed Release:  * 3.6.4
Operating System:  * GNU/Linux Fixed Release:  None
Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Wed 03 Jun 2015 02:56:05 AM UTC, comment #7: 

There's been no updates or progress on this bug in 2 years. I am unable to reproduce it because I apparently don't have enough memory to run the provided code_snippet. I have a properly built Octave with 64-bit indexes and the parallel package installed but the dataset is too large for my hardware. If no one can reproduce this and no one can investigate the cause of the crash, there's no point in keeping this open.

Mike Miller <mtmiller>
Group Member
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>
Group Member
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>
Group Member
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 Files:
   
   
Comment:
   

Attached Files
file #28147:  code_snippet2.m added by None (1KiB - 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
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by brufor (Posted a comment)
  • -email is unavailable- added by jordigh (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 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2015-06-03 mtmiller StatusNeed Info Invalid / Not an Octave Bug
        Open/ClosedOpen Closed
    2013-05-23 None Attached File- Added code_snippet2.m, #28147
    2013-05-15 None Attached File- Added exp_arg.m, #28086
    2013-05-15 jordigh StatusNone Need Info
    2013-05-15 None Attached File- Added code_snippet.m, #28084

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code