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


bug #38996: Octave crashes when using parcellfun

Submitted by:  None
Submitted on:  Wed May 15 11:43:20 2013  
Category: Octave Forge PackageSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Segfault, Bus Error, etc.
Status: InvalidAssigned to: None
Originator Name: Shan MignotOriginator Email: -unavailable-
Open/Closed: ClosedRelease: 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)

Wed Jun 3 02:56:05 2015, 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>
Project Administrator
Sat Jun 1 12:17:46 2013, 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 May 23 11:29:20 2013, 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)

Wed May 15 15:26:51 2013, 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 ?

Wed May 15 14:30:13 2013, 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 May 15 13:28:42 2013, 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)

Wed May 15 13:10:37 2013, 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 May 15 11:43:20 2013, original submission:


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).





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

Attach File(s):

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 mtmiller (Posted a comment)
  • -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 6 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Wed Jun 3 02:56:05 2015mtmillerStatusNeed Info=>Invalid
    Thu May 23 11:29:20 2013NoneAttached File-=>Added code_snippet2.m, #28147
    Wed May 15 13:28:42 2013NoneAttached File-=>Added exp_arg.m, #28086
    Wed May 15 13:10:37 2013jordighStatusNone=>Need Info
    Wed May 15 11:43:20 2013NoneAttached File-=>Added code_snippet.m, #28084

    Back to the top

    Powered by Savane 3.1-cleanup