Bugs using Qt 6.1.3 in Visual studio2019 - qt

Simply create a new MainWindow project in VisualStudio2019, there are two errors showing in error output window:
C++ defaulted default constructor cannot be constexpr because the corresponding implicitly declared default constructor would not be constexpr
C++ expression must have a constant value
Some setting are shown below:
QT version: 6.1.3_msvc2019_64
Windows SDK version:10.0.20348.0
Plantform tool set:Visual Studio 2019 (v142)
C++ version:ISO C++17 Standard (/std:c++17)
Well the project is good to build and run, while showing above errors.
Someone has any idea to solve the problem?

Related

The "VsInstallRoot" parameter is not supported by the "XamarinBuildAndroidAarRestore" task

I've got a Xamarin.Forms app and when I try to build the Android app I get the following compile time error:
Target _XamarinAndroidBuildAarRestore:
/packages/Xamarin.Build.Download.0.4.9/build/Xamarin.Build.Download.targets(120,4):
error MSB4064: The "VsInstallRoot" parameter is not supported by the "XamarinBuildAndroidAarRestore" task. Verify the parameter exists on the task, and it is a settable public instance property.
/packages/Xamarin.Build.Download.0.4.9/build/Xamarin.Build.Download.targets(114,3):
error MSB4063: The "XamarinBuildAndroidAarRestore" task could not be initialized with its input parameters.
The iOS app builds fine.
I'm using Visual Studio for Mac (version 7.4.1 build 48).
I was able to get this error to go away by deleting the packages, bin, and obj folders from my solution as referenced in this Xamarin Forum:
https://forums.xamarin.com/discussion/96703/the-user7zippath-parameter-is-not-supported

Qt 5.2.1 QFileDialog GDB strange behaviour

