-
-
Notifications
You must be signed in to change notification settings - Fork 42
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
raiseQThreadAffinityException cores java instead of throwing an exception #66
Comments
Perhaps the fact that it just shows this in logs all the time the app is running is related: |
Is it possible for you to attach .pdb files for qt jambi libs? Without them it's very hard to debug, since I can't use sources and repository code always fails to compile on my visual studio |
It also fails like this:
|
Thanks for the bug report. I'll look at it on Monday. As a first impression: It looks like, one of the QThreads is a dangling pointer. Thus typeid(*pointer) crashes. Could you show me the Java code causing this situation? |
Unfortunately there is no a single point of failure, it happens at random moments of interacting with qml components using mouse, sometimes even that is not required and it just crashes right after showing the qml ui. @omix I believe it would be easy to find exact cause if you could provide .pdb files for msvc_2019 windows build of qtjambi 6.2.5, then I would be able to see what exactly causes it in the debugger |
Please try to run your program with JVM argument -Dio.qt.disable-thread-affinity-check=true. This disables the thread check causing the crash. I assume, then the program will crash due to a thread-affine event call. But however, maybe this crash may at least give you more information. Hopefully. |
@omix with flag for disabling jambi thread checks, app runs just fine and doesn't crash at all. When I enbled qtjambi thread checks again, I managed to reproduce the crash in a few seconds after the app had started. I suspect jambi is wrong with its' thread check here. |
Can you give me example code to reproduce it? |
@omix unfortunately I can't send you soruces right now because they have too9 much company code, but I am trying to reproduce the situation in some demo. Could you please in parallel create .pdb files for qtjamvi v6.2.5? Sources always fail to compile for me for msvc2019 compiler so I can't make them myself. |
So far I can tell that it's thrown in qtjambi/src/cpp/qtjambi/qtjambi_core.cpp Line 6745 in b0447ef
|
I already identified the line where to expect the crash. Actually, the crash is not caused by the exception but shortly before creating the exception. The exception is actually a Java exception to be caught in Java. However, there is an error with real time type information of one of the thread pointers. It seems one of it is dangling. Well, but that makes no sense because Well, there could be one scenario I did not check until now: the QThread is created and deleted in native code (e.g. by QML engine). There is a QObject associated to this thread that survives the deletion of the QThread object. This might be caused by bringing the object to Java or creating it in Java. then, it is managed by Java GC and could survive native QThread. |
What doesn't work with compiling? |
Compile works now.. I'll try to generate .pdbs |
Use QtJambi debug dll's. Therefore, start your program with |
I am already running with -Dio.qt.debug=debug. It didn't add any new information. Vs says "dll was built without symbols information" |
I am not familiar with VS. Do you have Qt Creator? |
I've managed to make qt debug flag work, for that you also need to build -debug verion of all jars, forked to a new issue #67 |
The pre-configured setting |
Could you send me any example code leading to this bug? |
@omix I still can't provide you with our internal IB code, however I have found that even when I use qtjambi 6.2.5 built locally in release mode, it almost never crashes. After that I checked and found that latest 6.2.5 jars from Maven are dated by July 5th, whilethis git repo has a lot of bugfixes after that date: Perhaps one of them also fixed the issue we are seeing now. Could you please repost 6.2.5 jars to Maven? |
I don't think these small bugfixes deal with your issue. However, I inserted a blindfix. I removed the Java convertion for the threads in raiseQThreadAffinityException. |
Do you have an idea what kind of object is used from the wrong thread? Is it QWidget instance? |
@omix I think it's some qobject from non ui thread passed to QML js function. Unfortunately, it never repoduced for me on debug/release build I made for 6.2.5, only when using jars from maven |
Just to understand, you create a qobject in a thread pass it to QML where you perform actions on the object? |
That's a guess, I don't know for sure. Will you upload new 6.2.X qtjambi build? |
Yes, but that takes a while. I am performing last tests. Then I'll continue with release steps. Should be ready until weekend. Hopefully. |
@omix this code immediatley crashes when you call dispose() on a running thread. Is this the same behavior as in qt?
|
Oh, this program even crashes in C++. |
hey @omix I see that you've uploaded new 5.15 build, will you also push 6.2 today/on the weekend? |
Yes, it takes a day to upload. I'm just finishing the last artifacts. Then, give the maven database a couple of hours. |
Unfortunately, maven repository blocks me. I can no longer log in and wait for support now. Thus, I am not able to finish release before next week. |
I know. At one position between the 6.2 artifacts the Nexus Repository blocked my account. I'm waiting for support. No response up to now. |
I am in contact with Nexus Respository support. My release request crashed the system. I asked the server to release over 1000 artifacts in short time. That was the reason why they blocked me. |
I have released the missing components. Should be available in Maven in couple of minutes. |
@omix 6.2.6 for quick-native is still not there: https://search.maven.org/artifact/io.qtjambi/qtjambi-quick-native-windows-x64 |
I'll fork a new issue since this one is closed.. |
Describe the bug
When trying to warn about thread affinity, QTJambi sometimes cores the JVM
To Reproduce
In our not very complicated code, it reporoduces often at random moments
Expected behavior
It should correctly return java exception even if one of thread objects is corrupted
Screenshots
Stacktrace of the exception, it happens at different moments, but stacktrace is always the same:
Faulty code:
System (please complete the following information):
**Additional information
I assume this happens because our code is actively using threads so some of them are destroyed before raiseQThreadAffinityException is called
The text was updated successfully, but these errors were encountered: