On 04/01/13 08:53, Noel Grandin wrote:
Why are we catching std::bad_alloc all over the place?
git grep 'catch.*bad_alloc' | wc -l
68
Surely we should just let it crash?
Or have a single handler for the whole process that at least attempts to
provide some debugging data?
At the moment, most of them just log something and then continues, which
strikes me as counter-productive.
there are 2 reasons why a std::alloc might be thrown that should be
distinguished:
1. the box simply doesn't have enough RAM for the task (or alternatively
the implementation is wasteful of memory), and some ordinary allocation
fails; this is actually unlikely to happen in practice on some platforms
like Linux that overcommit memory by default
2. there is a single enormous allocation (gigabytes) which is caused by
reading some file; e.g. easy to do with a huge image
in the first case, we'll just crash at some point anyway (and with
overcommit in the OS we won't even be notified when there is _really_ no
more memory, the kernel just kills the process), so there isn't a good
reason to handle it.
but the second case is usually caused by malicious input files that want
to trigger some failure condition, and in that case it makes sense to
handle the bad_alloc, abort the file import and continue.
Context
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.