On Friday 19 July 2024 10:00:44 GMT-7 Nuno Santos via Interest wrote:
> Taking this into account. Do you think this could be a bug on Qt?
I have no clue. I don't know the code in question to be able to make a guess
based on the information you've provided. Someone who does may be able to.
Short
Thiago,
Thanks for your analysis.
I don’t know if I have stumbled on a Qt bug or not.
What we have found was that emitting signals even if queued inside a thread
that was started from the audio thread is provoking this locks.
Sometimes it locks the UI but most of the times it locks the audio t
Hi,
I am using a self-compiled packaged version of Qt6 for android aarch64 and
I experience some issues in the build process after my Qt C++ native code
has been compiled successfully.
The part where it should make an APK out of it fails (see output below)
What can I do in this case?
I am using
On Friday 19 July 2024 07:15:19 GMT-7 Nuno Santos via Interest wrote:
> (lldb) bt all
> * thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
> * frame #0: 0x0001db7aa1cc libsystem_kernel.dylib`__psynch_cvwait + 8
> frame #1: 0x0001ef5096e4 libsystem_pthread.dylib
On Friday 19 July 2024 03:30:40 GMT-7 Nuno Santos via Interest wrote:
> That’s the biggest problem. It happens s RARELY.
>
> We can’t find a sistematic way of reproducing it. That is why I was trying
> to find a more analytical way of detecting it.
You don't need that. Can you reproduce the p
Alexey,
Thanks for your reply.
Sure, here it is:
(lldb) bt all
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
* frame #0: 0x0001db7aa1cc libsystem_kernel.dylib`__psynch_cvwait + 8
frame #1: 0x0001ef5096e4 libsystem_pthread.dylib`_pthread_cond_wait +
122
Deadlocks usually occur across several threads. Do you have a stack
trace for other threads, too?
Alexey
On Fri, 2024-07-19 at 12:12 +0100, Nuno Santos via Interest wrote:
> Dennis,
>
> Thanks for the clarification.
>
> Maybe it is deviating a bit from Qt. It’s probably something I’m not
> doin
Am 19.07.2024 um 13:12 schrieb Nuno Santos:
Here is the place it got stuck in the audio render thread. It got locked when
invoking the method.
Does this ring any bell?
no idea, sorry
___
Interest mailing list
Interest@qt-project.org
https://lists.qt
Dennis,
Thanks for the clarification.
Maybe it is deviating a bit from Qt. It’s probably something I’m not doing
correctly from the Qt paradigm perspective but this is one of those problems
where I feeling lost.
I’ve just had one of those rare deadlock and it happened like this:
- This is a m
Am 19.07.2024 um 12:52 schrieb Nuno Santos:
Can data race cause deadlocks?
Or should I explicitly look for deadlock: "lock-order-inversion (potential
deadlock)”
data races can maybe get you into deadlocks someway... but you should
look for lock-order-inversions and fix them (even if very har
Sorry, Nuno.
I've never tried thread-sanitizer.
Instead, strace on linux or connecting from a debugger on all platforms
were helpful.
Kind regards,
Robert Iakobashvili
On Fri, Jul 19, 2024 at 1:52 PM Nuno Santos
wrote:
> Dennis,
> Robert,
>
> One more question.
>
Dennis,
Robert,
One more question.
When using thread sanitiser in the MacOS version I can only see "SUMMARY:
ThreadSanitizer: data race”. A lot of them.
Can data race cause deadlocks?
Or should I explicitly look for deadlock: "lock-order-inversion (potential
deadlock)”
Thanks!
Regards,
Nun
Dennis,
I’m willing to try to run this on Linux and see if I can spot anything there.
It might take me a while to setup though.
I have built Qt with -sanitize thread.
When using that kit, the -fsanitize=thread option is automatically applied to
the program as well, manually applying:
QMAKE_C
Am 19.07.2024 um 12:30 schrieb Nuno Santos:
That’s the biggest problem. It happens s RARELY.
We can’t find a sistematic way of reproducing it. That is why I was trying to
find a more analytical way of detecting it.
can you're app be build and run on linux - sometimes the problems
getting
> When you can reproduce deadlock on iOS from your dev-environment,
> try to connect from XCode debugging and assess the situation.
> There are changes you can detect where you have this deadlock.
That’s the biggest problem. It happens s RARELY.
We can’t find a sistematic way of reproducing
On Fri, Jul 19, 2024 at 12:18 PM Dennis Luehring via Interest <
interest@qt-project.org> wrote:
> Am 19.07.2024 um 11:02 schrieb Nuno Santos:
> > I don’t know but this is what happens. Look in the second line the
> > bolded part:
> >
> >
> /Applications/Xcode.app/Contents/Developer/Toolchains/Xcod
Am 19.07.2024 um 11:02 schrieb Nuno Santos:
I don’t know but this is what happens. Look in the second line the
bolded part:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++
-c -pipe -stdlib=libc++ -O2 -std=gnu++1z -arch arm64 -isysroot
/Applicatio
Dennis,
I don’t know but this is what happens. Look in the second line the bolded part:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++
-c -pipe -stdlib=libc++ -O2 -std=gnu++1z -arch arm64 -isysroot
/Applications/Xcode.app/Contents/Developer/Platf
Am 19.07.2024 um 10:46 schrieb Nuno Santos:
Apparently, compiling Qt with -sanitize thread automatically applies to the
applications as well.
I have checked the compile output and it was being applied already.
how should that happen? only if your application is part of Qt build itself
and you
Dennis,
Apparently, compiling Qt with -sanitize thread automatically applies to the
applications as well.
I have checked the compile output and it was being applied already.
Regards,
Nuno
> On 18 Jul 2024, at 18:59, Dennis Luehring wrote:
>
> Am 18.07.2024 um 17:24 schrieb Nuno Santos:
>> H
20 matches
Mail list logo
