How to handle Out-of-Memory in Konqueror?

Stefan Taferner taferner at kde.org
Wed Feb 25 13:47:57 GMT 2004


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday 25 February 2004 14:19, Josef Weidendorfer wrote:
> 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.

What I've meant: traditionally in Unix programs one does not care about out of
memory conditions. IMO the ulimit thing is to ensure a process does not eat
up all memory, knowing that those processes probably crash when they hit
the limit.

> 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.

Yes, that's what I wanted to say what will happen. If you try to catch it, you
have to catch it everywhere. Or test for NULL-pointers on new, whatever.

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

If it uses really much memory it might be more than a wishlist.

> > > 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?

If you can isolate the "critical" parts where new eats lots of memory you 
might be lucky with handling only these news. But if you use almost all 
memory in the "critical" parts and leave only little memory for later, 
konqueror will probably crash at a later occation.

> > > 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" ?

I have also ulimit in use. At a high limit, I think 300MB, just to be sure 
that no process goes crazy and crashes the machine.

See above. You cannot be sure that you catch out-of-memory if you do not
test in all cases of new. You might be able to reduce the problem, but it 
might still happen.

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

And as others suggested, try reducing the memory footprint.

Kind regards,
Stefan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFAPKeQyFGHHVZzCLwRAgHZAJ9OeZsHO6L8tRh73sa2rT1FMkbLMgCffNwg
09pRjp72urccp5RRLYlzc8I=
=3ie5
-----END PGP SIGNATURE-----




More information about the kde-core-devel mailing list