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..
hmm....thanks guys....i'll try it out, and let you all know what happens =)
i appreciate your help
i have tried it, and it didn't work.....
i commented out the setclasspriority()
and then i changed all the priorities to normal priority
and it froze.....
i am running an overnight test where i've commented out all the other threads, so that the thread in question is the only one running....we'll see how it goes in the morning.
in the mean time....any suggestions?
Well, what about going for Aculab Prosody instead? ;)Quote:
in the mean time....any suggestions?
Just a tip. When you're logging/tracing to file trying to figure out why/where your system i crashing, remember to flush the file bufferes after every single write. I've been pulling my hair too many times, searching in the wrong places, just bacause the application crashes before the my last 'trace lines' are actually save to disk.
I've got a bad feeling that this has something to do with the hardware, firmware or the drivers.
- petter
I have basic Question.
Do you Create Window during Sleep() ?
In MSDN (Sleep()):
You have to be careful when using Sleep and code that directly or indirectly creates windows. If a thread creates any windows, it must process messages. Message broadcasts are sent to all windows in the system. If you have a thread that uses Sleep with infinite delay, the system will deadlock. Two examples of code that indirectly creates windows are DDE and COM CoInitialize. Therefore, if you have a thread that creates windows, use MsgWaitForMultipleObjects or MsgWaitForMultipleObjectsEx, rather than Sleep.
If you don't create window, I have no Question.
A system-wide freeze, to me, really points to a driver problem - something that's running in kernel mode.. I don't know what a "CAC DPT4 card" is, but who wrote the driver for it?
I guess attaching a kernel debugger to your computer would be the only way to know for sure.
Are you leaking memory? Have you tried executing your application with Bounds Checker to check this?
Also is your application using (allocating) BSTRs that it does not de-allocate? Do you instantiate COM Objects - lots of them, and / or huge ones?
As it seems that your application runs for long, very long stretches of time - leaking lots of memory all night long will exhaust resources and can possibly bring the system to a halt.
nope, not leaking memory....unless the makers of the driver are...how would i check for memory leaks in their code?Quote:
Are you leaking memory? Have you tried executing your application with Bounds Checker to check this?
Also is your application using (allocating) BSTRs that it does not de-allocate? Do you instantiate COM Objects - lots of them, and / or huge ones?
As it seems that your application runs for long, very long stretches of time - leaking lots of memory all night long will exhaust resources and can possibly bring the system to a halt.
i wrote a separate app that just goes through the surveying loop over and over....and it freezes the computer. i am running the same program on a different machine setup, and it hasn't frozen yet....so could it be a problem with the original machines?
i don't know what a BSTR is, so i don't think i am using it.
what's a COM Object? =X
Which means that for every new you are doing a delete and for every new [] you are doing a delete [] ??Quote:
Originally Posted by S Kim
Else, you are leaking memory.
It could be - when I asked you some posts back you said that the freeze was reproducible on many computers. So, perhaps you need to test on a fresh system.Quote:
Originally Posted by S Kim
Also, whilst drivers can leak (why not?!) - they are usually tested over and over again, and usually don't. Use BoundsChecker or a similar utility to check fi your application is not leaking.
Without checking one can't say for sure that your application doesn't leak. A quick-check would be to view the application in Task Manager.
Change to "Processes Tab", and go to -
You should see positive and negative allocations for your application on this column over a period of time. Only positive allocations is an unhealthy sign.Quote:
View --> Select Columns --> Memory Usage Delta
Let us know what the statistics say.
I guess that answer was misleading....it was reproduceable on 3 different machines which had identical hardware setups.Quote:
Originally Posted by Siddhartha
it stays at 0 delta.Quote:
Originally Posted by Siddhartha
the people at CAC offered to try to test it out on some of their own machines...so i sent them the test code...so hopefully some insight will be gained from that.
but once again, in the meantime...any other ideas? =(
Don't know if this will help any, but I had an application that would fail after a long period of time, and it turned out to be resource leaks in a third party driver.
We found it by using the task manager to view the resources used by the application, and found that it wan't releasing handles properly - thus the system ran out of handles. (See taskman.jpg)
We also looked at GDI Objects in the taskmanager, and noticed that GDI resources were also being leaked. (See taskman2.jpg). If your taksman doesn't show the gdi resources, you can turn them on. (Refer to columns.jpg and columnselect.jpg)
All the jpg's are attached.
Hope it might help give you a clue.
Good luck.
hmm....checked the handle thing...and I did notice that i had a "NTService.exe" that was going up a handle about every 5 seconds. I tracked that booger down and uninstalled the app.
however....my application still freezes the computer. =( at least i don't have my handles going up =)
I ran a test last night where I ran the same code, and it hasn't frozen yet!
What was different? I turned off hyper-threading, and changed the boot.ini file to boot with one processor.
Now...this is not a good solution for us, because we want speed...we need multiple processors.
Any ideas on what might be causing the system to freeze in Multiprocessor mode, communicating with a PCI device?
What is "same code"Quote:
Originally Posted by S Kim
The one with which this thread started, or the one with SetPriorityClass commented out, and threads started at default priorities?
well, it's been a while since this thing started, but i thought i should give an update on it.
the problem was in the PCI device that my application was using. we mailed our machine to the company, and they offered to check it out for us.
they said the problem was in mapping memory, unmapping memory, and mapping memory over and over. i'm not much of a device driver guy, so that's as much info i can give.
thanks for all the help though =)