I'm using Qt 5.2.1 MinGW 32bit on a Windows 7 machine with gdb from the MinGW 4.8.
There is a strange behaviour when i try to singlestep through the code.
QFileDialog open;
open.setDefaultSuffix("tst");
QString fileName=open.getSaveFileName(this,tr("New File"),"",tr("Test File (*.tst)"));
if(fileName!="")
{
...
Im setting a breakpoint at the 1st Line.
Singlestepping works until the 3rd Line, than, after choosing a file, gdb says:
Cannot insert breakpoint -1217.
Error accessing memory address 0x7219cd30: Input/output error.
When i set a Breakpoint insede the if or after, the Debugger stops at the Breakpoint, but when i try to singlestep after the stop, the same error occurs.
When i set the FileName directly like:
QFileDialog open;
open.setDefaultSuffix("tst");
QString fileName="D:\path\to\File.tst";
if(fileName!="")
{
...
Singlestepping works without any problems.
The Code above runs without any problem, the problem only occurs when i try to singlestep.
Does anyone knows the problem, or a suitable workaround?
QFileDialog::getSaveFileName() is a static function, but you call it like a member method.
I'm only guessing, but probably the way you are calling a static member via an object confuses your debugging environment - the compiler should generate valid code though, so running over your code will work.
BTW, setDefaultSuffix will not work as expected, as getSaveFileName is a static member and will not look at your QFileDialog object.

Qt 5.3.0: process crashes complaining about free() in QQmlImageProviderBase when closing QQuickView

I am working on a project recently migrated to Qt 5.3.0 (previously it was running on Qt 5.2.1).
My project is based on a QQuickView object being filled with some QML files, depending on some command I receive from a communication protocol...
Since I was on Qt 5.2.1 the system worked fine and was rock solid: never a problem. Now with Qt 5.3.0 if I close the QQuickView window the process crashes with the following output:
** glibc detected ** /home/morix/devel/aesys/VLED/build/bin/VLED: free(): invalid pointer: 0x091ec694 **
======= Backtrace: =========
/lib/i386-linux-gnu/libc.so.6(+0x75ee2)[0xb5c1fee2]
/usr/lib/i386-linux-gnu/libstdc++.so.6(_ZdlPv+0x1f)[0xb5e1b51f]
/opt/Qt/5.3/gcc/lib/libQt5Qml.so.5(_ZN21QQmlImageProviderBaseD0Ev+0x24)[0xb7136110]
/opt/Qt/5.3/gcc/lib/libQt5Qml.so.5(+0x211f59)[0xb713cf59]
/opt/Qt/5.3/gcc/lib/libQt5Qml.so.5(+0x2138b3)[0xb713e8b3]
/opt/Qt/5.3/gcc/lib/libQt5Core.so.5(_ZN9QHashData11free_helperEPFvPNS_4NodeEE+0x4a)[0xb5f40e7a]
/opt/Qt/5.3/gcc/lib/libQt5Qml.so.5(_ZN17QQmlEnginePrivateD1Ev+0x8ab)[0xb71378c5]
/opt/Qt/5.3/gcc/lib/libQt5Qml.so.5(_ZN17QQmlEnginePrivateD0Ev+0x1c)[0xb7137a7c]
/opt/Qt/5.3/gcc/lib/libQt5Core.so.5(_ZN7QObjectD1Ev+0x6a1)[0xb6173031]
/opt/Qt/5.3/gcc/lib/libQt5Qml.so.5(_ZN9QJSEngineD1Ev+0x36)[0xb70352b6]
/opt/Qt/5.3/gcc/lib/libQt5Qml.so.5(_ZN10QQmlEngineD1Ev+0xf0)[0xb71398fe]
/opt/Qt/5.3/gcc/lib/libQt5Qml.so.5(_ZN10QQmlEngineD0Ev+0x1c)[0xb71399e2]
/opt/Qt/5.3/gcc/lib/libQt5Core.so.5(_ZN14QObjectPrivate14deleteChildrenEv+0x6c)[0xb616e4ac]
/opt/Qt/5.3/gcc/lib/libQt5Core.so.5(_ZN7QObjectD1Ev+0x661)[0xb6172ff1]
/opt/Qt/5.3/gcc/lib/libQt5Gui.so.5(_ZN7QWindowD2Ev+0x6d)[0xb646a7bd]
/opt/Qt/5.3/gcc/lib/libQt5Quick.so.5(_ZN12QQuickWindowD1Ev+0xd9)[0xb74878e9]
/opt/Qt/5.3/gcc/lib/libQt5Quick.so.5(_ZN10QQuickViewD1Ev+0x9a)[0xb753925a]
/home/morix/devel/aesys/VLED/build/bin/VLED[0x8059bbe]
/home/morix/devel/aesys/VLED/build/bin/VLED[0x8059c8f]
/home/morix/devel/aesys/VLED/build/bin/VLED[0x8051368]
/home/morix/devel/aesys/VLED/build/bin/VLED[0x804d429]
/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0xb5bc34d3]
/home/morix/devel/aesys/VLED/build/bin/VLED[0x804d2b1]
(VLED is the name of my project in the output here above).
It seems that some free() call in QQmlImageProviderBase is working on a unvalid pointer...
Please consider that in my project I make use of a QQmlImageProviderBase-derived class to provide some "live" pixmaps to QML... but I don't think the problem is there: the code is very simple (simply returns some pixmaps previously inserted in a local collection) and furthermore with Qt 5.2.1 it works fine...
I am working on Ubuntu Linux 12.04 LTS... but the problem is the same if I cross-compile the application for BeagleBone Black / TI AM335x... so it seems not to be an "environment-related" problem but rather a Qt problem...
Does somebody else is experiencing such a problem with Qt 5.3.0? Any workaround?
UPDATE
I created a very simply project for reproducing the issue: it can be found here here.
Please try it on your own and let me know if you have the same issue and if you find a valid workaround…
Ok, I posted the question on Qt bug tracker and here is the answer: the QQmlImageProviderBase-derived object must be allocated on the heap because the QQmlEngine takes the ownership of it when it is added to the view... If it is allocated on the stack the object is going to be deleted twice (once by QQmlEngine and once when the stack is popped)...
Allocating it on the heap (as suggested) and letting QQmlEngine to delete it on its own fixes the problem.

Qt Application throws an Access violation exception during startup

I have a Qt Application that works in Debug mode without any problems. Since two days I'm trying to make it work in Release mode. After some Project property modification I managed to compile without errors. But unfortunalty the application crashes before even reaching the main method.
That's my environment:
MS VS 2010
Qt 4.8.4
Qwt 6.0.0
I don't know if this is relevant, but I also installed the Qt plugin for VS and used Qt Designer to create my GUI.
As I said in Debug mode there is no problem. Starting the release version from the Visual Studio produces the following error:
Unhandled exception at 0x77c415de in Application.exe: 0xC0000005: Access violation reading location 0x0000000c.
The last function I can "debug" is the the "WinMain" method called inside the method "__declspec(noinline) int __tmainCRTStartup", which is located in crtexe.c (honestly I have no idea what this is). The call stack looks like this:
ntdll.dll!77c415de()
[Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]
ntdll.dll!77c415de()
ntdll.dll!77c3014e()
msvcr100.dll!718f0269()
msvcr100.dll!718f233b()
msvcr100.dll!718f233b()
msvcr100.dll!718f233b()
QtCore4.dll!5b2cfc49()
QtGui4.dll!57bf54ea()
Application.exe!__tmainCRTStartup() Line 547 + 0x1c bytes C
kernel32.dll!754633aa()
ntdll.dll!77c59ef2()
ntdll.dll!77c59ec5()
In the moment I'm totaly lost with this problem. No idea what to try further...
I've tried to reduce the program and commented out the complete main function. But the result was the same behaviour. As I said the error occurs even before the main function is called. I also turned off all optimization and recompiled... didn't changed anything.
What completly puzzles me, is the fact that it "works" when I call "Application.exe" from the command prompt (ok it also crashes but much later during execution). Weird, isn't it? What is the difference between starting from command prompt and starting from Visual Studio application?
AnatolyS and npiau thanks for you tips. Meanwhile I continued digging in my code. More or less I started from the very beginning and finally got the place the error occurs. I suppose npiau is right, it has nothing to do with Qt.
It's still (for me) a strange problem. I posted it in a new thread (because it has little to do with this thread): C++ Creation of a Singleton object in initializer list causes an Access Violation (only Release Mode)
The problem is not in QT but in your source code. "0xC0000005: Access violation reading location 0x0000000c" means that you try to access a wrong memory location.
Check out your arrays, ans pointers.

Qt and Linking to an external DLL

I've developed a program and I am trying to make this program work with a controllable light source manufactured by some other company. I've emailed the company and they have agreed to send me their external library as a DLL.
I have developed all of my software using Qt 4.8.1 and it has been compiled using MSVC2008.
The controllable light's DLL was compiled in Visual Studio 2008 and was written in either C++ or C# (the manufacturer is uncertain). All I have been given is the DLL and a text file saying that I must:
Add the DLL as a reference to my project
Add using LightName; to the top of the class
Instantiate an instance of the object like so: LightName *ln = new LightName();
Call function void turnOn() with the newly created LightName instance.
Firstly, I find it odd that an external library requires me to instantiate an instance of their object especially when its for a simple piece of hardware.
Secondly, the other company has provided me with no interface files.
My question is:
How can I possibly link to a C++ DLL and expose the functions nested in this library without having an interface header file in a Qt environment? Is there someway to make an interface for an external library?
I have already attempted using QLibrary and doing the following:
QLibrary myLib("mylib");
typedef void (*MyPrototype)();
MyPrototype myFunction = (MyPrototype) myLib.resolve("mysymbol");
if (myFunction)
myFunction();
However, this doesn't work because the DLL I was given was not a C DLL and I have no interface so Qt doesn't have a clue about what symbols it needs to resolve.
I've attempted to display all the definitions exported from my DLL using the dumpbin /EXPORTS command. Unfortunately this was unable to produce anything. I was hoping that I would get some sort of mangled C++ from this that I could then unscramble to make my own header.
I've attempted to use the dependency walker(very useful tool) however it couldn't resolve any symbols to give me some function definitions.
QLibrary only helps you if the library has functions exported as C symbols. If that is C++ you can dump the symbol table and look if that is sufficient for you. Names must be demangled: try to look for dumpbin or similar. It is however possible that you can't do this, it depends on how the symbols have been defined. In that case you'll have to ask for the header: read this.
Well it's absolutely legal to ask you for "instantiating an instance of their object". It's been simply their design decision to make the dll interface object oriented (as contrary to plain extern "C"). QtCore.dll is just someone else's DLL too, and you are instantiating their objects all the time.
But it also means that you will have harder time to call the DLL. The symbols are not "C" symbols (you can't export class that way) so QLibrary can't do anything for you. You can try dumpbin /EXPORTS from the DLL and then tediously unmangle them to reconstruct the class declaration. Luckily there are tools to help you (even online)
But not providing a header file for such DLL is completely dumb in the first place.

Resources