Printable View
I was wondering if there would ever be a case where the entire computer freezes during a call to Sleep().
My machine would freeze, and I would have to do a hard shutdown and restart the computer to use it again. I have been using filestream logs to see where the freeze occurs, and it looks like it's during a Sleep() call with 100 milliseconds as the argument.
Any help? thanks
ps. using Windows XP on a dual Xeon processor machine with 2 gb ram
Sleep when used correctly cannot cause this problem.
So, please do the following -
- Post code (use code tags) centered in and around the Sleep statement.
- Tell us if you observe this behaviour while debugging, or in the normal execution of your application.
- Briefly explain what your application does.
- The intention of the code in and around the Sleep.
Is yours a multithreaded program ?
Well, to answer the easy question, my application is multi-threaded.
My Sleep() call is used amidst a bunch of API calls to a CAC DPT4 card, which reads and writes data from E1 or T1 lines. I don't know if anyone would be familiar with it...but basically,
my application is opening up a port on the card, sleeping for 100 milliseconds, trying to get a sync on the data coming in through the card, and then closing it if it doesn't get a sync. through file logs, it seems like the machine always freezes during the Sleep() call. I observe this behavior in both debug and release modes. It goes through this cycle of functions calls every second. so every second, it is opening a port, sleeping for 100 ms, and trying to get a sync, and then closing.
one thing i noticed during my debugging session was that about 5 other threads are in a WaitForSingleObject() call with a 1000ms timeout time.
any help? thanks.
Well... You haven't answered the other simple question - do you face this system freeze problem only when debugging or also when the release mode version of your application is executed independently?
oops sorry
the answer is both. it freezes in debug and release modes
I presume you also means that you experience the system-wide freeze when the application is executed from Start --> Run?
All right, now please answer the new set of quick questions... :)
Its normal for Multithreaded applications to freeze the system when being debugged for some time. But, its certainly not normal that when run independently, the system doesn't respond to CTRL + ALT + DEL - and this happens on every run of your application.
- CTRL + ALT + DEL doesn't work? Not even if given some time?
- Does your application increase it's priority at any instant using SetPriorityClass?
- Are any of the threads in an infinite loop, and get a dominant CPU share?
- Does the HDD flicker when the PC is in this hung state?
- Are you able to reproduce this problem on other computers?
alright mr. siddartha, here are my quick answers
1. CTRL + ALT + DEL doesn't work? Not even if given some time?
nope. totally hung....no responses whatsoever.
2. Does your application increase it's priority at any instant using SetPriorityClass?
well, the currently running thread is started with above normal priority, but the priority does not change anywhere in the code.
3. Are any of the threads in an infinite loop, and get a dominant CPU share?
all the threads are in an infinite loop i think....but no, none of them get dominant CPU share. mostly in a waitforsingleobject() or sleep() method
4. Does the HDD flicker when the PC is in this hung state?
nopenope
5. Are you able to reproduce this problem on other computers?
yupyup. same exact thing on all 3 computers.
so no one has ever heard of a machine freezing during a Sleep() command? well, i never heard of it till now either....
If it is reproducible every single time, you are at luck. The more dangerous ones are the ones that only happen on a customer trying to do something in a place deep in the Sahara ;)
Have you done a code review to see if there is a possibility of a deadlock somewhere ?
Also, is it possibel for you to strip it down to bare minimum and get the same issue ?
"If it is reproducible every single time, you are at luck. The more dangerous ones are the ones that only happen on a customer trying to do something in a place deep in the Sahara"
that's encouraging...i guess =)
"Have you done a code review to see if there is a possibility of a deadlock somewhere ?"
well, this is not my code...i've been assigned to investigate a freezing problem. and i've narrowed it down to this. deadlock...i don't believe there are any deadlock situations. even if it were a deadlock, would it hang up the entire computer?
"Also, is it possibel for you to strip it down to bare minimum and get the same issue ?"
it has been stripped down. before, it was doing other things...but i've commented out everything so that only this functionality is running....that is, on this thread. i don't know what the other 5 or 6 threads are doing...
BTW, as you are new to CG - I must let you know that one can use Quote Tags and Code Tags.
See, here is me using QUOTE tags, below -
Can you check what happens when all threads are started with default priorities?Quote:
Originally Posted by S Kim
Do nothing non-default.
It wouldn't -A normal Win 32 application wouldn't.Quote:
Originally Posted by S Kim
Neither do we... :)Quote:
Originally Posted by S Kim
To rule out any issues with multithreading.. some questions:Quote:
Originally Posted by S Kim
- If you create a single threaded sample app that does the same thing as above, do you see the issue ?
- If so, if you remove any interactions with the card whatsoever, do you see the issue still?
alright, i changed the priorities on all the threads...
seemed like some were above normal, others normal, and others below normal....
but anyway, it sometimes takes up to an hour for a freeze...so i'll let you know when it happens.
additionally, i found that when int main() starts, almost immediately, it calls SetPriorityClass to HIGH_PRIORITY_CLASS
Bullseye, I had guessed it right!Quote:
Originally Posted by S Kim
Comment that line out... It is most certainly wrong in almost every case. ;)
The reason why this is a poor practise is that with your Process Set on a High Priority Class, and some threads set on a high priority, Windows tends to share an exhorbitant amount of processor time on your application, and those threads in particular.
So, in certain cases, the OS itself hasn't given some critical processes the time to say flush buffers, etc.
Hence, you faced the "System Wide Freeze".
Under default settings, this is very unlikely. Don't tamper with Process Priority, and if you do so, do it for a short interval, and reset it immediately when done with that precious task.
Yep.. changing thread priorities is to be avoided as much as possible. Let windows do all that for you..