How to handle Out-of-Memory in Konqueror?

[Josef Weidendorfer]

On Wednesday 25 February 2004 10:55, Stefan Taferner wrote:
> > I need your advice. Bug [75775] (konqueror fsview part crashes when
> > viewing a large directory) comes from an out of memory condition. The
> > backtrace shows that the crash is an abort(), triggered by raising an
> > out-of-memory exception in new().
>
> Unix does usually not care about out-of-memory, as it usually does
> not happen. When your swap is used up the machine is swapping around
> anyways, which makes it rather unusable.

Hmm...
There are already 2 people complaining about the crash. At least one uses
"ulimit -v", i.e. he is by purpose limiting the amount of virtual memory for 
each process.
I just checked the behavior of konqueror if I do "ulimit -v 40000", i.e. 
limiting to 40 MB virtual space. This is enough for KDE libs and khtml part.
Result: It *always* crashes at arbitrary points with different backtraces 
while browsing. Obviously, konqueror never handled this gracefully.

So: Should I regard this bug report more like a wish item: "Please use less 
space in fsview part?".

> > First thing: I will have to catch the exception? Or is it enough to check
> > for zero as return value from new() ?
>
> If an exception is thrown you have to catch it.

Yes. But doesn't this depend on compilation flags?
"new()" is used allover KDE, so in all of KDE we would have to be able to 
catch this error if we do it in the right way?

> > Next: Does it help in this case to free as many objects as possible
> > before showing a notification in message box, or is the process doomed to
> > fail anyway?
>
> You would have to guard all object creations (new-s) to be 100% safe, as it
> might happen elsewhere too. This is probably lots of work and not worth
> the effort.

I'm not sure about this statement any more:
Would you suggest people to not use "ulimit -v" ?

As for both people, the crash happened with the same new(), I could try for 
some special handling.

Greetings,
Josef