SFML community forums
Bindings - other languages => DotNet => Topic started by: myl on June 14, 2013, 03:52:12 pm
-
Hey Laurent and other SFML users.
I'm currently moving a project from SDL to SFML. Happy times, except when it comes to error handling. Going through forum threads on the topic I understand this is not an easy fix. Typed errors is a luxury, but I would be happy if I can just reroute or catch the messages in std err somehow. Has anyone had luck with this? This does not work for me: http://stackoverflow.com/questions/1579074/redirect-stdoutstderr-on-a-c-sharp-windows-service
I've attempted to make a wrapper around the sf::err stream in the excluded SFML System module, but with no luck, as a am merely a mortal C# developer.
Help! I need my errors!
-
Aren't the exceptions thrown by SFML.Net enough for you? Why do you want to catch the original SFML messages?
-
The LoadingFailedException provides no information to my knowledge? I would very much like to log the reason to have any chance of debugging whenever a user reports an error. It also seems a lot of useful information is being outputted without throwing exceptions.
-
Ok, I see.
I'm sorry I can't help (if I could, it would be done directly in SFML.Net ;)).
-
Would it make sense to expose a function that takes a stream or filehandle/filepath to reroute the stderr?
-
I don't know. I'm not very satisfied with the way I handle errors (I mean on the C++ side), so I'd rather think about a different error management system, instead of "fixing" the current one.
-
Hmm, this is now causing me a lot of pain, i have 100+ users reporting texture load error on the same hardware, but no way of catching the sfml output. Any ideas much appreciated!
Merci!
myl
-
For debugging you can run the app with a redirection of the standard error output to a file, for example.
myapp 2> errors.txt
-
Something funny is going on because that does not work, and I suspect the code example mentioned earlier doesn't work for the same reasons (essentially the same).
I tried redirecting stderr from command and also tried redirecting everything, but the output file doesn't contain sfml output. The console window no longer displays sfml output, and a file is generated but i have no clue where the output goes.
I remember reading somewhere that some compilers do interesting stuff related to redirection. What was the pre-built csfml binaries in the win 32bit .Net package built with?
-
The console window no longer displays sfml output
So you already have the SFML error output in the console? So you can see what happens for the loading failure?
I remember reading somewhere that some compilers do interesting stuff related to redirection. What was the pre-built csfml binaries in the win 32bit .Net package built with?
I don't do anything special regarding redirections.
-
I get console output locally yes (when I don't redirect), but I am unable to reproduce the loading failure in question, which is why i need to figure out how to collect debug info in the field.
Pretty strange the output disappears into thin air when redirected.
-
I get console output locally yes (when I don't redirect), but I am unable to reproduce the loading failure in question, which is why i need to figure out how to collect debug info in the field.
Ok, so you're not completely blocked, you can distribute a build with console to one user who is able reproduce the error.
Pretty strange the output disappears into thin air when redirected.
It must go somewhere. Do you run the app from Visual Studio? If so, the working directory is not the executable directory, it's the project directory by default.
-
Ok, so you're not completely blocked, you can distribute a build with console to one user who is able reproduce the error.
Reproduction frequency is very low unfortunately, but since we have many users, i get a lot of reports. Hard to find a single point of manual testing. :/ And I would have to go some places i am not comfortable with in a production environment (keeping console windows open after crashes is suboptimal).
It must go somewhere. Do you run the app from Visual Studio? If so, the working directory is not the executable directory, it's the project directory by default.
The file is created and whatever debug output i throw at Console.Out lands in it, excluding the sfml out. Meaning the sfml output is redirected, but not to the same place as the .Net generated out.
-
The file is created and whatever debug output i throw at Console.Out lands in it, excluding the sfml out. Meaning the sfml output is redirected, but not to the same place as the .Net generated out.
Ah, I see. This is really strange.
-
From the comments in this post:
http://stackoverflow.com/questions/2215312/getting-stdout-when-p-invoking-to-unmanaged-dll
i understand that there could be issues with redirection of stdout/stderr for MinGW compiled dlls on windows. Are the 32bit windows csfml dlls MinGW compiled?
Merci!
myl
-
Are the 32bit windows csfml dlls MinGW compiled?
No, I always use Visual C++.
-
Hmm ok. No idea then. I don't know the lowlevel win32/compiler stuff that could be causing this weird behavior. My best idea now is to:
1. Make sfml redirect sf:err hardcoded in source:
std::ofstream file("Path\\ToSome\\File.txt");
std::streambuf* previous = sf::err().rdbuf(file.rdbuf());
2. Setup sfml build environment and build
3. Setup csfml build environment and build
Any other suggestions? I really don't wanna move away from sfml :/
Merci!
myl
-
Even though I have little knowledge of visual c++, I guess the issue could be caused by this:
http://www.syndicateofideas.com/posts/fighting-the-msvcrt-dll-hell
Not sure if knowing this brings me any closer to a solution :/
-
It's quite long. Can you summarize what it says? ;D
-
It's quite long. Can you summarize what it says? ;D
I will do my best to summarize it.
Whenever you compile any C\C++ program with VS it is bound to MSCRTxxx.DLL. The xxx is a number that relates to version of VS that you used (VS 2003, VS 2005, VS 2008, ect...). So if you attempt to get output from a DLL that was compiled in a different version of VS the output is not directed correctly.
Here is a quote that sums up the safe solution.
The only safe solution is to use the same CRT for your application and your application’s modules. This has some drawbacks of course, and the major one is that you simply must ensure that all dependencies are using the same compiler generation and thus linking to the same CRT DLL. Within Apache Httpd we were using good old Visual Studio 6.0 for producing official binaries, but recently there were some discussion to switch to Visual Studio 2010.
Myl, what I would suggest is that you try to recompile CSFML with whatever version of VS you are using.
-
Myl, what I would suggest is that you try to recompile CSFML with whatever version of VS you are using.
You should do it :P
I'm not going to provide 3 different builds of CSFML when I can only have one that works with all the Windows compilers.
I agree that this problem is annoying, but as I said, I'd rather find a more convenient way to handle errors.