[Octave-bug-tracker] [bug #58790] Octave closes unexpectedly when memory allocation fails (Windows 32bit executable)

[Markus Mützel]

Follow-up Comment #23, bug #58790 (project octave):

I didn't know about this. But trying to read up on this, it really looks like
Octave is a victim of memory overcommit here.

This is what Qt has to say about it [1]:
> Most desktop operating systems overcommit memory. This means that malloc()
or operator new return a valid pointer, even though there is not enough memory
available at allocation time. On such systems, no exception of type
std::bad_alloc is thrown.

I think, by "most" they mean at least Windows and Linux with default
settings.

IIUC, the allocator tries to find "real" memory when the memory "reserved" by
´new´ is first *used*. If it can't find enough free or available memory at
that time, the *kernel* sends a *SIGKILL* to the process it deems to be the
most probable culprit. That's the situation on Linux. Windows seems to behave
similarly.
Unfortunately, I can't think of a good way of preventing this from happening
or of a way of recovering from that.

Maybe the next best thing is to at least try and rewrite the BISTs such that
it is less likely that running "__run_test_suite__" triggers this situation on
any of the platforms we support (with a "typical" setup).
That could also mean that we might consider to stop supporting Windows 32bit.
(For comparison, the last Matlab version for that platform was R2015b.) I'm
not saying I'm in favor of that. Just throwing it out there.
That error can still occur on other platforms (see comment #22). But e.g. with
the better allocator in Windows 64bit, it is less likely to occur IIUC.

[1]:
https://doc.qt.io/archives/qt-5.10/exceptionsafety.html#out-of-memory-handling


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?58790>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/