I'm working on a Vulkan application (that has nothing to do with OBS).. and I have strange messages and unexpected crash
[OBS] OBS_CreateDevice: texture sharing is not supported
[OBS] Failed to open pipe
[OBS] graphics-hook.dll loaded against process: coffeecupd.exe
[OBS] (half life scientist) everything.. seems to be in order
Seems like obs is injecting something in my code..how can I isolate my Vulkan application?
Of course, I'm puzzled as OBS is shut down while this happens
Related
When using Renderdoc to debug my Vulkan applications, I have noticed that when I execute the application normally somehow Renderdoc is also running and producing the statistics overlay on the window.
For example when executing ./executable from the command line I get:
(The information on the top left corner is the Renderdoc statistics)
Note that this still applies when deleting and re-compiling the executable.
I have tried uninstalling Renderdoc but I get the error that Vulkan fails to load librenderdoc.so, I have even tried reinstalling the Vulkan libraries but have had no luck.
Any help as to how I could execute my program normally without displaying the program statistics would be greatly appreciated.
The terminal output (from the validation layers) display:
Renderdoc uses Vulkan's layer mechanism to inject itself into the executable.
They have a lengthy blog post explaining the gory details, but basically what happens is that at runtime all your Vulkan API calls pass through Renderdoc first, which is what causes the statistics to appear. If you don't want that, you simply need to not include the Renderdoc layer when initializing Vulkan.
You either requested Vulkan to pull in the Renderdoc layer via the ppEnabledLayerNames field in the VkInstanceCreateInfo sturct passed to vkCreateInstance. In that case, you need to change your code to no longer do that and recompile the executable. Or, you may have Renderdoc loaded as an implicit layer. In that case, the executable does not need to be changed at all (and running the executable on a different machine that does not have Renderdoc installed will just work without showing the overlay). Instead, it is the Vulkan loader that pulls in the Renderdoc layer automatically.
So in that latter case, you need to change the loader configuration for your system. Since this works differently for every system and you did not mention which OS you are using, I will just leave you with a link to the official documentation that contains detailed info for all major operating systems. Simply remove Renderdoc from the list of implicit layers and the overlay should disappear.
I am evaluating different multiprocessing libraries for a fault tolerant application. I basically need any process to be allowed to crash without stopping the whole application.
I can do it using the fork() system call. The limit here is that the process can be created on the same machine, only.
Can I do the same with MPI? If a process created with MPI crashes, can the parent process keep running and eventually create a new process?
Is there any alternative (possibly multiplatform and open source) library to get the same result?
As reported here, MPI 4.0 will have support for fault tolerance.
If you want collectives, you're going to have to wait for MPI-3.something (as High Performance Mark and Hristo Illev suggest)
If you can live with point-to-point, and you are a patient person willing to raise a bunch of bug reports against your MPI implementation, you can try the following:
disable the default MPI error handler
carefully check every single return code from your MPI programs
keep track in your application which ranks are up and which are down. Oh, and when they go down they can never get back. but you're unable to use collectives anyway (see my opening statement), so that's not a huge deal, right?
Here's an old paper (back when Bill still worked at Argonne. I think it's from 2003):
http://www.mcs.anl.gov/~lusk/papers/fault-tolerance.pdf . It lays out the kinds of fault tolerant things one can do in MPI. Perhaps such a "constrained MPI" might still work for your needs.
If you're willing to go for something research quality, there's two implementations of a potential fault tolerance chapter for a future version of MPI (MPI-4?). The proposal is called User Level Failure Mitigation. There's an experimental version in MPICH 3.2a2 and a branch of Open MPI that also provides the interfaces. Both are far from production quality, but you're welcome to try them out. Just know that since this isn't in the MPI Standard, the function prefixes are not MPI_*. For MPICH, they're MPIX_*, for the Open MPI branch, they're OMPI_* (though I believe they'll be changing theirs to be MPIX_* soon as well.
As Rob Latham mentioned, there will be lots of work you'll need to do within your app to handle failures, though you don't necessarily have to check all of your return codes. You can/should use MPI error handlers as a callback function to simplify things. There's information/examples in the spec available along with the Open MPI branch.
I know there is a way to get crashes and hangs for all applications. These files are placed in "/Users/user/Library/Logs/DiagnosticReports". So I could get version, time and name of the app.
But how to get daemon/process crashes and hangs? I need to know which exactly daemon was crashed/hanged and time when it happened.
Also is there is a way to get some system(OSX) crash with the same info?
Also would be great to get some resource failures/warnings: out of memory or out of disk space.
I need to get it programatically.
On Windows we can do this using NotifyChangeEventLog () API. All these info we can gather using such method. Also it notifies if something happened.
For the daemons crash/hang report see the "/Library/Logs/DiagnosticReports" directory. According to this document you can also find there kernel panic reports (i.e. system crash).
Don't know about NotifyChangeEventLog-like API, but in situations like "out of memory" there will be an exception, so you just need to catch it. See Error Handling Programming Guide for details. Also take a look at Exception Programming Topics
Edit: for the information about Crash Reporter take a look at Chapter 5 of Levin's book "Mac OS X and iOS Internals: To the Apple's Core"
in 10.9 the activity monitor offers you two tools when you have a hang but no crash hence no crash report:
spindump - memory dump like crash report and
sys digs which produces a bundle of files
My App suddenly crashes at one point (reproducible) when run on a 512mb phone emulator (only have a 920 to test). There wasn't any exception, it just went black. I then ran the analysis tool on the application and found out the memory reaches its limit at the point the app crashed. The app exits with an error code. The most recent one I found was 0x887a0005, but I'm pretty sure I saw another one a little time back. Sadly, I don't have that one anywhere.
I load about 600 images from the web into BitmapImages with the CreateBackground option, and handle the ImageOpened event.
I'm not asking for help managing the problem itself, I'll find a way to work around it. I'm just wondering why the App isn't throwing any exceptions, and instead just crashes. Any ideas her
This is expected behavior. Depending on which piece of code is executing at the very moment you run out of memory, an out of memory exception may be thrown - if one can be thrown by that specific .NET class or under laying class. But the operating system is not going to wait for this to happen, and will usually just terminate your app. It's not sending your app a "terminate" or "out of memory" signal, it just kills it.
From what experience I have programming whenever a program has a problem it crashes, whether it is from an unhanded exception or a piece of code that should have been checked for errors, but was not and threw one. What would cause a program to completely freeze a system to the point of requiring a restart.
Edit: Thanks for the answers. As for the language and OS this question was inspired by me playing Fallout and the game freezing twice in an hour causing me to have to restart the xbox, so I am guessing c++.
A million different things. The most common that come to mind are:
Spawning too many threads or processes, which drowns the OS scheduler.
Gobbling too much RAM, which puts the memory manager into page-fault hell.
In a Dotnet/Java type environment its quite difficult to seize a system up, because the Runtime keeps you code at a distance from the OS.
Closer to the metal say C or C++, Assembly etc you have to play fair with the rest of the system - If you dont have it already grab a copy of Petzold and observe/experiment yourself with the amount of 'boilerplate' code to get a single Window running...
Even closer, down at the driver level all sorts of things can happen...
There are number of reasons, being internal or external that leads to deadlocked application, more general case is when something is being asked for by a program but is not given that leads to infinite waiting, the practical example to this is, a program writes some text to a file, but when it is about to open a file for writing, same file is opened by any other application, so the requesting app will wait (freeze in some cases if not coded properly) until it gets exclusive control of the file.
And a critical freeze that leads to restarting the system is when the file which is asked for is something which very important for the OS. However, you may not need to restart the system in order to get it back to normal, unless the program which was frozen is written in a language that produces native binary, i.e. C/C++ to be precise. So if application is written in a language which works with the concept of managed code, like any .NET language, it will not need a system restart to get things back to normal.
page faults, trying to access inaccessible data or memory(acces violation), incompatible data types etc.