[Development] Be aware: QtLocation's free MapQuest service discontinued
Hi, Qt Location provides three content/map provider plugins (HERE, MapBox and MapQuest). The first two providers require an account to run and MapQuest was free of any registration so far. Unfortunately this changed this Monday. More details in: https://bugreports.qt.io/browse/QTBUG-54599 As a consequence any QtLocation application that uses MapQuest will no longer receive any map tiles. The only possible way to fix this today is to change from MapQuest to HERE or MapBox. Although those providers require a registration they do offer free of charge usage models. Please be aware of their terms and conditions though. We are very sorry for this problem but at the end of the day there is not much Qt can do. We are working on a patch to change to a new registration free provider and even a related indirection but at the end of the day, registration free access is becoming a thing of the past. Going forward I would suggest to to always consider some form of registered usage for any map provider. While we will continue to address upcoming service changes this does ensure that there is some form of business relationship between you and your chosen map tile provider. At the very least it means that notifications can be received before drastic changes happen. -- Alex ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] leak in QMetaObject?
On 2016-07-14, Thomas Senyk wrote:
I see neither one nor the other. I see continues 100% consume with no
memory consumption drop what so ever.
> should "fix" it? .. but I still see 100% cpu and same memory consumption?
I debugged some time ago a case of a unresponsive application (for 30
seconds on a fairly beefy windows machine with sufficient ram)
There was a memory leak that involved leaking connections to lambdas of
the pattern:
m_foo = std::make_shared();
(void)connect(m_foo.get(), &SomeQObject::someSignal, [m_foo]() {
});
But a interesting point here was that after leaking some thousand
objects, the application became crawling when recreating most of the
UI's quickitems. There was still plenty of memory free on the system.
Plugging this leak didn't do much for the memory consumption of the
application, but the speed of the 'recreate ui' didn't slow down over
time any longer, at least within the testing done with that.
(This was qt5.4.1)
I haven't gotten around investigating it any further. But it kind of
feels relevant here.
/Sune
(I wrote a bit more of that code on http://pusling.com/blog/?p=446
should anyone be curious)
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] leak in QMetaObject?
On quinta-feira, 14 de julho de 2016 19:08:11 PDT Thomas Senyk wrote:
> On 14.07.2016 18:56, Thiago Macieira wrote:
> > On quinta-feira, 14 de julho de 2016 18:37:17 PDT Thomas Senyk wrote:
> >> On 14.07.2016 18:25, Thiago Macieira wrote:
> >>> On quinta-feira, 14 de julho de 2016 17:45:58 PDT Thomas Senyk wrote:
> should "fix" it? .. but I still see 100% cpu and same memory
> consumption?
> >>>
> >>> Can you attach the debugger to see what it is still doing after you're
> >>> done?
> >>
> >> Still the same, goes in circles around in QMetaObject::activate
> >>
> >> #3671 => #3673 => if (!c->receiver) continue => while => ...
> >> ... pressing F10 for a while doesn't let you out of that (short) cycle.
> >>
> >> If you want to know (I know it's not saying much) the values for
> >> list->first and list->last: @0x1529ac0, @0x6a3a3250
> >>
> >>
> >> Is that what you wanted to know? If I misunderstood, please clarify :)
> >
> > I wanted a backtrace. Are you saying the trace is 3700 frames deep?
>
> Sorry that was line numbers :) No it's not.
>
> http://paste.ofcode.org/u3gGqxAfX9hWefeUszDEx
>
> About to generate a callgrind output.
It's a little hard to tell from your backtrace. The Qt Creator copy & paste is
never the right thing, since it doesn't include function parameters. Please
use the gdb "bt" command whenever possible. That means debugging outside
Creator, since Creator can't get the output from that. If that is too
difficult,
the "full backtrace" is a good compromise.
Anyway, I think your test is faulty. When you write:
if ((i%1000)==0) {
QObject::connect(t, &QTimer::timeout, []() {
qDebug() << "test .. it should be empty now?";
});
}
First of all, why did you use a modulo instead of straight up comparison?
Anyway, as far as I can tell, the sender (the QTimer) connectionLists vector
contains 4 entries, only one of which is non-empty. That's the one
corresponding to the timeout() signal. Each connection list is a *singly*
linked list, so it has O(n) behaviour and your n is 10 million.
We talked about cleanConnectionLists. But that function starts with
if (connectionLists->dirty && !connectionLists->inUse) {
For the first 10 million times this function is called, the "dirty" flag is
false. Then your lambdas start getting called and set the "dirty" flag to true.
On the 10 million + 1 time that the function is called, from that connect()
call above, "dirty" is true, but so is "inUse", because you're in the middle
of delivering signals.
So the list isn't cleaned.
After this, there's only one slot connected to the signal, but the list is 10M
+1 items long.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] leak in QMetaObject?
On 14.07.2016 18:56, Thiago Macieira wrote: > On quinta-feira, 14 de julho de 2016 18:37:17 PDT Thomas Senyk wrote: >> On 14.07.2016 18:25, Thiago Macieira wrote: >>> On quinta-feira, 14 de julho de 2016 17:45:58 PDT Thomas Senyk wrote: should "fix" it? .. but I still see 100% cpu and same memory consumption? >>> >>> Can you attach the debugger to see what it is still doing after you're >>> done? >> Still the same, goes in circles around in QMetaObject::activate >> >> #3671 => #3673 => if (!c->receiver) continue => while => ... >> ... pressing F10 for a while doesn't let you out of that (short) cycle. >> >> If you want to know (I know it's not saying much) the values for >> list->first and list->last: @0x1529ac0, @0x6a3a3250 >> >> >> Is that what you wanted to know? If I misunderstood, please clarify :) > > I wanted a backtrace. Are you saying the trace is 3700 frames deep? > Sorry that was line numbers :) No it's not. http://paste.ofcode.org/u3gGqxAfX9hWefeUszDEx About to generate a callgrind output. Greets Thomas ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] leak in QMetaObject?
On quinta-feira, 14 de julho de 2016 18:37:17 PDT Thomas Senyk wrote: > On 14.07.2016 18:25, Thiago Macieira wrote: > > On quinta-feira, 14 de julho de 2016 17:45:58 PDT Thomas Senyk wrote: > >> should "fix" it? .. but I still see 100% cpu and same memory consumption? > > > > Can you attach the debugger to see what it is still doing after you're > > done? > Still the same, goes in circles around in QMetaObject::activate > > #3671 => #3673 => if (!c->receiver) continue => while => ... > ... pressing F10 for a while doesn't let you out of that (short) cycle. > > If you want to know (I know it's not saying much) the values for > list->first and list->last: @0x1529ac0, @0x6a3a3250 > > > Is that what you wanted to know? If I misunderstood, please clarify :) I wanted a backtrace. Are you saying the trace is 3700 frames deep? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] leak in QMetaObject?
On 14.07.2016 18:25, Thiago Macieira wrote: > On quinta-feira, 14 de julho de 2016 17:45:58 PDT Thomas Senyk wrote: >> should "fix" it? .. but I still see 100% cpu and same memory consumption? > > Can you attach the debugger to see what it is still doing after you're done? > Still the same, goes in circles around in QMetaObject::activate #3671 => #3673 => if (!c->receiver) continue => while => ... ... pressing F10 for a while doesn't let you out of that (short) cycle. If you want to know (I know it's not saying much) the values for list->first and list->last: @0x1529ac0, @0x6a3a3250 Is that what you wanted to know? If I misunderstood, please clarify :) Greets Thomas ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] leak in QMetaObject?
On quinta-feira, 14 de julho de 2016 17:45:58 PDT Thomas Senyk wrote: > should "fix" it? .. but I still see 100% cpu and same memory consumption? Can you attach the debugger to see what it is still doing after you're done? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] leak in QMetaObject?
On 14.07.2016 16:48, Giuseppe D'Angelo wrote: > On Thu, Jul 14, 2016 at 4:33 PM, Thomas Senyk > wrote: >> >> Is this expected? A bug? ... I'm happy to fill a bug report, I just >> wanted to get some feedback, maybe I'm just doing something wrong > > First and foremost, which Qt version are you using? :) > Ah yes .. I only mentioned it in the sub-text :) 5.6 branch from git (checkout from this morning) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] leak in QMetaObject?
On 14.07.2016 17:18, André Somers wrote:
>
>
> Op 14/07/2016 om 17:10 schreef Olivier Goffart:
>> On Donnerstag, 14. Juli 2016 16:33:26 CEST Thomas Senyk wrote:
>>> Hi,
>>>
>>> I lately wanted to validate that a connecting&disconnecting to a lambda
>>> will not leak the lambda object .. and found that more then that is
>>> leaked.
>>>
>>> Here is my example: http://paste.ofcode.org/36dmWCT8ddF6Zaqb9csKZNv
>>>
>>> After the 10million connections are executed and disconnected (all of
>>> them a successful), I assume a drop in memory consumption and more
>>> importantly a drop of cpu load to close to 0%.
>>>
>>> I see neither one nor the other. I see continues 100% consume with no
>>> memory consumption drop what so ever.
>>>
>>> I did a quick peak into QMetaObject::activate and it seems no clean up
>>> happened .. the list returned in
>>>list = &connectionLists->at(signal_index);
>>>(line #3660 in 5.6 checkout from today)
>>>
>>> seems rather long! (10million?)
>>>
>>> However all "if (!c->receiver)" shows no receiver and therefor will
>>> continue right away .. at least
>>>
>>> Is this expected? A bug? ... I'm happy to fill a bug report, I just
>>> wanted to get some feedback, maybe I'm just doing something wrong
>>
>> The lambda object and its capture is destroyed by the call to
>>slotObj->destroyIfLastRef()
>>
>> The internal data structre (QObjectPrivate::Connection) is deleted by
>> QObjectPrivate::cleanConnectionLists which is actually only called when
>> a new connection is made to this object.
>>
>> I don't think there is a leak, but it is true that some memory is only
>> free'ed
>> when you add new connection or that the object is destroyed. (but the
>> lambda
>> object is destroyed right after the disconnection)
Then this:
http://paste.ofcode.org/37rxyitynhEqi5gira88hR9
should "fix" it? .. but I still see 100% cpu and same memory consumption?
>>
>>
>>> Some background:
>>> I wanted to check if a single-shot-connection (connection to a signal
>>> and disconnect at first execute, using a lambda as slot) would be a
>>> feasible thing to do.
>> You can do that already:
>>
>> QTimer::sigleShot(100, [] { qDebug() << "hello"; });
>>
> That's not the same thing.
> This looks like my earlier suggestion
> https://bugreports.qt.io/browse/QTBUG-44219
+1, this is similar but not the same,
>
> André
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] leak in QMetaObject?
On Donnerstag, 14. Juli 2016 16:33:26 CEST Thomas Senyk wrote:
> Hi,
>
> I lately wanted to validate that a connecting&disconnecting to a lambda
> will not leak the lambda object .. and found that more then that is leaked.
>
> Here is my example: http://paste.ofcode.org/36dmWCT8ddF6Zaqb9csKZNv
>
> After the 10million connections are executed and disconnected (all of
> them a successful), I assume a drop in memory consumption and more
> importantly a drop of cpu load to close to 0%.
>
> I see neither one nor the other. I see continues 100% consume with no
> memory consumption drop what so ever.
>
> I did a quick peak into QMetaObject::activate and it seems no clean up
> happened .. the list returned in
> list = &connectionLists->at(signal_index);
> (line #3660 in 5.6 checkout from today)
>
> seems rather long! (10million?)
>
> However all "if (!c->receiver)" shows no receiver and therefor will
> continue right away .. at least
>
> Is this expected? A bug? ... I'm happy to fill a bug report, I just
> wanted to get some feedback, maybe I'm just doing something wrong
The lambda object and its capture is destroyed by the call to
slotObj->destroyIfLastRef()
The internal data structre (QObjectPrivate::Connection) is deleted by
QObjectPrivate::cleanConnectionLists which is actually only called when
a new connection is made to this object.
I don't think there is a leak, but it is true that some memory is only free'ed
when you add new connection or that the object is destroyed. (but the lambda
object is destroyed right after the disconnection)
> Some background:
> I wanted to check if a single-shot-connection (connection to a signal
> and disconnect at first execute, using a lambda as slot) would be a
> feasible thing to do.
You can do that already:
QTimer::sigleShot(100, [] { qDebug() << "hello"; });
--
Olivier
Woboq - Qt services and support - https://woboq.com - https://code.woboq.org
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] leak in QMetaObject?
Op 14/07/2016 om 17:10 schreef Olivier Goffart:
On Donnerstag, 14. Juli 2016 16:33:26 CEST Thomas Senyk wrote:
Hi,
I lately wanted to validate that a connecting&disconnecting to a lambda
will not leak the lambda object .. and found that more then that is leaked.
Here is my example: http://paste.ofcode.org/36dmWCT8ddF6Zaqb9csKZNv
After the 10million connections are executed and disconnected (all of
them a successful), I assume a drop in memory consumption and more
importantly a drop of cpu load to close to 0%.
I see neither one nor the other. I see continues 100% consume with no
memory consumption drop what so ever.
I did a quick peak into QMetaObject::activate and it seems no clean up
happened .. the list returned in
list = &connectionLists->at(signal_index);
(line #3660 in 5.6 checkout from today)
seems rather long! (10million?)
However all "if (!c->receiver)" shows no receiver and therefor will
continue right away .. at least
Is this expected? A bug? ... I'm happy to fill a bug report, I just
wanted to get some feedback, maybe I'm just doing something wrong
The lambda object and its capture is destroyed by the call to
slotObj->destroyIfLastRef()
The internal data structre (QObjectPrivate::Connection) is deleted by
QObjectPrivate::cleanConnectionLists which is actually only called when
a new connection is made to this object.
I don't think there is a leak, but it is true that some memory is only free'ed
when you add new connection or that the object is destroyed. (but the lambda
object is destroyed right after the disconnection)
Some background:
I wanted to check if a single-shot-connection (connection to a signal
and disconnect at first execute, using a lambda as slot) would be a
feasible thing to do.
You can do that already:
QTimer::sigleShot(100, [] { qDebug() << "hello"; });
That's not the same thing.
This looks like my earlier suggestion
https://bugreports.qt.io/browse/QTBUG-44219
André
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] leak in QMetaObject?
On Thu, Jul 14, 2016 at 4:33 PM, Thomas Senyk wrote: > > Is this expected? A bug? ... I'm happy to fill a bug report, I just > wanted to get some feedback, maybe I'm just doing something wrong First and foremost, which Qt version are you using? :) Cheers, -- Giuseppe D'Angelo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] leak in QMetaObject?
Hi, I lately wanted to validate that a connecting&disconnecting to a lambda will not leak the lambda object .. and found that more then that is leaked. Here is my example: http://paste.ofcode.org/36dmWCT8ddF6Zaqb9csKZNv After the 10million connections are executed and disconnected (all of them a successful), I assume a drop in memory consumption and more importantly a drop of cpu load to close to 0%. I see neither one nor the other. I see continues 100% consume with no memory consumption drop what so ever. I did a quick peak into QMetaObject::activate and it seems no clean up happened .. the list returned in list = &connectionLists->at(signal_index); (line #3660 in 5.6 checkout from today) seems rather long! (10million?) However all "if (!c->receiver)" shows no receiver and therefor will continue right away .. at least Is this expected? A bug? ... I'm happy to fill a bug report, I just wanted to get some feedback, maybe I'm just doing something wrong Some background: I wanted to check if a single-shot-connection (connection to a signal and disconnect at first execute, using a lambda as slot) would be a feasible thing to do. Greets Thomas ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
