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. _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
