[Development] QtCore missing check for memory allocation
marc.mutz at kdab.com
Wed Feb 25 21:29:31 CET 2015
On Wednesday 25 February 2015 16:30:56 Giuseppe D'Angelo wrote:
> And on the other hand, this assumption of having infinite memory has
> held for a while
Only in the niche that Qt exists in. Now, the question is whether Qt does not
play a role in systems that handle oom gracefully because Qt doesn't handle
them gacefully or whether it doesn't play a role in those systems because
there are no such systems.
But I'm sure there are embedded systems that fall in between the desktop model
of inifinite VM space and hard-realtime systems that allow no dynamic memory
allocations after program initialisation. For such systems, recovering from
oom is actually a plausible alternative. Relying on the oom killer in a soft
realtime application is asking for trouble. It can literally take an hour for
the system to recover. I just experienced a 50min thrashing when I dared to
start up a 4GB VM without waiting for qtcreator to fully quit. The oom killer
killed qt-creator, but it _did_ take 50mins.
As Ossi said, overcommitting is likely turned off in those systems. BTW, IIRC,
you also get nullptr mallocs (without thrashing swap first when you run into
If Qt wants to be(come) relevant to that part of the embedded space (or that
part of server space that still uses ulimit), we better stop acting like
there's only infinite memory.
> -- why should now people have a slower library because
> of all those checks?
Q_CHECK_PTR does not necessarily make the library slower. It only needs to be
applied to malloc/calloc and nothrow operator new, because ordinary new
already throws. We can port such code to normal operator new instead.
Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-Independent Software Solutions
More information about the Development