On Tuesday 10 March 2015 10:10:46 Alex Montgomery wrote:
> > Note that we're talking about a standard violation in the first place. The
> > standard says you can replace operator new, so if MSVC doesn't allow you
> > to do it properly, then you can throw the standard out of the window. If
> > an in
> Note that we're talking about a standard violation in the first place. The
> standard says you can replace operator new, so if MSVC doesn't allow you to do
> it properly, then you can throw the standard out of the window. If an inline
> operator new (for MSVC only) solved the problem, it would be
On Tuesday 10 March 2015 08:18:42 Koehne Kai wrote:
> > Except that dynamically linked Windows Qt applications (read: most) don't
> > work this way, so Windows users are left out in the cold. DLLs do not
> > allow
> > you to simply replace one new operator across link boundaries. See the
> > commen
Hi,
On Tue, Mar 10, 2015 at 10:55 AM, Al-Khanji Louai
wrote:
> It's my understanding that on Windows you link the global operator new/delete
> replacement into every dll separately.
Well there is a very hackish but easier way, patching libcmt.lib to
remove allocation functionality:
https://gith
ll Lars
> Cc: development@qt-project.org
> Subject: Re: [Development] QtCore missing check for memory allocation
>
> On Mon, Mar 9, 2015 at 12:57 AM, Knoll Lars
> wrote:
>
> > Yes, the best solution IMO is still to use your own malloc and
> > operator new replacements.
> Cc: development@qt-project.org
> Subject: Re: [Development] QtCore missing check for memory allocation
>
> On Mon, Mar 9, 2015 at 12:57 AM, Knoll Lars
> wrote:
>
> > Yes, the best solution IMO is still to use your own malloc and
> > operator new replacements. In addition, O
On Mon, Mar 9, 2015 at 12:57 AM, Knoll Lars wrote:
> 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.
Except that dynamically linked Windows Qt applications (read: most)
don't work this way, so Windows
On Monday 09 March 2015 07:57:18 Knoll Lars wrote:
> 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 pr
On 03/03/15 22:10, "Oswald Buddenhagen"
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
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
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)
> function
On Fri, Feb 27, 2015 at 09:26:14AM -0800, Thiago Macieira wrote:
> On Friday 27 February 2015 09:20:54 Oswald Buddenhagen wrote:
> > the whole point would be *not* using unwrapped malloc and new(nothrow).
> > this can be trivially verified for our own code with a grepping bot.
>
> There's an easie
On Friday 27 February 2015 11:15:03 Al-Khanji Louai wrote:
> In that case they cannot be overwritten without a recompile. Which brings me
> back to my original comment from yesterday (to which no one replied):
>
> How is that different from linking a custom implementation of operator
> new/operato
On Friday 27 February 2015 09:20:54 Oswald Buddenhagen wrote:
> the whole point would be *not* using unwrapped malloc and new(nothrow).
> this can be trivially verified for our own code with a grepping bot.
There's an easier solution.
See the reply to Louai.
> > > then explain edd2d9bd0a7f5dbe05
> -Original Message-
> From: Gunnar Roth [mailto:gunnar.r...@gmx.de]
> Sent: Friday, February 27, 2015 2:11 PM
> To: Al-Khanji Louai
> Cc: development@qt-project.org
> Subject: Aw: Re: [Development] QtCore missing check for memory allocation
>
> Hi,
>
> > in
Hi,
> in fact both C++11 and C++14 have improved the ways in which the new/delete
> operators can be overridden.
can you give me some links describing these improvements?
regards,
Gunnar Roth
___
Development mailing list
Development@qt-project.org
qtcompany.com@qt-
> project.org [mailto:development-bounces+louai.al-
> khanji=theqtcompany@qt-project.org] On Behalf Of Koehne Kai
> Sent: Friday, February 27, 2015 12:57 PM
> To: Robin Burchell; development@qt-project.org
> Subject: Re: [Development] QtCore miss
project.org
> Subject: Re: [Development] QtCore missing check for memory allocation
>
> On Fri, Feb 27, 2015 at 9:20 AM, Oswald Buddenhagen
> wrote:
> >> The argument is that it implies runtime overhead. See Robin's email
> >> for numbers. This is asking for making
On Fri, Feb 27, 2015 at 9:20 AM, Oswald Buddenhagen
wrote:
>> The argument is that it implies runtime overhead. See Robin's email for
>> numbers. This is asking for making the code slower on the very devices where
>> it needs to run faster.
>>
> i don't trust this number. i don't know how qMalloc
On Thu, Feb 26, 2015 at 04:12:27PM -0800, Thiago Macieira wrote:
> On Thursday 26 February 2015 20:54:32 Oswald Buddenhagen wrote:
> > > Let me put it this way: who's going to write the unit tests to ensure we
> > > get coverage for all those conditionals? Any volunteers?
> >
> > which conditional
On Thursday 26 February 2015 21:05:31 Oswald Buddenhagen wrote:
> even assuming that nobody else had an interest in this, you'd still need
> rather good reasons to effectively sabotage another contributor's
> interest, especially considering the majority situation.
I do have good reasons. See the
On Thursday 26 February 2015 20:54:32 Oswald Buddenhagen wrote:
> > Let me put it this way: who's going to write the unit tests to ensure we
> > get coverage for all those conditionals? Any volunteers?
>
> which conditionals? the malloc wrapper would throw/qFatal (depending on
> the build configur
On Thu, Feb 26, 2015 at 11:33:17AM -0800, Thiago Macieira wrote:
> On Thursday 26 February 2015 20:16:43 Oswald Buddenhagen wrote:
> > > There's no feature on Linux to do that. Overcommit is always enabled.
> >
> > wrong.
> > https://www.kernel.org/doc/Documentation/vm/overcommit-accounting
>
> H
On Thu, Feb 26, 2015 at 10:25:42AM -0800, Thiago Macieira wrote:
> On Wednesday 25 February 2015 20:07:58 Oswald Buddenhagen wrote:
> > as ulf pointed out, a rather trivial wrapper which ensures deterministic
> > behavior is hardly a burden.
>
> And I disagree that it's hardly a burden. I am sayin
On Thursday 26 February 2015 20:16:43 Oswald Buddenhagen wrote:
> > There's no feature on Linux to do that. Overcommit is always enabled.
>
> wrong.
> https://www.kernel.org/doc/Documentation/vm/overcommit-accounting
Have you read the file you linked to?
Options are:
0 Heuristic overcommit
On Thu, Feb 26, 2015 at 10:27:05AM -0800, Thiago Macieira wrote:
> On Wednesday 25 February 2015 20:09:21 Oswald Buddenhagen wrote:
> > On Wed, Feb 25, 2015 at 08:38:21AM -0800, Thiago Macieira wrote:
> > > On Wednesday 25 February 2015 17:20:54 Christian Kandeler wrote:
> > > > Also, you are not e
On Thursday 26 February 2015 19:22:56 Konstantin Tokarev wrote:
> When using such a large library as Qt is quite hard to get along with
> disabled overcommit on embedded device (because you need to keep your
> application's VmSize under than size of physical memory).
That's not necessary.
Let me
On Wednesday 25 February 2015 21:29:31 Marc Mutz wrote:
> > -- 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
On Wednesday 25 February 2015 20:09:21 Oswald Buddenhagen wrote:
> On Wed, Feb 25, 2015 at 08:38:21AM -0800, Thiago Macieira wrote:
> > On Wednesday 25 February 2015 17:20:54 Christian Kandeler wrote:
> > > Also, you are not even guaranteed to get a null pointer/bad_alloc due to
> > > things like L
On Wednesday 25 February 2015 20:07:58 Oswald Buddenhagen wrote:
> On Wed, Feb 25, 2015 at 08:01:54AM -0800, Thiago Macieira wrote:
> > On Wednesday 25 February 2015 16:48:44 Ulf Hermann wrote:
> > > >> We should thus do Q_CHECK_PTR on every memory allocation in Qt and we
> > > >> should fix Q_CHEC
25.02.2015, 22:09, "Oswald Buddenhagen" :
> On Wed, Feb 25, 2015 at 08:38:21AM -0800, Thiago Macieira wrote:
>> On Wednesday 25 February 2015 17:20:54 Christian Kandeler wrote:
>>> Also, you are not even guaranteed to get a null pointer/bad_alloc due to
>>> things like Linux overcommitting.
>>
How is that different from linking a custom implementation of operator
new/operator delete and malloc/free into Qt?
These are embedded use-cases anyway, so you wouldn’t be using a stock Qt
binary. Implementing the above is well-documented, and in fact both C++11 and
C++14 have improved the way
On Wed, Feb 25, 2015 at 10:17 PM, Konstantin Ritt wrote:
> Maybe a bit off-topic: can we introduce our own (probably customizable)
> memory allocation API, something like Apple's CFAllocator [1], and move Qt
> internals to use it instead of malloc/realloc/free (and maybe instead of
> some new/dele
Maybe a bit off-topic: can we introduce our own (probably customizable)
memory allocation API, something like Apple's CFAllocator [1], and move Qt
internals to use it instead of malloc/realloc/free (and maybe instead of
some new/delete-s, based on some policies)?
Then we could let the user to deci
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 doe
On Wednesday 25 February 2015 17:36:39 Mathias Hasselmann wrote:
[...]
> Writing allocation-safe code was considering a good idea years ago.
> Sadly the people supporting that approach totally forgot that checking
> each memory allocation dramatically inflates cyclomatic complexity of
> your code,
On Wed, Feb 25, 2015 at 08:38:21AM -0800, Thiago Macieira wrote:
> On Wednesday 25 February 2015 17:20:54 Christian Kandeler wrote:
> > Also, you are not even guaranteed to get a null pointer/bad_alloc due to
> > things like Linux overcommitting.
>
> Which is one of the reasons why we don't check
On Wed, Feb 25, 2015 at 08:01:54AM -0800, Thiago Macieira wrote:
> On Wednesday 25 February 2015 16:48:44 Ulf Hermann wrote:
> > >> We should thus do Q_CHECK_PTR on every memory allocation in Qt and we
> > >> should fix Q_CHECK_PTR so that it works under all circumstances.
> > >
> > > I disagree o
> You are contradicting yourself. Just a few minutes ago you considered it
> a problem, if you don't know the exact location of a failed allocation.
> Now when it comes to overcommiting you say not knowing the location is
> not a problem. I am confused now.
When overcommitting, the kernel will giv
> The commonly accepted solution to that problem is using memory debuggers
> like Valgrind. They are sufficiently sophisticated to tell you exactly
> where your bad pointer comes from. Ideally you have the resources to let
> your CI run your automated tests with such debugger.
Bad code which acce
Am 25.02.2015 um 17:34 schrieb Ulf Hermann:
>
>> Also, you are not even guaranteed to get a null pointer/bad_alloc
>> due to things like Linux overcommitting.
>
> Overcommitting is not dangerous as it will reliably lead to the
> process getting killed if it goes wrong. If you can exploit that, we
On Wednesday 25 February 2015 17:20:54 Christian Kandeler wrote:
> Also, you are not even guaranteed to get a null pointer/bad_alloc due to
> things like Linux overcommitting.
Which is one of the reasons why we don't check for malloc failures. Modern
memory allocators with overcommitting and OOM
> Also, you are not even guaranteed to get a null pointer/bad_alloc due to
> things like Linux overcommitting.
Overcommitting is not dangerous as it will reliably lead to the process getting
killed if it goes wrong. If you can exploit that, we have a much worse problem,
and not only in Qt.
Ulf
Am 25.02.2015 um 16:48 schrieb Ulf Hermann:
> The point is this: With the current behavior you're not actually
> guaranteed to get a segfault. The client code might not access *p,
> but rather p[], and that might hit valid memory.
> Or it might store p, do whatever funny arithmetic on it with the
On 02/25/2015 04:30 PM, Giuseppe D'Angelo wrote:
> Il 25/02/2015 13:35, Ulf Hermann ha scritto:
>>> I noticed that in qglobal.h Q_CHECK_PTR may be a noop in case
>>> QT_NO_DEBUG is set. Q_CHECK_PTR is used to check if memory allocations
>>> succeeded (e.g. QVector::reallocateData).
>>
>> Until 9d44
On Wednesday 25 February 2015 16:48:44 Ulf Hermann wrote:
> >> We should thus do Q_CHECK_PTR on every memory allocation in Qt and we
> >> should fix Q_CHECK_PTR so that it works under all circumstances.
> >
> > I disagree on both accounts.
>
> Could you elaborate a bit?
I disagree that we should
>> We should thus do Q_CHECK_PTR on every memory allocation in Qt and we should
>> fix Q_CHECK_PTR so that it works under all circumstances.
>
> I disagree on both accounts.
Could you elaborate a bit?
That "every memory allocation" may be relaxed a bit as there might be places
where the code can
Il 25/02/2015 13:35, Ulf Hermann ha scritto:
I noticed that in qglobal.h Q_CHECK_PTR may be a noop in case
QT_NO_DEBUG is set. Q_CHECK_PTR is used to check if memory allocations
succeeded (e.g. QVector::reallocateData).
Until 9d44645eae144fcfefa0de2455d41f04d29c40d4 (September 2014) most of QVe
On Wednesday 25 February 2015 14:45:02 Rainer Keller wrote:
> At least show a useful error message in any case. Right now the message
> is SEGV.
Which is useful.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
___
On Wednesday 25 February 2015 13:35:17 Ulf Hermann wrote:
> We should thus do Q_CHECK_PTR on every memory allocation in Qt and we should
> fix Q_CHECK_PTR so that it works under all circumstances.
I disagree on both accounts.
> > Is QT_NO_DEBUG really disabling the check for valid memory allocati
> because memory allocation can fail for a number of reasons, not only because
> you have requested a too large single chunk of memory.
Exactly, for example if other applications are consuming most of the memory.
> Furthermore people keep saying "What can we do if we detect a
> failed memory allo
> I noticed that in qglobal.h Q_CHECK_PTR may be a noop in case
> QT_NO_DEBUG is set. Q_CHECK_PTR is used to check if memory allocations
> succeeded (e.g. QVector::reallocateData).
Until 9d44645eae144fcfefa0de2455d41f04d29c40d4 (September 2014) most of
QVector's allocations weren't checked at all
> Anyhow, what's the problem with that?
The problem is that memory allocation fails and Qt continues without
checking the pointers ending up in a SEGV.
Would a fix be in Q_CHECK_PTR to abort in this case (exception or
qFatal) or should QVector get an additional check for null-pointer in
addition t
Il 25/02/2015 12:39, Rainer Keller ha scritto:
Is QT_NO_DEBUG really disabling the check for valid memory allocation?
It also depends on exception support, but yes. Also unlike Q_ASSERT
there isn't an equivalent of QT_FORCE_ASSERTS to make the check present
in non-debug no-exceptions builds..
Hi,
I noticed that in qglobal.h Q_CHECK_PTR may be a noop in case
QT_NO_DEBUG is set. Q_CHECK_PTR is used to check if memory allocations
succeeded (e.g. QVector::reallocateData).
Is QT_NO_DEBUG really disabling the check for valid memory allocation?
Rainer
___
55 matches
Mail list logo
