When I run my Windows Application(MFC) I get two Warnings.
First-chance exception at 0x01046a44 in XXX.exe: 0xC0000005: Access violation reading location 0x00000048.
First-chance exception at 0x75fdb9bc (KernelBase.dll) in XXX.exe: 0x000006BA: The RPC server is unavailable.
May I know what they mean?
What is a first chance exception?
When an application is being debugged, the debugger gets notified whenever an exception is encountered. At this point, the application is suspended and the debugger decides how to handle the exception. The first pass through this mechanism is called a "first chance" exception. Depending on the debugger's configuration, it will either resume the application and pass the exception on or it will leave the application suspended and enter debug mode. If the application handles the exception, it continues to run normally.
See this Article for more details.
This error means, that code from ntdll tries to access virtual address 0x00000048, that is not accessible. Maybe you call some function from ntdll and pass invalid pointer as a parameter.
An access violation is where you're trying to read a memory address that isn't yours; given the read address is very low in memory, I would guess that you've got a pointer to a class or struct that is actually null, and your code is attempting to access one of its members.
Related
I am randomly reading files in .NetCore on Linux in Docker. For better speed I have file memory mapped, so actual reading is just Span.CopyTo. But what happens when there is IO failure, whole app will crash, but I would like to catch this error and possibly retry later. On the other hand I want to catch this error only when it happens inside that specific Span.CopyTo, so global SIGSEGV handler cannot just ignore error and continue or at least not always.
Probability of failure is probably higher because it actually runs in Cloud (Azure), and disk is not local (so network failure could result in this crash too).
Application used also ChakraCore and signal handler of ChakraCore broke DotNetCore signal handler for SIGSEGV, which crashed application instead of just throwing AccessViolationException.
NOTE: A question similar to How to handle TIdHTTP fatal network errors without interrupting thread's execution? but handling TADOConnection fatal network errors.
I would greatly appreciate your suggestions on handling fatal network errors raised by TADOConnection inside TThread's Execute procedure.
My app runs a while..do loop inside the Execute procedure. Each loop makes a database update via TADOConnection.Execute(). All loop exceptions are handled at the loop level. There is also an upper level handler of on E: Exception do (level of Execute).
During active network operations a fatal network error occurs on the remote database server. Something went wrong and in the middle of the loop threads report they cannot find path a database server (Named Pipes Provider error, EOleException, etc.) The network gets back within 10 minutes.
I want to make sure that in case of a sudden network death, each thread somehow:
Detects that (well, that's the easiest).
Smokes a joint and waits until the network comes back.
Makes sure the network is up.
Re-establishes connection and restores all network hood.
Continues the loop.
The desired result is to keep the thread up and running and just survive the temporary network problem. The threads must periodically check if the network is back. When it is, the exception handler must restore all ADO hood calling thread's RestoreNetworkConnection and then continue the loop.
What I definitely don't want - is to stop threads' execution.
Questions
Which events/exceptions shall I intercept to handle fatal network errors?
Where to place exception handlers within Execute?
What is correct way of re-establishing connection back to normal state?
My multithreaded delphi application has a VEH exception handler. (http://msdn.microsoft.com/en-us/library/windows/desktop/ms681420(v=vs.85).aspx) i can get memory address, exception type etc when triggered but can't get thread information.
is it possible to get thread id from memory address?
Is it possible to get thread ID from a memory address?
If by memory address you mean address of code then the answer is no. Multiple threads can be simultaneously executing at the same address.
I see no evidence that these exception handlers are called in a thread other than the one which raised the exception.
Nodejs's default behavior is to shut down when an error makes it to the main event loop. The manual strongly recommends not overriding this behavior (for instance, via process.on('uncaughtException).
The explanation given is:
An unhandled exception means your application - and by extension
node.js itself - is in an undefined state. Blindly resuming means
anything could happen.
Think of resuming as pulling the power cord when you are upgrading
your system. Nine out of ten times nothing happens - but the 10th
time, your system is bust.
Can someone elaborate on this? Chrome, which uses the same V8 engine as node, resumes its event loop after an uncaught error by default, and AFAIK this doesn't cause any problems. So it doesn't seem like there's any intrinsic reason that V8 can't recover gracefully from an uncaught exception. Is there something in the node internals that behaves differently than Chrome?
The answer does not have anything to do with the engine's ability to restart itself.
It has to do with your own application code. If an unhandled exception occurs, then there is inherently no way of understanding your application's state. If there were, then it would not have been an unhandled exception. And, if you do not know your state, then you cannot be sure that more unhandled exceptions will not continue to occur, most likely causing worse-and-worse issues as time progresses (as unexpected states cascade into more-and-more unexpected states).
Imagine this as code that is running on the server (as it is not at all specific to node.js):
start process
open two server sockets
process incoming requests
If you were to fail to open the second server socket without handling the exception, then chances are your application will not work. Restarting the thread at the next logical step would likely fail to work properly as well. Restarting the engine could not reasonably close the one socket, and it would be unlikely to fix the cause of the second failure (most likely the port is already in use), and if it did close the successfully opened socket, then it had better restart the application so that it can be reopened (or else it made it worse).
That is perhaps an obvious case, but now imagine that you are a graphics application (e.g., a game):
start process
load models
handle state (until closing)
draw screen
If any model failed to load without exception handling, then the process cannot reasonably continue because it will simply cause more errors while drawing.
There are cases where recovering from unhandled exceptions is reasonable. In most client side GUI frameworks there is a way to register for unhandled exceptions, which allows the restarting of the event thread (GUI thread), analogous to Chrome's V8 recovery. It is dangerous because recovery is not guaranteed; whatever caused the unhandled exception could still be in memory and ready to cause the exception again on the next usage of it. However, it's also possible that a well developed application can be small enough to wipe itself clean given such exceptions. The best use of such handlers (handling of unhandled exceptions) is to log the exception so that the issue can be fixed.
To put it differently: imagine an exception occurs that you did not handle in your application anywhere. What can you do to fix it so that it does not happen on the very next pass of the code? To safely answer that implies that you know what caused it, which means that A) it should not be unhandled and B) it is isolated.
The only guaranteed safe reset is to start from the very beginning, which means to restart the application.
I have read so far that on an uncaught exception it is best to restart the node.js server. However my concern is that for example when multiple users are using the same node.js server and an exception is thrown for one user's request the server would shutdown thus ending whatever processes was taking place for other users. An example would be when one user is in the middle of a critical transaction an uncaught exception is thrown for another user thus stopping the server and having the transaction incomplete and not rolled back somehow even.
In this case considering multiple users what is the best way/practice of handling exceptions
Regards,
MilindaD
process on uncaught exception does not restart the server, it allows Node to continue execution, so the other users will continue any transaction or handling as if nothing happened. Be careful with this method, though, you may use it but the code will be in an unknown state and it will continue execution from where it threw the error.