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
Hi all.
Currently I can not clone any of repo using the "git clone" command,
this attempt hangs forever on my ArchLinux:
"
[denis@pclab serial]$ git clone ssh://
codereview.qt-project.org:29418/qt/qtserialport.git
Cloning into 'qtserialport'...
^C
[denis@pclab serial]$ git clone ssh://
codere
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
Is there any news on when Qt 4.8.7 is planned to be released?
I saw there have been snapshots available but do not have clue which are
the blocker issues.
Thanks,
Calogero
--
Calogero Mauceri
Software Engineer
Applied Coherent Technology Corporation (ACT)
www.actgate.com
___
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
On Wednesday 25 February 2015 16:35:38 Kurt Pattyn wrote:
> Hi,
>
> we compiled a project using Qt 5.4.1 (Windows 7 64-bit MSVS 2013) and then
> tried to run it on a computer with Qt 5.3.2 installed. We received the
> following popup:
>
>
>
> Is there any chance that this is still a binary comp
Hi,
we compiled a project using Qt 5.4.1 (Windows 7 64-bit MSVS 2013) and then
tried to run it on a computer with Qt 5.3.2 installed.
We received the following popup:
Is there any chance that this is still a binary compatibility problem?
Of so, I will enter it into the bugreports.
Cheers,
Ku
> -Original Message-
> From: development-bounces+kai.koehne=theqtcompany.com@qt-
> project.org [mailto:development-
> bounces+kai.koehne=theqtcompany@qt-project.org] On Behalf Of Kurt
> Pattyn
> Sent: Wednesday, February 25, 2015 4:36 PM
> To:
> Subject: [Development] Binary compatib
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
On 2015-02-20 04:04, André Somers wrote:
> Bo Thorsen schreef op 20-2-2015 om 09:03:
>> Andrés question about how this would change the API is a lot more
>> interesting. I so far haven't seen a single case where someone has
>> described how access to lambdas might improve the API. If they are
>>
On Wednesday 25 February 2015 16:01:18 Tomasz Olszak wrote:
> Is there any possibility to reconsider Qt World Summit date?
Kathy replied on the marketing list: no it isn't, as the dates are fixed due to
venue availability.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect
2015-02-20 17:12 GMT+01:00 Thiago Macieira :
> As priorities go, Embedded Linux Conference Europe[1] and LinuxCon Europe[2]
> take precedence over the Qt World Summit. So short of someone coming up with
> practical cloning by then, I won't be able to come to Berlin.
>
> [1] http://events.linuxfound
> 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
On Tuesday 24 February 2015 12:13:46 Thiago Macieira wrote:
> On Tuesday 24 February 2015 14:01:39 Adam Majer wrote:
> > A signed tag automatically verifies the entire history as being
> > authentic (up to the tag).
> >
> > - Adam
> >
> > PS. GPG signed releases would also be nice in addition to
> 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
Tor Arne,
As a test I modified my setup on OS X yesterday to pass
-DCMAKE_INSTALL_DATADIR="/Users/jeremy/Library/Application Support/" to
every KDE module's cmake comand. This successfully installed all supporting
data files into ~/Library/Application Support/foo and only required a
couple of mino
> 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..
On 25/02/15 12:31, Tor Arne Vestbø wrote:
> This should be fixed for OS X (and iOS). ~/Library/Application Support
> can be used for installed application data, but is most typically used
> for generated application data that is not directly user documents
> (which should live in ~/Documents), so t
On 25/02/15 01:04, Thiago Macieira wrote:
> On Wednesday 25 February 2015 00:44:49 Kevin Kofler wrote:
>> Still, I don't understand the strong resistance to implementing this.
>> Supporting XDG_* everywhere helps portability and does not hurt the
>> non-freedesktop.org platforms in any way. If the
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
___
Thanks for the write up Jeremy,
On 24/02/15 07:24, Jeremy Whiting wrote:
> QStandardPaths is useful to give paths to various places that are common
> to all platforms. ConfigLocation tells where configurations should be
> stored or read from, GenericDataLocation is where data should be,
> AppDataL
Hi Thiago,
that was the right hint. I had to create the .git dir in every module dir.
I did get the code by using git, but i have a copy script which copies the relevant parts of the qt src code and i ignored the .git directories.
So thank you very much for your help.
Regards,
Gunnar
37 matches
Mail list logo
