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.
Related
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.
Hello Guys i used just this simple example to play music with this code:
QMediaPlayer *mediaPlayer { new QMediaPlayer };
mediaPlayer->setMedia(QUrl(currentMediaFileName));
mediaPlayer->setVolume(50);
mediaPlayer->play();
he show me in debug mode the message "Segmentation fault" and my application crash.
I used Qt 5.15.0
This seems to be a bug in Qt. I found this bug report. Hopefully this issue will be resolved soon.
Based on my experience, the problem seems to occur only on certain hardware: I have two laptop computers, both with XUbuntu 21.04 and both using proprietary drivers, and when running the same code i get SIGSEGV on one system but on the other (older) system there is no problem.
Whenever I try to compile a QT Creator project with QT Quick, even the basic, automatically generated project, rcc.exe returns an error with code "Error -1073741819", according to the Creator.
This error number looks suspicious, Googling reports it's something related to File System and either too strict UAC settings (I have it disabled) or custom sound scheme (using default).
I tried to manually use rcc.exe, just to check what's happening and to my surprise, "rcc.exe stopped working..." popup appeared. I am really stumped by this.
I tried reinstalling Qt and the exact same thing is happening with the newest version, so I believe it's an OS problem.
I should add I am using Windows 10 and everything worked perfectly on this installation about 4 months ago.
EDIT: After using GDB on rcc.exe, I've got this:
(gdb) run
Starting program: D:\Qt\5.5\mingw492_32\bin\rcc.exe
[New Thread 4540.0x2da0]
[New Thread 4540.0x28c0]
[New Thread 4540.0x2c80]
[New Thread 4540.0x2350]
Program received signal SIGSEGV, Segmentation fault.
0x0040cc77 in ?? ()
The answer was the Windows build.
I was using build 14251, which has some problems with memory management.
After updating to 14257, everything started working flawlessly.
The C++ program I am writing under Linux (OpenSuse) had a bug in it where it consumed all available RAM including page memory. This affected badly the system and all programs it was running. More importantly eclipse (amongst other programs) was unable to close properly and I eventually had to power off the machine.
After powering the machine back up again and restarting eclipse all seemed well except when compiling under eclipse it now compiles both the debug and release versions whenever I press Control-B, my usual short cut.
So the question is how do I recover from this situation whereby I had a debug and release version of the program and Control-B would compile either the debug or release version but not both. I see this as an inconvenience but as the program gets larger the compile times are getting longer (twice as long as necessary) and I can only drink so much tea whilst I wait.
To answer my own question.
The Control-B short cut does a 'Build All' and so the answer is 'As Designed'.
But this begs two other questions.
Firstly I am sure that previously the Control-B short cut only compiled the Debug version. So I have no idea how I got eclipse to do that. That was something I did a long time ago.
Secondly how do I get just a Debug or a Release build but not both. I cannot discover an option for this. On my setup the 'Build Project' option still invokes both Debug and Release builds.
I've recently had a horrible problem with QTCreator. After the first time of running the program, ALL debugging instances segfault upon constructing the MainWindow object. Even if i make a blank QTwidget project and run in debug (without editing a single bloody thing), i get a segfault.
This persists after dozens of reinstalls. I have tried both the SDK as well as the IDE and library seperately. The version of the library is irrelevant, i always get the seg fault and its only on my tower. My laptops work just fine.
Does anyone have any possible solutions? Any help will be appreciated.
I needed to run QtCreator in admin mode in order for GDB to function properly.
Without knowing more (please answer to cbamber85's comment), such issues are known to be caused by uberprotectious anti-virus solutions or other software that hooks into places where GDB would usually hook in (Vendor OS-'enhancement' tools are infamous for doing that). This is a known Problem with GDB.
You could try to disable your virus scanner or remove/unload/remove from autostart the vendor tools and try again.
If that doesn't work, the content of the debugger output log pane (Windows > Views > Debugger Log) would be interesting.