GNOME Bugzilla – Bug 67569
Poor out of memory handling
Last modified: 2013-01-26 17:02:03 UTC
Using Gnumeric 0.99.1 (RC 2) Gnumeric just closes when it can't complete an operation because there is no free memory. running under gdb only gives: Program terminated with signal SIGKILL, Killed. The program no longer exists. Steps to reproduce: 1.- fill the a1 cell with a "1" 2.- using the mouse copy it to 65536 3.- using the mouse copy the selected "A" column to AA or whatever you need (it depends how much ram do you have). It is best to disable swap, so it crashes sooner. 4.- gnumeric crashes. I would expect a "not enough memory to complete the operation" instead of a hard crash and *data loss*.
Giving this a more appropriate severity.
Gnumeric crashes, and I lose my data. I don't think it should be an enhancement. Gnumeric should catch the ENOMEM error. It is not about the stupid testcase I posted, it is about that gnumeric will crash if it can't get more memory to complete the operation, and it shouldn't crash. Anyway, it is your decision.
Solving this requires work in 2 directions 1) use less memory 2) be more careful when an allocation fails Both of which are ongoing processes. It not feasbile to know before hand how muchmemory an operation will consume. The paste operation simply does not have access to that level of detail. However, we can do an audit to ensure that as many calls to _new/_malloc that we can find check for NULL return. That will not help much though. Unless we can free memory no other operations, including saving the file will be possible. Realisticly going forward (1) (aka a good offense) is a better bet than (2) (aka a good defense).
Also we need to 0) fix all libraries we use.
A notable problem is glib. Functions like g_hash_table_insert have no error reporting facility. Manuel: your problem is real, but (a) We cannot fix it isolated in Gnumeric. (b) You can work around the problem by setting up a normal-sized swap area. Right now it's best for us to work on Jody's (1) -- that helps everyone.
Since the most important thing is the document, does gnumeric have some sort of "data recovery after crash"? something like: "Last time gnumeric exited abnormally, do you want to restore the last temporary version of the document(s) you were working on?". This would be great, and won't only serve out of memory crashes.
There is an 'autosave' featre that saves the file at regular intervals if it was modified. We do not keep a log of operations or their undo state. It would be a nice feature but is not high on the priority list.
*** Bug 625544 has been marked as a duplicate of this bug. ***
I think we just have to admit that fixing this is not in the cards. Notably: 0) fix all libraries we use. This isn't happening. So auto-save and large amounts of memory is your friend. In the past ten years we have reduced the amount of memory that we use considerably.