Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct
[Solved] Access violation when creating a Qt Quick component
jrlaff last edited by
I have a strange access violation when using Qt Quick on a windows 7 machine.
First, I am using Qt version 5.3.1. When calling QQmlComponent::create() to create a component from a local Qml file, the application crashes.
Two strange observations:
- The crash is not systematic. It crashes +- 4 times out of 5.
- The same program runs fine on another machine (my development workstation, 64-bit, with native OpenGL drivers I guess) and crashes on target machines (32-bit, with ANGLE Open GL ES emulation libraries).
I have tried several things already, and went to the conclusion that the crash depends on the Qml file content. If I simplify it (so that only a simple rectangle is displayed), it runs fine. Starting from that point, I tried to isolate the component that causes the crash. However, it seems that either it depends on the complexity of the Qml code, or several components are in cause, as every time I find one that produces a crash, un-commenting the other ones brings another crash.
My questions are:
- Could it be due to the fact that the target machines use the ANGLE emulation libraries?
- Is there any known bug in Qt that would produce a crash on QQmlComponent creation? I have tried to create the component from a Loader in the Qml code, with the same crash result.
- Is there any Qt log that I could enable (other than the custom message handler) to help diagnose the problem?
jrlaff last edited by
I figured it out.
It turns out that I used some version of the following DLL files:
These files were copied from this location: D:\Qt\Qt5.3.1\5.3\msvc2013\bin. However, the same files also exist in D:\Qt\Qt5.3.1\Tools\QtCreator\bin. While they are tagged with the same version, some have the same size, but different content.
Using the files from the first location produces the crash (on the target PC only, not on my workstation), while copying them from the second location runs fine everywhere.
I am quite unlucky with these DLLs, as previously I already had text rendering issues with libEGL.dll and libGLESv2.dll.
I wonder why two "versions" of these files exist.