Usually an access violation terminates the program and I cannot catch a Win32 exception using try and catch. Is there a way I can keep my program running, even in case of an access violation? Preferably I would like to handle the exception and show to the user an access violation occurred.
EDIT: I want my program to be really robust, even against programming errors. The thing I really want to avoid is a program termination even at the cost of some corrupted state.
In Windows, this is called Structured Exception Handling (SEH). For details, see here:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms680657%28v=vs.85%29.aspx
In effect, you can register to get a callback when an exception happens. You can't do this to every exception for obvious reasons.
Using SEH, you can detect a lot of exceptions, access violations included, but not all (e.g. double stack fault). Even with the exceptions that are detectable, there is no way to ensure 100% stability after the exception. However, it may be enough to inform the user, log the error, send a message back to the server, and gracefully exit.
I will start by saying that your question contains a contradiction:
EDIT: I want my program to be really robust, ... The thing I really want to avoid is a program termination even at the cost of some corrupted state.
A program that keeps on limpin' in case of corrupted state isn't robust, it's a liability.
Second, an opinion of sorts. Regarding:
EDIT: I want my program to be really robust, even against programming errors. ...
When, by programming errors you mean all bugs, then this is impossible.
If by programming errors you mean: "programmer misused some API and I want error messages instead of a crash, then write all code with double checks built in: For example, always check all pointers for NULL before usage, even if "they cannot be NULL if the programmer didn't make a mistake", etc. (Oh, you might also consider not using C++ ;-)
But IMHO, some amount of program-crashing-no-matter-what bugs will have to be accepted in any C++ application. (Unless it's trivial or you test the hell out of it for military or medical use (even then ...).)
Others already mentioned SEH -- it's a "simple" matter of __try / __catch.
Maybe instead of trying to catch bugs inside the program, you could try to become friends with Windows Error Reporting (WER) -- I never pulled this, but as far as I understand, you can completely customize it via the OutOfProcessException... callback functions.
Related
I have a random Runtime Error 216 that appears on application close.
I have debugged as far as I can and the error is thrown in SysUtils.FinalizeUnits.
I have gone over the code and ensure all created objects are freed.
The number on the runtime error, 0040054A, is not present in the mapfile. Do you know what this means?
Can anyone tell me how to find out what is throwing the error?
This is VERY OLD Delphi problem - wrong exception handling in unit initialization/finalization process.
The problem easy to reproduce - just make any program error/exception (division by zero for instance) in initialization block of any unit. The exception will be created correctly. But then, before the exception rise, the unit finalization process destroy the exception object. And thus, when the exception object accessed, the "runtime error 216" occured.
I'd suspect a memory leak (all Runtime Errors 216 I've encountered so far were) and use a profiler (visual inspection is never as good as a tool). Since you're using Delphi XE, you should give AQTime a try (it's included), see also
Delphi - Check if memory is being released "on time"
Kind regards, Frank
Since runtime error 216 is an access violation, this may indicate that you're attempting to use something that you've already freed.
Addresses in the map file are based at 0, but that's not where your EXE file gets loaded into memory. Your EXE gets loaded at its preferred base address, which is usually $400000. Subtract that from the address you have. The address you're looking for in the map file is $0000054a.
There was a similar question, Read:
How to debug a crash that only occurs on application shutdown? (Delphi)
Consider using Memory profiler, this may help identifying live objects after app was terminitated.
I suggest you try the FastMM Full Debug Mode, and either statically link that into your app, or use it as a package (if your app uses packages).
You can use the method I used to fix mine.
I commented out the main program, and added code back until it failed.
Turns out that it did not want me to call couninitialize at all. Did not throw an error at the time, but failed after program termination with a 216. Removing the offending statement fixed it.
Since this was maybe 6 statements before end. statement, I don't imagine it will matter.
This method is easy if you are consistent about using // for comments. I moved IO statements that needed curly brackets to a procedure.
On Microsoft's oficial web site it is mentioned that, this issue can occur if your computer is infected with a SubSeven Trojan virus.
Antivirus software and windows registry cleaner should help.
I have been asked to debug, and improve, a complex multithreaded app, written by someone I don't have access to, that uses concurrent queues (both GCD and NSOperationQueue). I don't have access to a plan of the multithreaded architecture, that's to say a high-level design document of what is supposed to happen when. I need to create such a plan in order to understand how the app works and what it's doing.
When running the code and debugging, I can see in Xcode's Debug Navigator the various threads that are running. Is there a way of identifying where in the source-code a particular thread was spawned? And is there a way of determining to which NSOperationQueue an NSOperation belongs?
For example, I can see in the Debug Navigator (or by using LLDB's "thread backtrace" command) a thread's stacktrace, but the 'earliest' user code I can view is the overridden (NSOperation*) start method - stepping back earlier in the stack than that just shows the assembly instructions for the framework that invokes that method (e.g. __block_global_6, _dispatch_call_block_and_release and so on).
I've investigated and sought various debugging methods but without success. The nearest I got was the idea of method swizzling, but I don't think that's going to work for, say, queued NSOperation threads. Forgive my vagueness please: I'm aware that having looked as hard as I have, I'm probably asking the wrong question, and probably therefore haven't formed the question quite clearly in my own mind, but I'm asking the community for help!
Thanks
The best I can think of is to put breakpoints on dispatch_async, -[NSOperation init], -[NSOperationQueue addOperation:] and so on. You could configure those breakpoints to log their stacktrace, possibly some other info (like the block's address for dispatch_async, or the address of the queue and operation for addOperation:), and then continue running. You could then look though the logs when you're curious where a particular block came from and see what was invoked and from where. (It would still take some detective work.)
You could also accomplish something similar with dtrace if the breakpoints method is too slow.
I have never seen a real use for checking if a file was closed correctly. I mean, if it didn't close, then what? You have nothing smart to do. Beside, I'm not sure if there's a real world use case, where non of the write/reads/flush will fail, and only the close will.
Does anyone actually uses the return value of close?
From the close(2):
Not checking the return value of close() is a common but nevertheless serious
programming error. It is quite possible that errors on a previous write(2)
operation are first reported at the final close(). Not checking the return
value when closing the file may lead to silent loss of data. This can
especially be observed with NFS and with disk quota.
And if you use signals in your application close may be interrupted (EINTR).
EDIT: That said, I seldom bother unless I'm prepared to handle such cases and write code that has to be 100% fool-proof.
I want to read a byte of memory but don't know if the memory is truly readable or not. You can do it under OS X with the vm_read function and under Windows with ReadProcessMemory or with _try/_catch. Under Linux I believe I can use ptrace, but only if not already being debugged.
FYI the reason I want to do this is I'm writing exception handler program state-dumping code, and it helps the user a lot if the user can see what various memory values are, or for that matter know if they were invalid.
If you don't have to be fast, which is typical in code handling state dump/exception handlers, then you can put your own signal handler in place before the access attempt, and restore it after. Incredibly painful and slow, but it is done.
Another approach is to parse the contents of /dev/proc//maps to build a map of the memory once, then on each access decide whether the address in inside the process or not.
If it were me, I'd try to find something that already does this and re-implement or copy the code directly if licence met my needs. It's painful to write from scratch, and nice to have something that can give support traces with symbol resolution.
I'm really wondering why all source codes that implement a
pthread_mutex_lock never test its return value as defined :
documentation of pthread
even in books the examples don't test if the lock is in error, codes just do the lock.
Is there any reason I missed to let it untested ?
Basically, the only “interesting” error is EINVAL, which in most programs will only happen because of memory corruption, or, as I know from my own painful experience, during program shutdown after destructors have already destroyed some mutexes. The way I see it, the only reasonable response to such an error is to abort the program, which on the other hand is very inconvenient if the errors occur precisely because the program is already shutting down. Of course, this can be solved, but it’s not at all that simple, and not much is gained by it for most programs.
First off, I think "all source code" and "never test" are too strong. I think "some" and "often" would be more accurate.
In books, error checking code is often omitted for clarity of exposition.
As to real-world code, I guess the answer has to be that it is perceived that the likelihood of failure is very low. Whether this is a good assumption is debatable.