Skip to main content
GameDev.net gamedev.net
🔒 Locked

Recoverable run time errors

Started by orryx Jul 30, 2006 at 7:19 PM 7 replies 750+ views
Original Post
orryx
orryx
In my program I have a function which takes in a package from the network and does things with it depending on the package type. The program crashes because of some crazy behavior. While running it through the debugger I watched it successfully run through the part of the function where it crashes twice (it received 2 packets successfully) and on the 3rd the debugger stops with: "Unhandled exception at 0x(some memory address)... user break point" but at this point I can click "continue" and the program will still run for a few more lines before screwing up some data and crashing while trying to delete it. So first off, what are some errors that are recoverable like that? If I run the program without the debugger it doesn't stop at the first break, and crashes when trying to delete the corrupt data. Note that the 2nd crash when it tries to delete the corrupt data isn't recoverable. And secondly, why is the data being corrupted afterwards? Heck, why is the program even complaining about the recoverable error? After the recoverable error the data is read from the package just fine, everything is well until it calls a function with the data (which DOESN'T change the data) and then the data comes back corrupted from the function. Very strange stuff. Update: I commented out the part where it calls the function with the data and the program runs through fine. I examined the function completely and i'm sure none of the data is changed. Actually the only data that changes is a char * (yes yes I know, use the string class..... but thats not the point) The address that the char* is pointing to doesn't change but the data does. And the most likely cause of all this: The function called is inside a dll. It is called from the main program. I've had people tell me that this can screw things up. [Edited by - orryx on July 30, 2006 7:36:27 PM]
dawidjoubert
dawidjoubert
Quote:
Original post by orryx
In my program I have a function which takes in a package from the network and does things with it depending on the package type. The program crashes because of some crazy behavior. While running it through the debugger I watched it successfully run through the part of the function where it crashes twice (it received 2 packets successfully) and on the 3rd the debugger stops with: "Unhandled exception at 0x(some memory address)... user break point" but at this point I can click "continue" and the program will still run for a few more lines before screwing up some data and crashing while trying to delete it.

So first off, what are some errors that are recoverable like that? If I run the program without the debugger it doesn't stop at the first break, and crashes when trying to delete the corrupt data. Note that the 2nd crash when it tries to delete the corrupt data isn't recoverable.

And secondly, why is the data being corrupted afterwards? Heck, why is the program even complaining about the recoverable error? After the recoverable error the data is read from the package just fine, everything is well until it calls a function with the data (which DOESN'T change the data) and then the data comes back corrupted from the function. Very strange stuff.


I dont know but if you are accessing stray date with a broken pointer errors can hide in the memory until a specific thing happens (like msn gets out of sleep mode muhahahahaa)

----------------------------http://djoubert.co.uk
Thevenin
Thevenin
I recently corrected a very VERY awful packet error caused by my TCP buffer being too small. The debugger told me nothing about the buffer size, and would just randomly throw an error at me that had nothing to do with the error's source.

Please tell me you've checked the size of your TCP buffer, and ensured that the volley of packets coming in arn't overflowing it.
mattnewport
mattnewport
A user breakpoint is usually the result of a failed assert somewhere. You should be able to see what the assert is and where it's happening from the callstack if you hit break when the unhandled exception dialog pops up. The assert is quite likely related to the crash you see later - it's probably asserting that some buffer isn't being overflowed or something.
orryx
orryx
Quote:
Original post by Thevenin
I recently corrected a very VERY awful packet error caused by my TCP buffer being too small. The debugger told me nothing about the buffer size, and would just randomly throw an error at me that had nothing to do with the error's source.

Please tell me you've checked the size of your TCP buffer, and ensured that the volley of packets coming in arn't overflowing it.


Nope, my network code copies the packets into a queue and then the function causing the problems reads through the queue and handles each one. The packet recieved from the net is discarded.
Thevenin
Thevenin
Quote:
Original post by orryx
Nope, my network code copies the packets into a queue and then the function causing the problems reads through the queue and handles each one. The packet recieved from the net is discarded.


Awesome, good. I'll sleep better tonight knowing your not about to go through what I went though (Or atleast, not exactly). Good luck solving this one. [razz]
orryx
orryx
Quote:
Original post by mattnewport
A user breakpoint is usually the result of a failed assert somewhere. You should be able to see what the assert is and where it's happening from the callstack if you hit break when the unhandled exception dialog pops up. The assert is quite likely related to the crash you see later - it's probably asserting that some buffer isn't being overflowed or something.


If I hit break and look at the call stack each one is from ntdll32.dll all the way down the stack, and they're all asm code, so nothing I can read...
orryx
orryx
Alright so going paranoid about the whole dlls causing the problem thing, I threw all the files together into the executable project, so no dlls were used, and the project still crashed at that same point with the same problems. There is still 2 dlls being used, SDL.dll and SDL_net.dll, does anyone know any issues with these? I'm using sdl for my network code.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.