crash when attempting drag on macOS with Qt6
-
I'm not sure if this should go here or in the Qt6 category, but here goes...
I have a rather strange problem where Qt6 crashes when (a.o.) a drag is initiated on macOS. Although this is systematically reproducible in debug in the full application I'm working on, the problem doesn't occur in a release version, nor in a minimal application built in the same source tree with the same Qt binaries. The minimal application obviously links with less other (static and shared) libraries than the full application).
I was able to track the origin of the crash: when Qt initiates a drag, it creates an image for the OS to show. In Qt6 this is done by the extension of NSImage with a category QtExtras that contains a.o. method imageFromQImage. In my case, the method imageFromQImage is not present in NSImage at the critical moment as shown by
[ NSImage respondsToSelector: @selector(imageFromQImage)]which returns NO, resulting in a nil return value.
As I'm unfamiliar with the category loading mechanism, I was hoping someone would be able to shed some light as how I may find what's causing this strange behaviour.
As the category is declared in a private header of Qt, I can't just include that to try and remedy it. -
Hi,
Beside build Qt yourself it's going to be hard to debug.
Is your application something closed ?
-
Hi,
Beside build Qt yourself it's going to be hard to debug.
Is your application something closed ?
@SGaist If your question is "is this commercial software" then the answer is yes.
I did some more experimenting and I think I may have found a possible cause. One of the libraries we use is a binary from another company. They also use Qt, but for obvious reasons they link statically with it. I have the impression that the extension provided by the Qt they use is somehow interfering with the one "our" Qt creates. -
Are they using Qt 5 ?
-
That's something you should check. Mixing two different major versions of Qt is unlikely to work well and in your case they might be from different architectures.
-
That's something you should check. Mixing two different major versions of Qt is unlikely to work well and in your case they might be from different architectures.
@SGaist As the Qt in that library is linked statically and its symbols aren't exported that shouldn't be a problem. That library links Qt statically precisely to avoid having to keep Qt versions in sync between the two companies.
This hasn't posed problems in the past BTW.
Not sure what you mean with different architectures. That library is now a universal library.
-
But weren't you using the same major version of Qt even if not in sync ?
