> 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 soooo 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. Thanks for your help! Regards, Nuno > On 19 Jul 2024, at 11:16, coroberti <corobe...@gmail.com> wrote: > > > > > On Fri, Jul 19, 2024 at 12:18 PM Dennis Luehring via Interest > <interest@qt-project.org <mailto: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/XcodeDefault.xctoolchain/usr/bin/clang++ >> > -c -pipe -stdlib=libc++ -O2 -std=gnu++1z -arch arm64 -isysroot >> > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.2.sdk >> > -mmacosx-version-min=11.0 -fsanitize=thread -fno-omit-frame-pointer - >> >> maybe its a MacOS develop environment magic but on linux/clang its not >> automaticly done >> because i maybe just want to check the Qt-Libs "OR" my app seperated for >> TSAN findings >> >> i think you're doing it someway wrong >> >> > Does anyone have alternatives? >> >> is GDB an option on iOS? >> then follow these instructions >> >> https://ethanhao.github.io/c++11,/gdb,/multithread,/2017/03/03/Deadlock-detecting-using-GDB-Copy.html >> >> > Yes, it's a good idea. > > 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. > > Kind regards, > Robert Iakobashvili > ............................ >
_______________________________________________ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
