I am using ffmpeg and Qt to build a small demo app.
FFmpeg is built with /MT (crossbuild or built with visual 2010)
Qt is always built with /MD
My little example is always built with /MD
When the application
int main(int argc, char *argv[])
{
QApplication a(argc, argv);
av_gcd (75, 25);
return a.exec();
}
//note : following is av_gcd source in ffmpeg libs:
int64_t av_gcd(int64_t a, int64_t b)
{
if (b)
return av_gcd(b, a % b);
else
return a;
}
is executed in release mode it crashes because it doesn't see av_gcd as executable memory. The error is:
First-chance exception at 0x0000000300905a4d in mylittleexample.exe:
0xC0000005: Access violation at location 0x0000000300905a4d.
=======================================
VERIFIER STOP 0000000000000650: pid 0x1B9C: Attempt to execute code in
non-executable memory (first chance).
0000000300905A4D : Address being accessed. 0000000300905A4D : Code
performing invalid access. 00000000009FF770 : Exception record. Use
.exr to display it. 00000000009FF280 : Context record. Use .cxr to
display it.
=======================================
The address 0x0000000300905a4d doesnt change regardless of the function in the library (ffmpeg in this case), or the compiler used for the executable (vs2010, vs2012) or a different machine.
If I use the FFmpeg built with /MD and it works as one would expect.
I observe that the executable doesnt load the library when the
library is compiled with /MT. Why is that?
Furthermore, If the library is compiled with /MT and debug
information is enabled when the application is linked (/DEBUG
param to the linker) then the library is loaded and everything
execute correctly. Why?
Related
I needed to include OpenCV into my program, so after long time, I gave up to set it up on mingw (which was fully functional for my program) and installed MSVC17 compiler and debugger. But when I run my application with MSVC, program crash with 0x0000005 code, access violation on 0xfffffff.
It always crash on app.exec() in main.cpp
int main(int argc, char *argv[])
{
QCoreApplication::setAttribute(Qt::AA_EnableHighDpiScaling);
QGuiApplication app(argc, argv);
MyClass myClass;
myClass.getView()->setMinimumWidth(900);
myClass.getView()->setMinimumHeight(600);
QQuickWindow *quickWindow = qobject_cast<QQuickWindow *>(myClass.getView());
quickWindow->setFlags(Qt::FramelessWindowHint);
//Connecting signal from QML to exit application
QObject::connect(myClass.getView()->engine(), SIGNAL(quit()), &app, SLOT(quit()));
quickWindow->show();
return app.exec(); //Here it crash
}
As I said, it fully worked with mingw (32 bit).
Can MSVC2017 x64 somehow crash when building app, that was previously used by mingw x32? Do anyone know how to fix it?
Thank you very much!
//EDIT:
Somehow, it works for release, but not for debug mode.
//EDIT:
It crashes only when app is showing visible QML object
This sounds like a 32 vs. 64-bit issue.
Try updating the dependencies on your item and see if that resolves it, you should be able to re-build the raw source to x64 if you specify that CPU build, and update any dependencies that are x86.
Or, run the app in 32-bit mode.
I have problem with my Wt web application. It's rather simple app, I do not need to deploy it on any external server (only localhost), so built in whttpd server provided by framework is sufficient for my needs. I create an executable file in release mode (Visual Studio 2015), run it, and when I open localhost:8080 in browser to access application, I get an error. In debug mode however everything works well.
Debug console shows this:
Exception thrown at 0x00007FFB08477788 in
Neural_network_visualisation.exe: Microsoft C++ exception:
std::runtime_error at memory location 0x00000025E30FB408.
Critical error detected c0000374
Neural_network_visualisation.exe has triggered a breakpoint.
main.cpp
#include "MyApplication.h"
#include "MyContainerWidget.h"
WApplication *createApplication(const WEnvironment& env) //exception is thrown here
{
Wt::WApplication *app = new Wt::WApplication(env); //error c0000374
app->setCssTheme("polished");
new MyContainerWidget(app->root());
return app;
}
int main(int argc, char **argv)
{
return WRun(argc, argv, &createApplication);
}
The exception is thrown just after entering createApplication function, but the program doesn't crash there. After executing first line critical error is shown and application stops.
The code is so simple that I can't see any problem with it. My guess is that release mode expects some special configuration to work with Wt, but official documentation doesn't mention anything more is needed while using built-in http server. Can anybody with Wt experience help me with this?
Edit 1:
I changed my code so it looks like this:
#include "MyApplication.h"
#include "MyContainerWidget.h"
WApplication *createApplication(const WEnvironment& env)
{
//Wt::WApplication *app =
// app->setCssTheme("polished");
//new MyContainerWidget(app->root());
return new Wt::WApplication(env);;
}
int main(int argc, char **argv)
{
return WRun(argc, argv, &createApplication);
}
Now the error is different and states:
HEAP[Neural_network_visualisation.exe]: Invalid address specified to
RtlValidateHeap( 000002A04F550000, 000002A05117F060 )
So this is a memory management problem. In debug mode this management works quite different than in release, that's why I do not get any error while in debug. Unfortunately, I still do not know how to fix this. Any ideas?
Problem solved. I still can't exactly tell what was the cause, but I recompiled Wt and Boost libraries and changed project properties to match with the Wt examples. I also had to change build type from x64 to x86. It works now.
I finished migrating an application from Qt4 to Qt5, it compiles and everything but it crashes at a certain point. I am debugging it and trying to find why but I have reached a dead end:
Here is the stack:
main.cpp line 373:
TouchSwibz w(NULL, NULL, renderMode ? renderMode : AppSettings::RASTERMODE);
When it reaches the breakpoint and I try to go further, it crashes with the usual
"This application has requested the Runtime to terminate it in an
unusual way."
And the aplication output shows
QWidget: Must construct a QApplication before a QWidget
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
I have thought maybe its because the widget is being initialized when the main window is being created, but what can be done to solve this? What would be a good workaround? I dont even know if this is the real issue.
I work under Windows 7 x64 using Qt 5.2.1 and compiling with mingw 4.8 32bit, the application is in 32bits also. Everything is compiled with the same kit.
I dont know what other useful information I can provide. I tried stepping inside the QwtSlider constructor but I cant.
I managed to solve it by compiling all the libraries in debug mode, turns out having libraries in release mode while building your application in debug mode will make undefined behaviour happen.
You're most likely having non-local instances of QWidget type. By definition, those will be initialized before main starts executing, so before QApplication gets constructed. The code below reproduces the problem:
#include <QLabel>
#include <QApplication>
QLabel label("Hello, world!");
int main(int argc, char ** argv)
{
QApplication app(argc, argv);
label.show();
return app.exec();
}
The fix is to delay the construction until there is a QApplication object:
#include <QLabel>
#include <QApplication>
// Won't ever be a dangling pointer.
QPointer<QLabel> label;
int main(int argc, char ** argv)
{
QApplication app(argc, argv);
QLabel label_("Hello, world!");
label.reset(&label_);
label->show();
return app.exec();
}
I just solved a similar problem, and here is my detailed situation and solution:
I use VS with Qt add-on;
and Qt version is 5.7 64 bit (but this is not important)
I compiled successfully in both debug and release mode;
I could run it in debug mode but not in release, where caused an massage "Must construct a QApplication before a QWidget".
[IMPORTANT] I first compiled and tested it under DEBUG mode, and then I met some computational thresh-hold that encouraged me to use RELEASE mode.
[IMPORTANT] I used some third-party library, related to Qt GUI component, that requires you to add an external dependency to the project.
[IMPORTANT] I just copy the configures in the Project Property page from DEBUG to RELEASE, like exteral C++ library or External Dependencies.
I finally found the reason. In the project's Property Pages dialog box -> Linker folder -> Input property page -> Additional Dependencies, one of the external library should be replaced as a release version one, which have different name, in my case, QGLViewerd2.lib to QGLViewer2.lib.
Yesterday I decided to download, install, and attempt to use Allegro 5. I also downloaded Code::Blocks 12.11 w/ the MinGW compiler. I set up everything and installed everything correctly (or so I thought) and tried to run a sample code to see if it would work:
#include <stdio.h>
#include <allegro5/allegro.h>
int main(int argc, char **argv){
ALLEGRO_DISPLAY *display = NULL;
if(!al_init()) {
fprintf(stderr, "failed to initialize allegro!\n");
return -1;
}
display = al_create_display(640, 480);
if(!display) {
fprintf(stderr, "failed to create display!\n");
return -1;
}
al_clear_to_color(al_map_rgb(0,0,0));
al_flip_display();
al_rest(10.0);
al_destroy_display(display);
return 0;
}
When I attempt to compile and run the program an error message box appears saying "The procedure entry point _gxx_personality_v0 could not be located in the dynamic link library libstdc++-6.dll." I searched the web for about an hour trying to find a fix for this problem, like I do for most things, but I came up empty handed. I'm wondering if anyone has any ideas for any fixes to this problem, if so, let me know ASAP! Thanks in advance!
__gxx_personality_v0 is used in the exception handling of the C++ library. MinGW can support a couple different exception models on the x86: sjlj (setjmp/longjmp) or DWARF (DW2). As far as I know, which model will be used is compiled into the compiler - it's not something that can be selected with a command line option.
The sjlj exception model will link to __gxx_personality_sj0, the DW2 exception model links to __gxx_personality_v0. It seems like your compiler is building for the dw2 exception model, but at runtime it's finding a libstdc++-6.dll that was built with the sjlj model. See if you have multiple versions of libstdc++-6.dll on youR system, and see if copying another one to the same directory as your program fixes the problem.
You can use nm libstdc++-6.dll | grep personality to see which exception 'personality' the DLL is using.
I ran into this as well. Did some searching, someone mentioned paying attention to whether or not you were in Debug or Release Mode. This applies to Code::Blocks specifically. I found I was in Debug Mode. I changed that to Release Mode and my program compiled and ran.
I am troubled by this though... It seems to me it should work in both modes, so how do I fix it so that it will? I have no answer there. Maybe someone will comment with the solution. In the meantime, compile and run in Release Mode instead of Debug Mode.
I just did a little mad science, removed the libstdc++6.dll from MinGW/bin and put it in another folder. Then I copied over the same file from Gimp/bin. No more linker error, instead I get an error that says the application failed to start :( Still compiles and runs in Release Mode though.
When I just declare
boost::thread t1, t2;
in my program and then compress .exe file with UPX, the compression succeeds. But when I try to launch the compressed exe, Windows tells me that it's "not valid win32 application".
There is a bug report for UPX (similar bug), but it has different error message ("The application failed to initialize properly (0xc0000005)").
In my case OS thinks the file is corrupted or something, so it cant even be started to show errors! Why??
Win7x64, C++, VisualStudio, boost 1.47, UPX3.07
strange news:
Unpacking exe makes corrupted exe that throws error exactly the same
as here. ("The application failed to initialize properly
(0xc0000005)") And this is for unpacked exe, not packed as in bug
report.
extern "C" void tss_cleanup_implemented(void) {}
before the inclusion of boost's thread header does not matter. The
result is the same.
main.cpp:
#include <boost/thread.hpp>
int main(int argc, char** argv)
{
boost::thread t;
return 0;
}
May be someone will try to compile and compress?
Bug was repaired in new version 3.08. It's ok now.