[Development] QtCore missing check for memory allocation

[Knoll Lars]

On 03/03/15 22:10, "Oswald Buddenhagen"
<oswald.buddenhagen at theqtcompany.com> wrote:

>On Mon, Mar 02, 2015 at 10:11:33AM -0800, Thiago Macieira wrote:
>> On Monday 02 March 2015 11:21:10 Oswald Buddenhagen wrote:
>> > > I am actively against it while it's a huge burden on us for little
>> > > perceived  benefit. You have to convince me of the benefit against
>>the
>> > > cost.
>> > 
>> > i still don't see that huge burden. i see introducing a few (inline)
>> > functions in two alternative #ifdef branches, and a global search &
>> > replace operation.
>> 
>> You need to replace all the "new" too for this to be effective.
>> 
>this aims at the reliably failing builds without exception support, so
>the non-throwing new's return value would have to be checked to
>complement the malloc wrapper.

The problem is that a non throwing new can’t reliably detect OOM issues.
Even if we did check the return value of every 'operator new’ call in Qt,
this would leave us with one big problem that’s more or less impossible to
solve. The main problem is that we call new inside other constructors (ie.
Inside another call to operator new).

The fundamental issue that can’t be solved without exceptions is that this
should cause the outer operator new to fail (as the inner object didn’t
get constructed, thus the outer object is not fully constructed and
usable). But without exceptions there’s no way we can report this back
through the outer constructor call.

>while this would be reasonably simple (just replace new with qNew or
>something like that), it would be a) kinda ugly and b) would expand to
>lots of code.
>
>
>the other case is a build with exceptions where new throws as normal and
>qMalloc (used from c++ code) throws as well. malloc calls from c code
>would obviously need to handle and propagate malloc failures up to a
>point where we can see them and throw, which isn't much effort for our
>own code.
>
>however, there is a serious problem: stack unwinding resulting from
>an exception being thrown (even if it just aborts in the end because
>nobody catches it) requires all objects on the stack to keep their
>internal state consistent enough so that invoked d'tors won't crash -
>even when a c'tor throws before initialization finishes.
>this is clearly at least partially the exception safety which we have
>deemed out of scope so far because of an unreasonable cost/benefit
>ratio. i presume we're not going to change our opinion on that point.

No. We will not change this. We have tried to get some partial exception
safety for some of our code during the Symbian days and it was extremely
error prone, a huge pain to maintain and caused an incredible amount of
bloat in the created binaries. Doing this (and maintaining it) for all of
Qt would require a development team a couple of times the size we
currently have, and still would bring new feature development almost to a
standstill.

>regarding 3rd party libraries: some would need to be excluded from the
>support entirely (because they are uncooperative), while others may need
>fixes inside or around the libs. generally, whether they return null or
>throw (while being exception-safe) doesn't matter, as the mechanisms can
>be translated into each other. i don't think the effort for that would
>be prohibitive if we had a serious interest in it, but it certainly
>wouldn't come for free.
>
>
>so to summarize ... color me convinced. replacing malloc it is.

Yes, the best solution IMO is still to use your own malloc and operator
new replacements. In addition, OOM handlers on the OS level can help.

Cheers,

Lars