I'm learning SFML library and i picked a code from the tutorial. it opens a window and it should make me able to close it again but when i close it it says
Debug Error!
Run-Time Check Failure #2 - stack around variable 'App' was corrupted.
and then the console stops working.
this is my code:
int main()
{
// Create the main window
sf::Window App(sf::VideoMode(800, 600, 32), "SFML Events");
while (App.IsOpened())
{
// Process events
sf::Event Event;
while (App.GetEvent(Event))
{
// Close window : exit
if (Event.Type == sf::Event::Closed)
App.Close();
// Escape key : exit
if ((Event.Type == sf::Event::KeyPressed) && (Event.Key.Code == sf::Key::Escape))
App.Close();
}
// Display window on screen
App.Display();
}
return EXIT_SUCCESS;// = return 0
}
linking to the debug libraries are
sfml-system.lib
sfml-window.lib
sfml-system-d.lib//these are debug files
sfml-window-d.lib
if i ramove the first 2 and built my program it doesn't give errors but when i open it it says :
the application was unable to start correctly (0xc0150002). click ok to close the application
i have a 64 bit computer. and in microsoft vc++ 2010 i can do build solution or debug and i always do build solution.
and i am building in release mode but i have also tried both and they both didn't work
could someone please tell me what i could do to prevent this from happening or how this comes.
For these application startup issues,it is always a good idea to check if all dlls in the dependency closure are accessible - that is, are they all in the search PATH? We usually use dependency walker to check which dlls are missing, or use gflags for runtime diagnostic
While put your dlls with your exe in same folder works, it does not scale well, one way I usually do is put the library path in PATH environment variable.
And one thing to notice, sfml comes with prebuilt binrary for vs2005 and vs2008, as you are using vs2010, the underlying c runtime library(msvcrt) is different, there would be potential problems - you would better build sfml from source yourself using vs2010 or use vs2005/vs2008, just to be consistent
if you wouldnt like to use DLLs and would like to compile SFML into exe, here is tutorial:
2.0 http://www.sfml-dev.org/tutorials/2.0/start-vc.php
you need to add preprcessor directive SFML_STATIC , and include additional libs u are using in your program into linker -> input
I also had some related problems when I first time used this (and equivalent libs). Here is some points to take in count:
Do not use precompiled libraries/dlls. Learn how to use CMake, boost_build (boost libraries), Scons (mongoDB) etc. and build libraries according to currently used compiler/platform (of course if there is such possibility). After some time this process became pretty easy and simple and this will save a lot of time later for other projects.
Read SFML tutorials on making a simple project. They are easy to read and understand. May try to generate also examples with CMake and build them to see how they work. Another good tutorial is the book on SFML programming (which have a huge push on using C++11, which I think is great).
As pointed out add SFML_STATIC to "Preprocessor definitions" if don't want to use DLLs and I think is better to set "Windows (/SUBSYSTEM:WINDOWS)" in linker options (if I correctly understood from "and then the console stops working" statement).
Better to place libsndfile-1.dll and openal32.dll in release/debug folder where app is generated, from what I saw VC++ have a bad behavior on finding dlls from provided paths.
Related
I'm very new to c++ and was getting this error while trying to build Release versions of my c++ OpenGL project. After some googling I went ahead and changed the Runtime Library in the C/C++ > Code Generation menu to Multi-Threaded Debug GLL (/MDd), which then fixed the issue. I'm wondering if that's the right thing to do though.
I created a new empty project as a test, and the default Runtime Library setting in Release mode is Multi-Threaded (/MD). The default Runtime Library for Debug mode is Multi-Threaded Debug (/MDd). Despite having different Runtime Libraries, both configs build successfully, which makes me wonder if there's been a mess up in my project setup at some point.
Another detail that made me curious was the output log while trying to build in Release x64:
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\x64\Release\LoggerFactory.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\x64\Release\ConsoleAndFileLogger.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\x64\Release\Component.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\x64\Release\Physics.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\x64\Release\Rotator.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\x64\Release\IEntitySpawnHandler.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\x64\Release\SpaceScene.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\x64\Release\ActionManager.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\x64\Release\DeviceManager.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\x64\Release\Device.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\x64\Release\Mouse.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\x64\Release\MouseAxis.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\x64\Release\MouseButton.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\x64\Release\InputAction.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\x64\Release\InputAxis.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\x64\Release\Scene.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\x64\Release\GUI.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\x64\Release\GLFWKeyboardKeyData.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\x64\Release\Keyboard.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\x64\Release\GLFWPCInputDeviceFactory.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\x64\Release\Random.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\x64\Release\IndexBuffer.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\x64\Release\Main.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\x64\Release\Material.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\x64\Release\Mesh.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\x64\Release\OpenGLUtilities.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\x64\Release\Square.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\x64\Release\Shader.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\x64\Release\ShaderManager.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\x64\Release\VertexArray.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\x64\Release\VertexBuffer.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\x64\Release\SceneManager.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\x64\Release\Singleton.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\x64\Release\glm.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\x64\Release\imgui.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\x64\Release\imgui_demo.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\x64\Release\imgui_draw.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\x64\Release\imgui_impl_glfw_gl3.obj
**D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\x64\Release\Window.obj
**D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\Win32\Debug\Camera.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\Win32\Debug\Color.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\Win32\Debug\Debug.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\Win32\Debug\ObjectRenderer.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\Win32\Debug\Entity.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\Win32\Debug\SpaceShip.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\Win32\Debug\Star.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\Win32\Debug\Input.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\Win32\Debug\KeyboardKey.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\Win32\Debug\Math.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\Win32\Debug\Renderer.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\Win32\Debug\Time.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\Win32\Debug\Transform.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\Win32\Debug\Vector2.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\Win32\Debug\Vector3.obj
I've highlighted two lines where the intermediate file path changes from bin\x64\Release to bin\intermediates\Win32\Debug, and was wondering if this might help with the issue.
Though not a perfect solution, I ended up creating a new project and reimporting all dependencies one after another, compiling in between to try and find the issue. After importing all libraries, the new project just worked. I then copied all of my code and compiled it in the new solution, which worked, so the issue has been resolved.
I saved a diff between the two project files, but couldn't find the issue (they are too different for me to make sense out of). Maybe someone with more experience can figure it out.
Looking for some advice as to what can cause a crash of this type in Windows when loading a dll.
I'm writing a Windows VST3 .dll plugin in C++, and experiencing a crash on startup when my .dll is loaded. When running the host application and the plugin via Visual Studio 2019 debugger I'm getting the Access violation executing location ... dialog shown above, and the call stack is empty, making me think memory is completely corrupted.
Maybe this is caused by linking options I need to tweak when building the .dll?
Here are some facts:
The plugin itself works fine. I can get it to load and unload without issues when all 3rd party API calls are commented out.
If I link some 3rd party libraries into my plugin, then again everything works fine.
Once I make a call to any of those 3rd party libraries, then that causes the segfault on startup.
Plugin is built with /MD, but I also tried /MT and saw the same behaviour.
I'm using JUCE C++ to get the VST3 framework and GUI components.
An example of one of the 3rd party library I'm linking against and attempting to call into is the SuperpoweredSDK C++ library. But I've tried other libraries, and I'm seeing the same behaviour with each one.
Unfortunately, getting an entire blank VST3 plugin together is too much code to post in a StackOverflow question. But since I can get the plugin to work if I comment out all calls to 3rd party libraries, I don't think the code itself is the issue, I think the way the dll (.vst3) file is built is the problem.
The critical portion of the CMakeLists.txt file that builds the .vst3 dll file looks like this:
FIND_LIBRARY ( SuperpoweredSDK NAMES SuperpoweredWin141_Debug_MD_x64.lib PATHS ${SUPERPOWERED_DIR}/libWindows )
SET ( TEST_EXTERNAL_DEPS PRIVATE Threads::Threads ${SuperpoweredSDK} )
FILE ( GLOB JUCE_SOURCE ${CMAKE_HOME_DIRECTORY}/JuceLibraryCode/*.cpp )
LIST ( FILTER JUCE_SOURCE EXCLUDE REGEX ".+/JuceLibraryCode/include_juce_audio_plugin_client_[^u].+" )
FILE ( GLOB PLUGIN_SOURCE *.cpp )
ADD_LIBRARY ( TestVST3 SHARED ${JUCE_SOURCE} ${PLUGIN_SOURCE} ${CMAKE_HOME_DIRECTORY}/JuceLibraryCode/include_juce_audio_plugin_client_VST3.cpp )
SET_TARGET_PROPERTIES ( TestVST3 PROPERTIES OUTPUT_NAME "Test" SUFFIX ".vst3" )
TARGET_LINK_LIBRARIES ( TestVST3 PUBLIC ${TEST_EXTERNAL_DEPS} )
what can cause a crash of this type in Windows when loading a dll
Typical reason is initializer of some global variable. Example code that will crash when loading the DLL:
class C
{
public:
C() { __debugbreak(); } // Compiles into `int 3` interrupt, will definitely crash
};
static C g_c;
When you link an external library but don’t call it, linker’s dead code elimination feature often drops complete .obj file which are linked but unused. This also drops variables there, along with their constructors.
One way to debug, set breakpoint on DllMain. But not the DllMain in your code, another one, that’s actually exported. In VC++ 2017 CRT that one is called dllmain_dispatch, the source file for that is in VC++ runtime, crt\src\vcruntime\dll_dllmain.cpp. That dllmain_dispatch calls a couple of functions before calling your DllMain, one of them, dllmain_crt_process_attach, calls _initterm and that one actually calls constructors of all the global stuff. At least one of them fails in your case.
P.S. A possible reason of a crash like this, your third-party library is trying to use COM, and the thread which called LoadLibrary never called CoInitialize().
We eventually did find the cause of this crash. With VST3 files, the DAW loads each .dll (or .vst3), queries the capabilities, and immediately unloads the dll again. It then moves on to the next file, and the process starts all over until all plugins have been queried.
In this case, one of the 3rd party libs I was using (SuperpoweredSDK) starts a background thread to verify the license against a web server somewhere. This was not documented. With the background thread started, the DAW unknowingly proceeds to unload the DLL, leaving the thread hanging there running code that no longer exists! And thus, the crash without any call stack.
Several possible solutions:
Move the SuperpoweredSDK initialization code until later when it really is needed.
In a future not-yet-released version of SuperpoweredSDK (current version is 2.0.1), they're apparently adding an API call to shutdown Superpowered, and that shutdown call will wait until all background threads have finished running. Make sure you call this new API.
I have followed (twice, now) the setup guide for getting SFML up and running in Visual Studio. I have made sure that the proper .lib files and directories are being pointed to in the project's settings and that the required .dll's are present in the application's working directory, as per the guide.
I am trying to run the following: (ambitious, I know...)
#include "stdio.h";
#include <iostream>;
#include <SFML/Graphics.hpp>;
int main ()
{
sf::RenderWindow window( sf::VideoMode( 640, 480 ), "Title" );
std::cin.get();
}
Compile is successful, but as soon as the application starts, I get:
Exception thrown at 0x56D5EEB6 (sfml-system-d-2.dll) in D20 RPG.exe: 0xC0000005: Access violation reading location 0xCCCCCCD8.
With the first line commented, the application starts and finishes without a problem.
Do I need to locate the SFML source and compile it myself? It is a fairly sprawling library with a lot of dependencies, so that's something I've been avoiding unless someone thinks it might help. My experience with C++ and VS is shallow enough that I think I'd be more likely to introduce more problems before solving this one.
I was able to get this code working by creating a new empty console application project and using the NuGet package manager interface to install the sfml-graphics, sfml-window, and sfml-system packages.
I have been trying out SDL for iOS, and it has been going smoothly until I added sdl_ttf to the mix. The only output that I would get was
apinames 0.1: extract FreeType API names from header files
this program is used to extract the list of public FreeType API
functions. It receives the list of header files as argument and
generates a sorted list of unique identifiers
usage: apinames header1 [options] [header2 ...]
options: - : parse the content of stdin, ignore arguments
-v : verbose mode, output sent to standard error
-oFILE : write output to FILE instead of standard output
-dNAME : indicate DLL file name, 'freetype.dll' by default
-w : output .DEF file for Visual C++ and Mingw
-wB : output .DEF file for Borland C++
-wW : output Watcom Linker Response File
Upon googling, I found this SO question from someone who had the same problem as me: SDL2_ttf won't run on ios
It seems that a different main (one inside sdl_ttf) is being run and is producing the output.
A commenter on the post I mentioned said "I would guess you included apinames.c in your project from the tools directory and that main is what is getting run". What is the tools directory? How would I fix that?
How would I change the entry point of the Xcode project to my main.cpp?
Thanks for any advice.
I would have to actually see your project to answer #1 (did you look at your "compiled Sources" for apinames.c?), but maybe that will be irrelevant if I answer #2.
If you look at the SDL_main.h source file you will see:
#elif defined(__IPHONEOS__) /* On iOS SDL provides a main function that creates an application delegate and starts the iOS application
run loop.
See src/video/uikit/SDL_uikitappdelegate.m for more details. */
#define SDL_MAIN_NEEDED
turns out you can subclass SDLUIKitDelegate and force SDL to instantiate it by creating a category like this:
#implementation SDLUIKitDelegate (MyDelegate)
+ (NSString *)getAppDelegateClassName
{
//override this SDL method so an instance of our subclass is used
return #"MyDelegateClass";
}
#end
you will want to look at the source for SDLUIKitDelegate so you can get a feel for what you are messing with, but my app just overrides application:didFinishLaunchingWithOptions: like this:
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
AddLogger(createAppleLogger());
[self setupWrapper];
// Notice how we call super implementation so SDL can finish its setup
return [super application:application didFinishLaunchingWithOptions:launchOptions];
}
Is this close enough for the entry point for you? Or do you really need main()? It would mean having to do all the SDL setup yourself (which can change between SDL revisions).
Also note that your main() should get redefined as SDL_main and should get called at some point early on (if my memory serves).
Drag to re-order your frameworks within "Link Binary With Libraries" found in your xcode build target under "Build Phases". Ensure that SDL2.framework (or whatever you are using) is above SDL2_image.framework.
#include <FL/Fl.H>
#include <FL/Fl_Window.H>
int main() {
Fl_Window win(400, 400);
win.show();
return Fl::run();
}
I'm compiling with "fltk-config --compile main.cpp". The code compiles without incident, but when the application is run I only get a console window and no GUI.
I've also tried using fluid from terminal (via "fluid main.cpp"); I'm not even sure I'm using this correctly since, as I understand, fluid is a graphical editor. In any case, the result is "Can't open display: ". I found the same error but for a different situation here. Somebody in that thread suggested doing "export DISPLAY=:0.0", which I tried. Now when using fluid the error has simply changed to "Can't open display: :0.0".
It's worth noting that I've also tried using Qt4 as a framework (using qmake/make to compile), but I have the exact same problem. Console loads, no GUI of any sort, despite using code that various sources say should work.
edit
I found this question. I used DependencyWalker to find .dlls used by my .exe, and placed copies of those .dlls directly into my project folder. This did not fix my problem, or change it in any way. For reference, the .dlls I used were: cygfontconfig-1, cyggcc_s-1, cygstdc++-6, cygwin1, cygX11-6, cygXft-2, kernel32.
I also tried the same solution for Qt, again with no success. In that case, the .dlls were cygwin1, cyggcc_s-1, cygstdc++-6, cygqtcore-4, cygqtgui-4, kernel32.
For some good news, I've found that can successfully build an application with the Qt Creater SDK, so the problem lies somewhere with my manual compiles only. In any event, I'd still like to solve this problem. I dislike using an SDK for small projects, and I'd like to keep my library options open.
If fltk-config --cxxflags and fltk-config --ldflags do not output -mno-cygwin, then your FLTK was compiled to work with Cygwin's X Window System - something you probably want to avoid. Add -mno-cygwin to your Makefile and your FLTK application should work.
I always liked MinGW+MSYS more.