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 Package Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Segfault, Bus Error, etc.
Status:  Invalid Assigned to:  None
Originator Name:  Shan Mignot Originator Email:  -email is unavailable-
Open/Closed:  Closed Release:  3.6.4
Operating System:  GNU/Linux

Add a New Comment(Rich Markup)

You are not logged in

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


( 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>
Project Administrator
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)

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 ?

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)

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:


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 Files:

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)

    Do you think this task is very important?
    If so, you can 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 03 Jun 2015 02:56:05 AM UTC mtmiller StatusNeed Info => Invalid
        Open/ClosedOpen => Closed
    Thu 23 May 2013 11:29:20 AM UTC None Attached File- => Added code_snippet2.m, #28147
    Wed 15 May 2013 01:28:42 PM UTC None Attached File- => Added exp_arg.m, #28086
    Wed 15 May 2013 01:10:37 PM UTC jordigh StatusNone => Need Info
    Wed 15 May 2013 11:43:20 AM UTC None Attached File- => Added code_snippet.m, #28084

    Back to the top

    Powered by Savane 3.3