I have a non-managed c++ service that has a crash periodically.
I analyze the DrWatson dump and every time it seems to point to a
ntdll!RtlInitializeCriticalSectionAndSpinCount. I do use
CRITICAL_SECTIONS often throughout the code to manage access to the
variables, since it's a multi-threaded app.
Is there a certain rule of thumb when using Critical Sections to avoid
this ? I saw in MSDN they say to call
InitializeCriticalSectionAndSpinCount instead of just
InitializeCriticalSection in order to avoid memory resource exceptions
on pre-windows-XP systems... but our clients are XP, so I think i'm ok
with using InitializeCriticalSection. Maybe there's something more
recommended to use ?
In my searches, i'm seen some references to stack overflows... i'm not
too familiar with how to avoid it ? can someone offer some
guidance ? I know we use some string variables that can hold a few MB
of xml data... usually they are declared as an STL "string" and passed
as references. Do I need to use 'new' to allocate these large vars ?
does that avoid using the stack ?!?
Re: Need Help Debugging ... Is there a certain rule of thumb when using Critical Sections to avoid...InitializeCriticalSection in order to avoid memory resource exceptions ... i'm seen some references to stack overflows...... I know we use some string variables that can hold a few MB ... (microsoft.public.win32.programmer.kernel)
Re: Need Help Debugging ... Is there a certain rule of thumb when using Critical Sections to avoid...InitializeCriticalSection in order to avoid memory resource exceptions ... If you want to monitor you system calls or internal functions call, you can use an API monitor software like WinAPIOverride32 ... Next if you think it can come from a heap allocation error you can try to increase your software heap size ... (microsoft.public.win32.programmer.kernel)
Re: Any plans to remove obsolescent features? ... I'm not saying that adding some code to avoid undefined behaviour is a bad idea and a waste of time. ... you shouldn't waste time worrying about - though I wouldn't certainly be interested in a language, or at least a language feature, which provided some method of anticipate and cope with running out of stack.... If I'm writing a program that I intend to only run myself, then letting that program invoke undefined behaviour for invalid inputs may also be reasonable -- especially if I'll only run the program while debugging other programs, and the risk of undefined behaviour of this program is likely to be negligible compared to undefined behaviour of the program being debugged. ... On the other hand, telling a customer that invalid input can make my program damage his hard drive, just because the requirements he specified did not mention anything about invalid inputs, would be much less acceptable than spending some extra time adding code to try to be reasonably sure that the program doesn't run into undefined behaviour. ... (comp.std.c)
Re: hmmm ... > My main point is that she could have avoid this mess where the two big stacks ... >> Surely the most likely is a small/med pair?... >> to that...so why risk it all against another big stack?... (rec.gambling.poker)
Re: [1/3] kprobes-func-args-268-rc3.patch ... >> traps again to restore processor state and switch back to the ... >> stack bytes to cover argument space. ... So I was looking for ways to avoid that ... ... > That's all quite hackish and compiler dependent.... (Linux-Kernel)
