I've recently installed Ubuntu 22.04 LTS on my development laptop. Previously I was running 18.04 so this is my first experience of Wayland. I did a clean installation on a new disc. I had relatively few problems reinstalling gitkraken and cloning the repository of my source code from github but when I came to install the Qt libraries this is where my problems started. The on-line installer from the Qt website simply wouldn't run. It just exited silently. I eventually found an old version of the on-line installer executable in a backup of my downloads folder from Ubuntu 18.04 and was able to use this to download and install the same version of the Qt libraries that I was using previously (5.15.0). This is also the same version that I use on my other development machine which runs Windows 10. Keeping the two in step is useful and upgrading too many things at the same time seemed like asking for trouble. I installed the latest versions of Qt Creator (7.0.1) and g++ (11.2.0).
I was then able to build my application and, after a brief search of stack overflow I added "-platform wayland" to the command line arguments setting in Qt Creator but the application crashed almost immediately on start-up with the error "The Wayland connection experienced a fatal error: Protocol error".
Several things made me think this might be a bug in the Qt libraries rather than my application (none of them definitive!):
At the point of application exit, apart from main() there is none of my application code in the call-stack (see below)
My application has been stable for a long time and has survived several operating system, compiler and Qt version changes across two OS families
The fact that the latest Qt on-line installer (itself almost certainly a Qt application) wouldn't run
I downloaded Qt 5.15.12 (the latest Qt 5 version available) and rebuilt my application against that but the result was the same.
The next step is obviously to strip my application right down to something minimal that still shows the problem but before I do I was wondering whether this is something other people have come across when migrating a Qt5 application to Wayland and whether I need to take the bigger step of upgrading to Qt6? The Qt Wiki describes Qt 5.11 as being "stable" with Wayland.
The call stack at the time of the error looks like this:
qt_message_fatal
QMessageLogger::fatal
QtWaylandClient::QWaylandDisplay::checkError
QtWaylandClient::QWaylandDisplay::flushRequests
doActive
QMetaObject::activate
QSocketNotifier::activated
QSocketNotifier::event
QApplicationPrivate::notify_helper
QApplication::notify
QCoreApplication::notifyInternal2
QCoreApplication::sendEvent
socketNotifierSourceDispatch
g_main_context_dispatch
??
g_main_context_iteration
QEventDispatcherGlib::processEvents
QEventLoop::exec
QCoreApplication::exec
main
Many thanks.
It's something to do with QDialog::setMaximumSize. The call to setMaximumSize itself does not crash but if I remove all calls to it the application works fine. Some controls do subjectively seem bigger on Wayland so I wonder if Qt 5 on Wayland crashes if the size of the QDialog contents exceeds the maximum size specified. This certainly doesn't cause a crash in Qt 5 on Windows and didn't in Qt 5 on Ubuntu prior to the switch to Wayland. I think this is a Qt bug but of course it may well be fixed in a later version of Qt and there's an easy enough work-around now I know the cause.
I was using setMaximumSize to allow the dialog to expand dynamically as widgets were added but to prevent the user from making the window any bigger than it needed to be. layout()->setSizeConstraint(QLayout::SetFixedSize); achieves the same thing.
I am new to UWP. I have just ported a quite complicated WPF app. It took me several weeks to figure out every difference and refactored a lot of code. However when I start to build and run in release mode I get an Access violation exception.
How is this even possible? Aren't debug and release execution supposed to be the same? How can I debug this problem if it occurs only in release?
If I turn native compilation off, the release build runs without a problem. However, when I try to install it on the device, a NetCore 2.2 debug framework is required. What is this debug framework and why cannot I run my release code without it?
I used to develop for AspNetCore and those things can run even on Linux. I really do not understand how is a UWP app cannot run on a Windows 10 tablet without a special debug framework.
I am kind of lost here. Any help or guidance is much appreciated. Thanks
EDIT:
As for the conclusion: I needed to create the app again from scratch. I started copying everything from the old app class by class. It was worth the effort not just because I refactored a lot of code :) but finally found what was causing the crash. I had a dependency in one of my libraries to an older version of System.ServiceModel.Primitives NuGet package. In Debug build, even with Native Compilation, the runtime managed to resolve the package. However, in Release it could not.
It was quite a journey that made me to develop a better software. However I could avoid it by releasing more often from the beginning, or the if the runtime would show more informative error messages about assembly resolution problems.
The .NET Native compilation tends to cause problems for apps and it is recommended to try and run the application frequently in the release mode to catch potential issues as soon as possible. Usually any reflection-related code should be checked well, as those usually are the source of problems.
I would suggest going back in time (if you have some kind of source control) and try earlier builds of your app to pinpoint the time when the app stopped working. Alternatively, you can try commenting out parts of the code until the release build starts working. Finally, it is also possible to create a blank project and sequentially copy code and run it to locate the problem.
.NET Native is an annoying aspect of UWP app development and Microsoft is aware of this - the plan is .NET Native will no longer be required anymore soon (most likely before .NET 5 comes) and later there will be a more predictable replacement.
About a month ago, I used PyInstaller and Inno Setup to produce an installer for my Python 3 script. My AVG Business Edition AntiVirus just started complaining with today's update that the program has an SCGeneric Trojan Horse in the main .exe file used to start the program (in the folder created by PyInstaller that has all of the Python "guts"). At first I just thought it was a false positive in AVG, but submitting the .exe file to VirusTotal I get this analysis:
https://virustotal.com/en/file/9b0c24a5a90d8e3a12d2e07e3f5e5224869c01732b2c79fd88a8986b8cf30406/analysis/1493881088/
Which shows that 11 out of 61 scanners detect a problem:
TheHacker Trojan/Agent.am
NANO-Antivirus Trojan.Win32.Agent.elyxeb
DrWeb Trojan.Starter.7246
Yandex Trojan.Crypren!52N9f3NgRrY
Jiangmin Trojan.Agent.asnd
SentinelOne (Static ML) static engine - malicious
AVG SCGeneric.KTO
Rising Malware.Generic.5!tfe (thunder:5:ujHAaqkyw6C)
CrowdStrike Falcon (ML) malicious_confidence_93% (D)
Endgame malicious (high confidence) 20170503
Zillya Dropper.Sysn.Win32.5954
Now I can't say that these other scanners are ones that I have heard of before... but still I'm concerned that it is not just AVG giving a false positive.
I have submitted the .exe file in question to AVG for their analysis. Hopefully they will back off on whatever it is that they thought they were trying to detect.
Is there anything else I can do with PyInstaller to make it so that the .exe launcher that it created won't be considered a Trojan?
I was always getting some false positives with PyInstaller from VirusTotal. This is how I fixed it:
PyInstaller comes with pre-compiled bootloader binaries for different OSs. I suggest compile them by yourself on your machine. Make sure everything is consistent on your machine. For Windows 64-bit, install Python 64-bit. Download PyInstaller 64-bit for Windows. Make sure Visual Studio (VS) corresponding to your Python is installed, check below:
https://wiki.python.org/moin/WindowsCompilers
Compile the bootloader of PyInstaller on your machine with VS. It automatically updates the run.exe, runw.exe, run_d.exe, runw_d.exe in DownloadedPyinstallerFolder\PyInstaller\bootloader\Windows-64bit. Check below for more info on how to compile the bootloader:
https://pyinstaller.readthedocs.io/en/stable/bootloader-building.html
At the end, install PyInstaller. Within the PyInstaller directory, run
python setup.py install
I was able to submit the file in question to AVG's "Report a false detection" page, at https://secure.avg.com/submit-sample. I received a response back fairly quickly (I can't remember exactly how long, but it was less than a day) that they had analyzed my file and determined that it did not have a virus. They said that they had adjusted their virus definitions so that it would not trigger a false positive anymore. I updated my definitions and it was still triggering, so I contacted them again with my virus definition version, and I heard back that the version I had wasn't high enough - I think there was some delay on my definitions because I get them from a local server. But within a day I had the right version of the definitions and the false positive didn't trigger anymore.
So if you have a false positive with AVG, I would recommend this solution - fairly quick and easy to get a resolution to the problem.
I puzzled over this question for two days and finally found a problem with my application. The issue was with the application's icon.
Example for tkinter:
root.iconbitmap('./icon.ico')
When I removed this line of code, the false-positive Trojan was gone.
Also, make sure not to use --icon dependency when you are converting your .py file into .exe. Otherwise, this will cause the same false-positive Trojan detection.
I faced same issue for my small document register project code.
My temporary solution was to allow the app in windows defender and
other solution was to use the command pyinstaller filename.py instead of pyinstaller --onefile filename.py.
I dont know if it is correct. But it worked for me.
I searched many blogs for weeks. But I found nothing..
Today I found a way to convert py to exe without any virus errors.
Virus Total Report
So in this method you do not need to send any reports.. Actually It is very simple.
You need to install a module named Nuitka.
python -m pip install nuitka
Then you need to open command from from the file path. And use the command;
python -m nuitka --mingw64 filename.py
And that's all.
You can use the command
nuitka --help
You can find more at - Nuitka Guide
I had this same problem using python 3.8.5 and pyinstaller 4.5.1
In my case the first exe build was accepted by the antivirus (Windows Defender) but subsequent builds were flagged as having a trojan.
I solved it by using the pyinstaller --clean option every time I built the executable
Reverting back to PyInstaller 3.1.1 from 3.4 resolved similar issues on my end (at least temporarily).
As #boogie_bullfrog told, reverting to a previous version could be a solution. However I used *.spec file to store some data (like pictures and icons). I had the latest 3.5 version (August, 2019) and moving to 3.1.1 caused error when app was compiled (probably due to supporting Python 3.7).
So right now the easiest solution is to downgrade to 3.4
It supports specs from pyinstaller 3.5 and the onefile-app wasn't detected by Windows 10 built-in firewall
What I did was to solve this(make exe files non detectable as virus) was to downgrade pyinstaller by typing in cmd: pip install pyinstaller==4.1.0
And by the way it didn't work on 3.4.0 so I just randomly picked that version(4.1) and its pretty good looking so far :>
I'm pretty sure that it works on more than only that one version but that i experienced personally
Recompile and then reinstall your Pyinstaller bootloader manually.
This was a problem I had for a while, and my friend and I figured out this resolution with the help of many others. It almost always works to resolve the issue.
I posted the specific steps on my medium blog. Shared the link below, but the basic steps are as follows
Purge Pyinstaller Files within your Project and Rebuild
Uninstall Pyinstaller
Build a Pyinstaller Bootloader with your Compiler
Install the newly compiled Pyinstaller
Re-build your EXE with Pyinstaller, and make sure it’s not being be flagged as a virus
How to Resolve the Python Pyinstaller False Positive Trojan Virus
Part 1. Manually Compile your Pyinstaller Bootloader
Part 2. Working with Anti-Virus Developer(s)
I had a similar problem with a pyinstaller exe under Windows. Avira put that file into quarantine since it was considered potentially dangerous (due to heuristics, which means that some segments look typical for a virus, but no virus is actually found).
Keep in mind that the exe files you generate yourself are unique (as a consequence, the Avast scanner usually returns a message "you have found a rare file, we are doing a quick test", and delays execution for 15 seconds to perform a more thorough test).
My solution consists of some steps:
I have uploaded the exe to https://www.virustotal.com/gui/home/upload to check it with many scanners. If just one or two are detecting a virus, you should be on the safe side.
In order to make your local virus scanner accept the file, you can manually accept it for your computer, but this does not solve the underlying problem, so on other computers it would still be flagged as a virus.
Therefore I reported the file as false positive to Avira, which can simply be done by sending it by email. Other scanners have similar feedback lines. I got a feedback by email within one day that it is ok, and the scanner on my pc agrees with this now. Hope that this helps with the next iterations of my exe so that it stays clean.
Had the same problem today. Win8.1 would keep flagging .exe as virus. Updated to pyinstaller 5.7.0 but the issue persisted. Uninstalled pyinstaller 5.7.0 and did a fresh install. Strangely, Win8.1 isn't complaining anymore!
I'm using the Qt for developing the c/c++ application,while i try to debug the app with static library it is very slow and takes much time step over (r) in..
can any one suggest me to make the debugger fast as like vs2008..
regards
VS
It is likely you are having this behaviour because the debugger retrieves required debug info for system libraries from the internet each time - or it doesn't find the requested info at all. If so, it will display something like that in the Debugging Window.
Follow these steps to set up a symbol cache which will allow caching debug symbols:
http://doc.qt.io/qtcreator/creator-debugger-engines.html#setting-cdb-paths-on-windows
This might still make it slow for the next time you debug, but it should get quite fast from the second time on.
If you do not have internet access though, you will need to manually download these symbols from here:
http://msdn.microsoft.com/en-us/windows/hardware/gg463028.aspx
and place them in the symbol cache folder you specified.
it has nothing to do with windows and debug symbols server
this is happening when libqt has debug symbols and it happens even (directly) in gdb/cgdb!
it has to do with dwarf (still looking into this one)
regressed on windows (8), ubuntu (13.04), fedora (19-rc) & mac (10.8.5 & 10.9) -> obviously has little to do with os or library
I have an annoying and unfortunately urgent problem. I started out by trying to subclass the QGLWidget for my Windows application in Visual Studio 2008 x86. It crashed immediately upon running, as far as I could tell, when the QGLWidget was instantiated. Finally I ended up trying all the included Qt examples for Open GL, and they all behave the same - crashing as follows:
Error message pops up:
"Windows has triggered a breakpoint in
2dpainting.exe..."
The execution halts in qgl_win.cpp (breakpoint indicated):
QGLTemporaryContext::~QGLTemporaryContext()
{
wglMakeCurrent(d->dmy_pdc, 0);
wglDeleteContext(d->dmy_rc);
ReleaseDC(d->dmy_id, d->dmy_pdc);
DestroyWindow(d->dmy_id);
--> if (d->old_dc && d->old_context)
wglMakeCurrent(d->old_dc, d->old_context);
}
Output:
... HEAP[2dpainting.exe]: HEAP: Free
Heap block a40c108 modified at a40c288
after it was freed Windows has
triggered a breakpoint in
2dpainting.exe.
This may be due to a corruption of the
heap, which indicates a bug in
2dpainting.exe or any of the DLLs it
has loaded ...
Also happens when I switch from debug to release. However, I can run most of these Open GL example compiled executables just fine.
I can't find anything through internet searches. Gurus, please help!
Thanks,
Matt
I resolved the problem by updating my graphics drivers to their latest version. Strange, because I'm using the Intel GMA 965 Express chipset, which is already very old.
Now all the Qt examples compile just fine. No heap corruption.
I'm also able to run the main Qt Examples and Demos app from the start menu, which I was never able to do before - it would just crash.