Date: prev next · Thread: first prev next last
2013 Archives by date, by thread · List index


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.