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 inline
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
comments 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
Subject: Re: [Development] QtCore missing check for memory allocation
On Mon, Mar 9, 2015 at 12:57 AM, Knoll Lars
lars.kn...@theqtcompany.com 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
: development@qt-project.org
Subject: Re: [Development] QtCore missing check for memory allocation
-Original Message-
From: development-bounces+kai.koehne=theqtcompany.com@qt-
project.org [mailto:development-
bounces+kai.koehne=theqtcompany@qt-project.org] On Behalf Of
Alex Montgomery
Hi,
On Tue, Mar 10, 2015 at 10:55 AM, Al-Khanji Louai
louai.al-kha...@theqtcompany.com 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
On Mon, Mar 9, 2015 at 12:57 AM, Knoll Lars lars.kn...@theqtcompany.com 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
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
On 03/03/15 22:10, Oswald Buddenhagen
oswald.buddenha...@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
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
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 easier
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
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/operator
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
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 fact both C++11 and C++14 have improved the ways in which
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 conditionals? the
On Fri, Feb 27, 2015 at 9:20 AM, Oswald Buddenhagen
oswald.buddenha...@theqtcompany.com 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
: [Development] QtCore missing check for memory allocation
On Fri, Feb 27, 2015 at 9:20 AM, Oswald Buddenhagen
oswald.buddenha...@theqtcompany.com 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
-
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 missing check for memory allocation
-Original
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
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
25.02.2015, 22:09, Oswald Buddenhagen oswald.buddenha...@theqtcompany.com:
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
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 saying it
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
Have you
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 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 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 Linux
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_CHECK_PTR so
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 even
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
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
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
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
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
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 deal
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 allocation?
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 do
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
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
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
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[some large number], and that might hit valid memory.
Or it might store p, do whatever funny arithmetic
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 give
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
have
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
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
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: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 on both
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 for
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
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
On Wed, Feb 25, 2015 at 10:17 PM, Konstantin Ritt ritt...@gmail.com 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
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
53 matches
Mail list logo
