Cygwin's bash became extremely slow after errors

I realize there are a few other questions about why Cygwin is apparently slow, but this case seems to be unique.

I had some issues where things were reporting lots of errors, and then after a reboot any process launched from bash is extremely slow. I honestly have no idea what could be causing this (I checked the process priority in taskmgr; it's still normal).

Details:

I was running a soak test of some socket code overnight and came back in the morning to find my screen flooded with errors (DialogBoxes - mostly attempted to access NULL pointers) as well as quite a few things sent to the command line. There was quite a bit of text I wasn't able to capture (the computer was mostly unresponsive; I had to reboot it manually). I do remember some of the text referenced "Win32 error 6" (which I assume means INVALID HANDLE).

After the reboot, most things are fine, but Cygwin/bash is still pretty unresponsive. I ran the following, as suggested in another question:

$ time for i in {1..10} ; do bash -c "echo Hello" ; done
...
real    1m12.244s
user    0m3.522s
sys     0m34.460s

Invoking another bash instance isn't necessary for the terrible speed:

$ time for i in {1..10}; do ls ; done    
# nb there are about 6 entries in pwd
....
real    0m47.718s
user    0m2.568s
sys     0m23.411s

Although builtins do seem to go quickly enough:

$ time for i in {1..10} ; do echo Hello ; done
....
real    0m0.001s
user    0m0.000s
sys     0m0.000s

Update: I just realized a Windows Update installed between then and now, too. I'm glad this isn't getting too complicated or anything. (Although, I believe other coworkers have installed the update and aren't seeing problems).

Update 2:

To answer a comment below, the files in /bin execute without any problems from CMD. Also, I completely removed and re-downloaded my cygwin installation directory and the problem is still occurring.

I'm [still] not entirely sure how to use Cygwin's strace, but I think the first column may be time delta. With that in mind, here's a few lines that look problematic (the 0xDEADBEEF is certainly not encouraging):

4100175 4101564 [main] bash 5664 _cygtls::remove: wait 0xFFFFFFFF
4278898 4279724 [main] bash 5612 child_copy: dll bss - hp 0x628 low 0x611DC000, high 0x612108D0, res 1
2210923 25635973 [proc_waiter] bash 5664 pinfo::maybe_set_exit_code_from_windows: pid 5400, exit value - old 0x8000000, windows 0xDEADBEEF, cygwin 0x8000000
3595425 16085618 [proc_waiter] bash 5612 pinfo::maybe_set_exit_code_from_windows: pid 5376, exit value - old 0x8000000, windows 0xDEADBEEF, cygwin 0x8000000
3057452 19149209 [proc_waiter] bash 5664 pinfo::maybe_set_exit_code_from_windows: pid 5612, exit value - old 0x8000000, windows 0xDEADBEEF, cygwin 0x8000000
2631997 38835042 [proc_waiter] bash 5716 pinfo::maybe_set_exit_code_from_windows: pid 5720, exit value - old 0x8000000, windows 0xDEADBEEF, cygwin 0x8000000
2610852 38836658 [main] bash 4624 _cygtls::remove: wait 0xFFFFFFFF
3708283 42556365 [proc_waiter] bash 5716 pinfo::maybe_set_exit_code_from_windows: pid 4624, exit value - old 0x8000000, windows 0xDEADBEEF, cygwin 0x8000000
3666884 42562053 [main] bash 5664 fhandler_base_overlapped::wait_overlapped: GetOverLappedResult failed, bytes 0
2742397 45305871 [proc_waiter] bash 5664 pinfo::maybe_set_exit_code_from_windows: pid 5716, exit value - old 0x8000000, windows 0xDEADB开发者_Go百科EEF, cygwin 0x8000000
45322195 45322997 [main] bash 3996 child_copy: dll bss - hp 0x62C low 0x611DC000, high 0x612108D0, res 1
4247577 49581019 [main] bash 3996 _cygtls::remove: wait 0xFFFFFFFF
4266690 49581325 [main] bash 5664 child_info::sync: pid 3996, WFMO returned 0, res 1
49622099 49623318 [main] bash 4840 child_copy: dll bss - hp 0x690 low 0x611DC000, high 0x612108D0, res 1
4225718 53860809 [main] bash 4840 _cygtls::remove: wait 0xFFFFFFFF
4248491 53861119 [main] bash 3996 child_info::sync: pid 4840, WFMO returned 0, res 1
2167422 2169463 [main] bash 1412 _cygtls::remove: wait 0xFFFFFFFF
10369 2205831 [main] bash 1412 pwdgrp::load: \etc\passwd curr_lines 4082
10313 2237148 [main] bash 1412 cygwin_gethostname: name A119894
14720 2251868 [main] bash 1412 stat64: entering

I had a similar problem, fixed by removing disconnected network shares.

http://cygwin.com/faq/faq-nochunks.html#faq.using.slow
http://cygwin.com/ml/cygwin/2010-06/msg00510.html (read all replies)

You can look into this as well:

http://cygwin.com/acronyms/#BLODA

gl

I have little experience with this, but I can at least give you my opinion on what it looks like.

I'm seeing lots of [proc_wiater] lines, each at over 5000 ... that's longer than your actual directory listing takes :/ Looks like the problem here is "ls is a program". I bet if you timed dir you'd not notice such a ridiculous time.

-Someone who knows nothing of strace.

It creates a dirty log file, use awk.

So I never actually solved this. Got a new computer instead.

Similar problem cropped up there eventually, and the problem was the NVIDIA driver software--not the actual drivers themselves.

So, the path was:

• Install NDIVIA Drivers
• Remove NVIDIA Software from AppWiz.cpl
• Use Hardware Manager to find the .inf files that were left around