Apache OpenOffice (AOO) Bugzilla – Issue 82995
new operator thows exceptions in code complied without exceptions on Linux
Last modified: 2017-05-20 11:29:48 UTC
We have discussed with pl and thb on irc when the operator new throws std::bad_alloc exception and when it returns NULL pointer instead. It went out that it is system dependant. If the code is compiled with -fno-exceptions -DEXCEPTIONS_OFF, the NULL pointer is returned on Windows but the exception is still thrown on Linux. The problem is related to he Linux-specific implementation of the operator new in sal/cpprt/operators_new_delete.cxx. The current behavior is error prone and makes the error handling more complicated. Could it be somewhat synchronized? Note, the discussion started because of the fix for the issue #82970.
For what it's worth I'd vote for enabling exception handling wholesale in all modules. No mre ambiguities and no more code where an exception passes though unseen by the exception mechanism (funny things can happen when an exceptions come up to stackframes compiled without exception support, depending on the compiler's implementation).
Getting potentially affected parties in the loop.
@pl: yep, that's prolly the easiest fix - though not without problems as well. because enabling exceptions in non-exception aware code prolly turns up as much issues as just exiting right away (as it happens today) - and those tend to be harder to discern. Another reason to make error handling a priority...
My opinion is the following: Ultimately, all OOo code should be coded in an exception-aware way and be compiled with exceptions enabled, and plain new should always be standards conforming (i.e., throwing bad_alloc, not returning NULL). The code should move toward that goal, not away from it (and it should ideally do so in a way that interim versions of the code do not start to hide or obscure bugs that would have been well visible in prior versions). This implies two things: 1 When calling new can "legitimately" fail (e.g., because the requested size can be enormous as it is a value coming from the outside, not a programming error or the---unlikely---case of "real" memory outage), fix the code (e.g., by compiling with exceptions enabled and handling bad_alloc, or by using new(nothrow)). This apparently happened for issue 82970. 2 Improve the Windows build environment to make plain new throw bad_alloc (or abort) when compiling with -fno-exceptions -DEXCEPTIONS_OFF (if possible).
It seems that at least in some cases, on Windows, even in code that as far as I can see is compiled with exceptions on, new[gazillions] does not throw std::bad_alloc, it just returns NULL. This is a mess.
Reset assigne to the default "issues@openoffice.apache.org".