bugGNU Octave - Bugs: bug #65621, octave hangs or crashes when has...

 
 

bug #65621: octave hangs or crashes when has small (1GB) ulimit -d - likely ENOMEM handling bug

Submitter:  Jerzy Tarasiuk <jt_fuw>
Submitted:  Sun 21 Apr 2024 02:35:09 PM UTC
   
 
Category:  Interpreter Severity:  3 - Normal
Priority:  1 - Later Item Group:  Segfault, Bus Error, etc.
Status:  Need Info Assigned to:  None
Originator Name:  jt_fuw Open/Closed:  * Open
Release:  * 6.4.0 Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Mon 06 May 2024 07:04:18 PM UTC, comment #1: 

I can't easily reproduce this.  If I use very small values such as 14000 (14 MB) then I can get reliable abort on failure to allocate memory.


ulimit -d 14000
unset DISPLAY
octave-6.4.0 -f /dev/null
octave: X11 DISPLAY environment variable not set
octave: disabling GUI features
terminate called after throwing an instance of 'St9bad_alloc'
  what():  std::bad_alloc
fatal: caught signal Aborted -- stopping myself...
Aborted (core dumped)


I once got the hang you are discussing, but was never able to reproduce again.

Without a reproducible example, I can't say if the situation has changed in Octave 9.1.  I think it should be significantly better since the startup code has been re-written.  Given that 6.4 is deprecated and no longer maintained, it would help if you could find a reproducible example using 9.1 for which we would be more motivated to find a solution.

Rik <rik5>
Group administrator
Sun 21 Apr 2024 02:35:09 PM UTC, original submission:  

OS: Linux Ubuntu 22.04.4 LTS; no DISPLAY variable

When ulimit -d is 2GiB, octave /dev/null tells:
octave: X11 DISPLAY environment variable not set
octave: disabling GUI features
and then ends - it is the correct behavior.

When ulimit -d is 1GiB, octave /dev/null tells the same
and hangs - it runs few threads, uses CPU, ignores signals
(tried INT, TERM, HUP - needed KILL to kill it).

Note: ulimit -d value is in KiB - therefore I used
"ulimit -d 2000000" or "ulimit -d 1000000".

In some cases (this depends on exact ulimit -d value, or
program arguments, e.g. a file passed for processing)
a segfault is signalled; sometimes the program terminates
after the message, sometimes it remains and eats CPU time.

strace show large amount (around 25% syscalls) of ENOMEM-s
in the second case, and no one ENOMEM in the first case.

Likely the ENOMEM is incorrectly handled - possibly this
kills some threads leaving the entire process inoperable.

Included: strace logs for both cases; for the bad case
it is abbreviated: 20k lines from the start and 2k from
the end are included as two files.

Strace logs were packed using tar with 'xz' compressing;
okn/obn stand for Octave Correct/Bad-case Null-input.

Jerzy Tarasiuk <jt_fuw>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #55951:  okn.txz added by jt_fuw (72KiB - application/x-xz-compressed-tar)
file #55952:  obn.txz added by jt_fuw (81KiB - application/x-xz-compressed-tar)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by jt_fuw (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 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2024-05-06 rik5 CategoryNone Interpreter
        Priority5 - Normal 1 - Later
        StatusNone Need Info
    2024-04-21 jt_fuw Attached File- Added okn.txz, #55951
        Attached File- Added obn.txz, #55952

    Back to the top

    Powered by Savane 3.13-bb6a.
    Corresponding source code