I have a strange issue, a vulkan application I am writing seemingly runs fine when run from the terminal. But if run from renderdoc an assertion inside the official .hpp header triggers.
Since this only happens if the program is launched with renderdoc I am having a hard time trying to debug it.
Is there a way to get the exact environment configuration renderdoc is using to run the program so that I can replicate the bug?
It is quite bizarre it only happens if the new dynamic rendering extension is active too. If it is not requested renderdoc doesn;t seem to trigger the assertion. But I am on the latest version (1.18).
If anyone runs into something like this in teh future. The problem was that an old instance of renderdoc was installed in my system, this in turn created conflicts when loading the program onto renderdoc as vulkan wasn't properly configured.
Uninstalling the old version fixed it.
Related
I'm using Xcode 3.0 on a PowerBook G4. I needed to test some code to see how it runs on a big endian host. I already had it set up to go so got it out to test.
I first created an empty project and added my binary as a custom executable as well as loading in some source files. This seemed to be working fine. The code is a C++ terminal application and I had already setup a Makefile with CMake.
In the beginning I set up some breakpoints and started up the debugger. And it worked well. Stopping at my breakpoints. But then something happened that I don't know what and it started ignoring them.
I setup a new project like before and started from scratch again. Loaded the debugger. And once again it ignored them!
So then I managed to get CMake (2.8.12) to generate an Xcode project file. Which didn't go too easy as it didn't know what compiler I had. Looks like I stumbled onto another bug there. I eventually got past it by going between the CMake GUI and terminal.
I then closed all windows in Xcode and quit it. I then opened up the new project to start afresh. I set up some new breakpoints and loaded up the debugger. The code fell through again but then I realised I didn't set any arguments. So I did that and tried again. It ran through again! I looked up how to reset Xcode prefs and did so. Try again and it keeps ignoring my breakpoints!
I know it's kinda bad to setup an account to ask a question. And I hate to do that. But I'm really over this and don't know what is wrong with it. I've Googled for answers, got some hits here, and tried suggestions like disabling lazy symbols, making sure strip doesn't kill debug symbols and other symbol stuff but none has any affect. I've wasted hours trying to fix it instead of testing code I need too.
What's disconcerting is that no source is loading into the [GDB] debugger either. I actually forced it to stop by doing an implicit read from location zero in my source. And even this wasn't right. It didn't even load up the source but just gave me a disassembly. Even though I had it set to show only source. There's something wrong with it. :-?
Well thanks for any help. I don't know if I'm getting old or what. But this is getting as annoying as a small hidden bug in code that brings the whole house down! ;-)
I have been improving an OpenGL code of my own since some days, and now I got a terrible surprise: My code works properly if run from inside CodeBlocks IDE (by Menu-> Build -> Run), but if I open it from the Windows Explorer, the program will still open and issue messages on the console as if it would be running properly, but I just get a blank screen.
I have trying re-building the code to see if the problem disappears from Windows, or to see if it also affects the run from inside CodeBlocks, but the outcome is still the same.
Some days ago (before much of the code change), I could start the program from both Windows and CodeBlocks and run perfectly in both cases, so this is totally surprising for me now.
I use GLFW3 and GLEW and I am linking to the following libraries:
C:\msys64\mingw64\lib\libglew32.dll.a
C:\msys64\mingw64\lib\libglfw3.a
opengl32
C:\msys64\mingw64\lib\libsfml-system.dll.a (I use the clock of this library)
gdi32
On the meantime I have deinstalled and installed msys64, but this didnt affect my other OpenGL projects linking the same libraries, so I suppose this is not the source of the problem
How would I proceed to debug such an issue? I have no clue about how to start troubleshooting this, so any comment on what extra info I should post is welcome.
Update: If I open the application from the GPU PerfStudio and CodeXL, everything works just fine, but not when I open via Windows Explorer.
How would I proceed to debug such an issue?
When I deal with bugs like this I use a tool called CodeXL. You can download the latest version here. It automatically breaks on any OpenGL error and shows you which of your OpenGL function calls caused it.
It is free and it works also with non-AMD GPUs.
It should not take you long time to learn how to use it: you just create a new project, give it path to your project folder and .exe and hit run. (make sure that Debug->Breakpoints->Break on OpenGL error is checked)
//Moreover, it visualizes your buffers, shows you your loaded textures, etc.. Definitely check it if you plan to program more Windows+OpenGL in the future.
I have a strange problem using Visual Studio 2010.
I'm running a DLL, which is loaded from IIS in the process w3p.exe from Microsoft. When I start the remote debugger on another machine and attach my local machin there, everything is fine and I can debug.
The problem is when I run it locally. I know that the DLL is loaded (because of logfiles) and I can attach the debugger to the process. But when I try to Break all I get an error saying
Unable to break execution. This process is not currently executing the type of code you selected to debug.
The project settings are definitely pointing to the project that just compiled the running DLL, so I don't really understand this error message.
Also when I set breakpoints nothing happens. The debugger is attached though, because when I stop IIS then I get an error message telling me that the debugger needs to be stopped first.
I'm using an intentional application error fopen(NULL, NULL) which will allow me to attach a debugger in the debug build. But this is rather annyoing, because I have to clear the call stack manually before I can actually start debugging. Using __debugbreak() doesn't help, so I have to use this clumsy workaround.
So can anybody tell me why this works remotely, but not locally?
So I finally found a solution to my problem.
When opening the attach dialog there is an option Attach to: Managed... with a Select button beside it. By default this was set to Managed (v4.0). Now I added Native code and this solved my problem. I can attach now locally as well.
I sure don't understand why this works on a remote machine, because the code is exactly the same though, so there shouldn't be such a difference.
My system is Win 8.1 64-bit and using VS2013 Express. I can verify my video cards support the latest OpenGL and OpenCL. I used the latest code and media files from authors github and site: https://github.com/openglsuperbible/sb6code and http://www.openglsuperbible.com/example-code/ respectively.
I am able to make debug and release builds of the project(s) successfully but cannot correctly run it either via debug mode or the .exe in the bin folder. A white window will show up and then exit. I was able to step through and found that glfwOpenWindow will return false causing the exit but I cannot step further and see why it is returning so. I found some solutions that suggested changing
glfwOpenWindowHint(GLFW_OPENGL_PROFILE, GLFW_OPENGL_CORE_PROFILE);
to
glfwOpenWindowHint(GLFW_OPENGL_PROFILE, 0);
but this does not change my results. I can verify also that major version is 4 and minor is 3 for the book code. I have found a few other people having the same problem but no resolution. Another possible solution (but to a different problem it seems) was changing the project subsystem to Console from Windows but this throws an error regarding main and so it may not be what I'm looking for.
For reference, this book is using glfw version 2.7.6 when (currently) the latest is 3.0.4. I tried swapping this too but it understandably blew up due to all of the changes.
Any further ideas would be great and very helpful!
I have discovered that while my GPU does support the latest OpenGL, my computer was instead using the integrated Intel HD 4600! By switching my computer to use the dedicated GPU by default, I am able to run the latest OpenGL.
If it successfully compiled, then please do following:
Ensure that you do have the latest graphic card drivers installed (eg. if you have nVIDIA card, go to www.nvidia.com and get newest drivers).
Ensure that files which these examples are trying to load (I guess jpg/tga/png files, maybe some obj/fbx/3ds files for geometry, whatever else these examples need) are present at expected path (relative path to exe).
Run it as a debug, place breakpoints in app initialization, see that OpenGL is initialized correctly and that required files are loaded. I think you will find that required files are not in expected path(s).
P.S.
I think the best practice for learning OpenGL is not to rely on some library to open window and initalize OpenGL for you - it's better you learn it all step by step - how to open an application window, how to initialize gl render context associated with device context etc. You'd also avoid things like this when you don't know where the problem could be.
Basically, yesterday I could program in C++ and today I cannot.
I'm trying to write a simple hello world program in Eclipse Helios using the MinGW C/C++ compiler and I'm running into several problems, and I believe this one to be the root of it.
At first the program compiled and built, but when I tried to run it, an error dialogue said the FirstProject.exe file could not be found/does not exist in the launch configuration. However, I got no errors building and I could clearly see the binaries in Debug/FirstProject.exe in my project explorer. I tried refreshing my project explorer and alas, the file disappeared before my eyes.
I tried building the program again, and that's when I get this error:
c:/mingw/bin/../lib/gcc/mingw32/4.6.1/../../../../mingw32/bin/ld.exe: final link failed: No space left on device
I don't know what device it's talking about. I have more than 1TB left on this hard drive, so it can't be that. I tried emptying my %Temp% folder and recycling bin (suggestions I found trying to search for a solution for this problem) but to no avail.
It may be worth noting that C++ programs I have written in the past are still running. I'm very new to programming, so I don't know how much information you need, but I'll gladly add anything you need if you think you can help me out.
I just solved this on one of the computers at work which had the same issue when compiling through Codelite. Moving workspaces, rebooting, and reinstalling Codelite didn't fix the problem. I also checked permissions on the /temp folder which were fine.
It turns out there were permission issues/other issues with the disk. Running a disk check fixed a few issues on the disk and that allowed the program to compile. If this doesn't solve your issue you may also want to try disabling any anti-virus/spyware programs and try again.
I just solved this problem on my PC. Actually what the problem in my case was that my windows defender (or any antivirus in someone's case) was blocking ld.exe from accessing the protected folder that is the source code folder. You can correct this by going into the Virus and threat protection settings of your PC and then find there for blocked history. You will definitely find there a history record of that blockage. Then just go and allow on this device it. And boom 😁