|
|
| Re: Max Deadlock Obtained (473151) | |||
 |
|||
| Home > SubChat | |||
|
[ Read Responses | Post a New Response | Return to the Index ] |
|
||
|
Re: Max Deadlock Obtained |
|
|
Posted by JohnL on Tue Aug 7 23:31:39 2007, in response to Re: Max Deadlock Obtained, posted by SelkirkTMO on Tue Aug 7 23:15:52 2007. Blue screens in NT progreny are indeed rare and almost always the result of a badly written driver clobbering another one or just plain walking off the plank. In kernel mode, the kernel itself doesn't manage memory and you have to be PERFECT in doing so in your own code. I write code for a living.Anything that runs for the life of the operating system has to be perfect. If it leaks memory, the OS will die. I haven’t written this sort of code for Windows, but I have written similar sort of code for MVS (and its successors) where my memory footprint had to be the bare minimum because the code and data areas were locked down (since they were executed as part of interrupt service code and couldn’t be paged in). Any memory I used was thus unavailable for normal programs paging. "Illegal operation" is an interesting one because here, it CAN be the fault of the code, but more often than not it really is windows unless it happens at the same place every time in a proggie. Here's what goes on behind the scenes since most of them are 0x00000005 errors, or "buffer overflow." A program is merrily going along until it uses up a block of memory and needs some more. At this point, windows will "raise an exception" to which the kernel is supposed to jump in an "page in" more memory and page out the old memory which is still in use (also known as a "swap"). The FIRST exception call usually will swap in the memory but if windows can't find it, it becomes an "unhandled exception." The program can EXPECT this and try the call again but more often than not, windows will not find more space the second time it's asked to and up comes "Illegal operation" when the kernel is at fault. OMG! Is this really Windows’ memory management model? You use memory until it runs out when you may be able to handle the error? Again the MVS model: although you had a 2GB address space, you couldn’t use any block of memory unless you had requested it from the OS. And the OS limited how much you could request (based on parameters specified for the job) so that an errant program couldn’t run away with all the backing store for virtual memory on the machine). XP and Vista are even MORE scrooched in that they've added another layer of "rotsa ruck." It's called "not responding" and is definitely windows being hosed. Here, windows now pings a running program every x amount of seconds. If you TOUCH it while it's busy in an uninterruptable thread (heavy calcs) then windows will pop up a "not responding" making you think the proggie's died (sometimes it really has) when it actually hasn't. This is more of a “get the program model right” issue. If you have a program that does heavy calculations, then put them in a separate thread so that there is something left to handle the inevitable window manager messages (even if all you do is paint “update in progress xx% complete” on the window pane). However the error “recovery” you specify is bizarre. But not so surprising! |
|
|
|