kfunk added a comment.
In https://phabricator.kde.org/D2545#69298, @thiago wrote:
> In https://phabricator.kde.org/D2545#69187, @kfunk wrote:
>
> > In https://phabricator.kde.org/D2545#69091, @thiago wrote:
> >
> > > There doesn't seem to be a way of doing some clean up before the
thiago added a comment.
In https://phabricator.kde.org/D2545#69187, @kfunk wrote:
> In https://phabricator.kde.org/D2545#69091, @thiago wrote:
>
> > There doesn't seem to be a way of doing some clean up before the threads
are forcibly killed.
> >
> > Maybe if I abuse qtmain().
>
kfunk added a comment.
In https://phabricator.kde.org/D2545#69091, @thiago wrote:
> There doesn't seem to be a way of doing some clean up before the threads
are forcibly killed.
>
> Maybe if I abuse qtmain().
This would only fix it for non-console GUI applications if I underst
kfunk added a comment.
For the record, since I don't see an easy fix I'm pondering about patching
qtbase in craft.git:
Ideas:
a ) Add this to QDBusConnectionManager ctor:
qAddPostRoutine([]() {
QMetaObject::invokeMethod(QDBusConnectionManager::instance(), "quit");
thiago added a comment.
More information on this Windows behaviour:
- https://blogs.msdn.microsoft.com/oldnewthing/20070503-00/?p=27003
- https://blogs.msdn.microsoft.com/oldnewthing/20070502-00/?p=27023/#2375204
There doesn't seem to be a way of doing some clean up before the threa
thiago added a comment.
In https://phabricator.kde.org/D2545#69083, @kfunk wrote:
> > Here's the other problem: it's possible for threads to simply disappear
on Windows. Given that I see "dllmain" in the backtrace (though not DllMain), I
can't rule out that this has happened. Qt 5.6 has
kfunk added a comment.
> Here's the other problem: it's possible for threads to simply disappear on
Windows. Given that I see "dllmain" in the backtrace (though not DllMain), I
can't rule out that this has happened. Qt 5.6 has a workaround to another
deadlock caused by Windows. Can you try t
thiago added a comment.
In https://phabricator.kde.org/D2545#66904, @thiago wrote:
> Commit ad66dbe305cff72443f4d3484191872d56e6dfbb in qtbase did try to solve
this by disconnecting the senders when the objects were getting deleted.
closeConnection() is called before the thread exits (fr
thiago added a comment.
In https://phabricator.kde.org/D2545#66545, @kfunk wrote:
> In https://phabricator.kde.org/D2545#65976, @dfaure wrote:
>
> > Actually, I think Thiago's still waiting for a backtrace of all threads.
>
>
> I think I've already said this via other channels: T
kfunk added a comment.
In https://phabricator.kde.org/D2545#65976, @dfaure wrote:
> Actually, I think Thiago's still waiting for a backtrace of all threads.
I think I've already said this via other channels: There's only one thread
left at this point.
BRANCH
master
REVISION DE
dfaure added a comment.
Actually, I think Thiago's still waiting for a backtrace of all threads.
BRANCH
master
REVISION DETAIL
https://phabricator.kde.org/D2545
EMAIL PREFERENCES
https://phabricator.kde.org/settings/panel/emailpreferences/
To: kfunk, vonreth, dfaure
Cc: albertvaka, mu
albertvaka added a comment.
Since there is no fix on Qt, should we merge this?
BRANCH
master
REVISION DETAIL
https://phabricator.kde.org/D2545
EMAIL PREFERENCES
https://phabricator.kde.org/settings/panel/emailpreferences/
To: kfunk, vonreth, dfaure
Cc: albertvaka, mutlaqja, arrowdodge
mutlaqja added a comment.
Any update on this?
BRANCH
master
REVISION DETAIL
https://phabricator.kde.org/D2545
EMAIL PREFERENCES
https://phabricator.kde.org/settings/panel/emailpreferences/
To: kfunk, vonreth, dfaure
Cc: mutlaqja, arrowdodger, #frameworks
dfaure added a comment.
We need a backtrace with all threads to understand what's happening.
BRANCH
master
REVISION DETAIL
https://phabricator.kde.org/D2545
EMAIL PREFERENCES
https://phabricator.kde.org/settings/panel/emailpreferences/
To: kfunk, vonreth, dfaure
Cc: arrowdodger, #fram
kfunk added a comment.
Here's the backtrace (note: using Qt 5.6 branch):
ntdll.dll!NtWaitForSingleObject() Unknown
KernelBase.dll!7ffbcb2eaadf() Unknown
> Qt5Core.dll!QWaitCondition::wait(QMutex * mutex=0x01c24fd16520,
unsigned long time=4294967295)
dfaure added a comment.
So what is the actual deadlock you're experiencing?
I showed this to Thiago and he said he needs more info on what is actually
happening, i.e. where exactly it deadlocks in QtDBus.
BRANCH
master
REVISION DETAIL
https://phabricator.kde.org/D2545
EMAIL PREFERE
arrowdodger added a comment.
In https://phabricator.kde.org/D2545#48488, @dfaure wrote:
> Hmm can you check if https://codereview.qt-project.org/161056 fixes it?
I've tried both Thiago patches on 5.7 branch and they don't fix this problem.
BRANCH
master
REVISION DETAIL
https:
dfaure added a comment.
Hmm can you check if https://codereview.qt-project.org/161056 fixes it?
BRANCH
master
REVISION DETAIL
https://phabricator.kde.org/D2545
EMAIL PREFERENCES
https://phabricator.kde.org/settings/panel/emailpreferences/
To: kfunk, vonreth, dfaure
Cc: #frameworks
kfunk added a comment.
Bump?
REVISION DETAIL
https://phabricator.kde.org/D2545
EMAIL PREFERENCES
https://phabricator.kde.org/settings/panel/emailpreferences/
To: kfunk, dfaure, vonreth
Cc: #frameworks
19 matches
Mail list logo