This is the mail archive of the
cygwin
mailing list for the Cygwin project.
RE: cygwin 1.5.20-1, spinning pdksh, 100% CPU
> -----Original Message-----
> From: Igor Peshansky [mailto:pechtcha@cs.nyu.edu]
> > Here's a stack trace of the thread where the spin is occurring. The
> > other threads in the process are quiet - the signal thread is is
> > ReadFile as expected, and the other threads are all in stub routines
> > doing WaitForSingleObject.
> >
> > (gdb) bt
> > #0 handle_sigsuspend (tempmask=0)
> > at ../../../../src/winsup/cygwin/exceptions.cc:694
> > #1 0x61094b93 in sigsuspend (set=0x42db80)
> > at ../../../../src/winsup/cygwin/signal.cc:477
> > #2 0x610917b8 in _sigfe () at
> > ../../../../src/winsup/cygwin/cygserver.h:82
> > #3 0x0022c588 in ?? ()
> > #4 0x600301dc in ?? ()
> ^^^^^^^^^^
> This frame is suspicious. It's some sort of a DLL, but not
> Cygwin1.dll.
> Can you use Process Explorer or something to find out what DLL is
> loaded
> in that range? It might be something injected by an
antivirus/firewall
> on
> the list of dodgy apps...
>
> > #5 0x006854d8 in ?? ()
> > #6 0x00000003 in ?? ()
> > #7 0x0022c588 in ?? ()
> > #8 0x006874b8 in ?? ()
> > #9 0x006854d8 in ?? ()
> > #10 0x00000003 in ?? ()
> > #11 0x0022c5a8 in ?? ()
> > #12 0x004126e0 in waitlast () at ../src/jobs.c:729
> > #13 0x004126e0 in waitlast () at ../src/jobs.c:729
> > #14 0x0040b160 in expand (
> > cp=0x6874b8
> >
>
"\001R\001M\001T\001I\001N\001S\001R\001E\001A\001S\001O\001N\001=\003$
> L
> > KBIN/ins_list -d \"$EQVRMTSYS\" -t \"$EQVRMTTAG\" 2>NUL: | cut
-d\001
> > -f8", wp=0x22c6b0, f=32) at ../src/eval.c:533
> > #15 0x0040a654 in evalstr (
> > cp=0x6874b8
> >
>
"\001R\001M\001T\001I\001N\001S\001R\001E\001A\001S\001O\001N\001=\003$
> L
> > KBIN/ins_list -d \"$EQVRMTSYS\" -t \"$EQVRMTTAG\" 2>NUL: | cut
-d\001
> > -f8", f=32) at ../src/eval.c:113
> > #16 0x0040d80a in comexec (t=0x6871e0, tp=0x0, ap=0x687350, flags=0)
> > at ../src/exec.c:555
> > #17 0x0040cc7d in execute (t=0x6871e0, flags=0) at ../src/exec.c:155
> > #18 0x0040ce39 in execute (t=0x687778, flags=0) at ../src/exec.c:192
> > #19 0x0040d311 in execute (t=0x686620, flags=1) at ../src/exec.c:367
> > #20 0x004124c1 in exchild (t=0x686620, flags=74, close_fd=0)
> > at ../src/jobs.c:641
> > #21 0x0040cdf6 in execute (t=0x686620, flags=10) at
../src/exec.c:185
> > #22 0x0040ce62 in execute (t=0x688470, flags=0) at ../src/exec.c:195
> > #23 0x0040d311 in execute (t=0x684ee0, flags=0) at ../src/exec.c:367
> > #24 0x0041766e in shell (s=0x6839b8, toplevel=1) at
../src/main.c:616
> > #25 0x00417204 in main (argc=6, argv=0x61171f74) at
../src/main.c:429
> >
> > Please let me know if there's any other information that would be
> > useful. Thanks!
>
> It would also be nice to find out what static library is linked into
> the
> 0x0022XXXX space...
> Igor
I'm not sure how gdb does backtrace across _sigfe and _sigbe - I think
there's some "stack magic" that happens in these routines. The bt
output doesn't make sense to me between entries #3 and #11. I'm pretty
sure that these addresses are invalid - for instance 22c588 is a stack
location on this thread, and "3" is obviously not a function address.
The addresses don't match up with any loaded DLL's:
(gdb) info dll
DLL Name Load Address
/cygdrive/c/WINDOWS/system32/ntdll.dll 7c801000
/cygdrive/c/WINDOWS/system32/kernel32.dll 77e41000
/bin/cygwin1.dll 61001000
/cygdrive/c/WINDOWS/system32/advapi32.dll 77f51000
/cygdrive/c/WINDOWS/system32/rpcrt4.dll 77c51000
/cygdrive/c/WINDOWS/system32/secur32.dll 76f51000
/cygdrive/c/WINDOWS/system32/psapi.dll 76b71000
/cygdrive/c/WINDOWS/system32/winmm.dll 76aa1000
/cygdrive/c/WINDOWS/system32/user32.dll 77381000
/cygdrive/c/WINDOWS/system32/gdi32.dll 77c01000
/cygdrive/c/WINDOWS/system32/imm32.dll 76291000
/cygdrive/c/WINDOWS/system32/lpk.dll 7f001000
/cygdrive/c/WINDOWS/system32/usp10.dll 75491000
/cygdrive/c/WINDOWS/system32/rdpsnd.dll 71bc1000
/cygdrive/c/WINDOWS/system32/winsta.dll 771f1000
/cygdrive/c/WINDOWS/system32/msvcrt.dll 77ba1000
/cygdrive/c/WINDOWS/system32/netapi32.dll 71c41000
The stack itself looks pretty nice - you can trace straight back from
cancelable_wait down into pdksh code (%ebp is 0x22c518):
0x22c518: 0x0022c548 0x61017667 0x00000000
0x600301dc
0x22c528: 0x61117610 0x61117630 0x00000000
0x00000000
0x22c538: 0x0022c568 0x006874b8 0x006842a0
0x00000004
0x22c548: 0x0022c558 0x61094b93 0x00000000
0x006874b8
0x22c558: 0x0022c588 0x610917b8 0x0042db80
0x0068b3f0
0x22c568: 0x0022c588 0x600301dc 0x006854d8
0x00000003
0x22c578: 0x0022c588 0x006874b8 0x006854d8
0x00000003
0x22c588: 0x0022c5a8 0x004126e0 0x006842a0
0x00000000
0x22c598: 0x0042972b 0x006874b8 0x00000000
0x006874b8
0x22c5a8: 0x0022c698 0x0040b160 0x0068b3f0
0x00000000
0x22c5b8: 0x0068a614 0x00000001 0x0022c680
0x00000019
0x22c5c8: 0x0068bbe8 0x00000000 0x61171d44
0x00680000
0x22c5d8: 0x00000000 0xffffffff 0x61171dd4
0x00000001
0x22c5e8: 0x00000000 0x00000000 0x00000001
0x00000000
0x22c5f8: 0x0022c640 0x00000000 0x00000000
0x00000000
0x22c608: 0x00687518 0x00000000 0x00000004
0x00685470
0x22c618: 0x0068ad98 0x00000000 0x00000001
0x61104ab4
0x22c628: 0x00000003 0x00000001 0x00000668
0x0068a614
0x22c638: 0x00685478 0x610564f7 0x0068ad98
0x006854bc
0x22c648: 0x00000001 0x0068ad60 0x0068ad60
0x00000000
0x22c658: 0x00685ae0 0x00000001 0x00000000
0x0068b3f0
0x22c668: 0x0022c698 0x00400001 0x00685530
0x006854b0
0x22c678: 0x00000080 0x0068a614 0x00000001
0x006854bc
0x22c688: 0x000000cb 0x006874b8 0x00000000
0x00687350
0x22c698: 0x0022c6c8 0x0040a654 0x006874b8
0x0022c6b0
0x22c6a8: 0x00000020 0x6105642c 0x00685498
0x00685498
0x22c6b8: 0x0068549c 0x0000001d 0x00000000
0x00000000
0x22c6c8: 0x0022c718 0x0040d80a 0x006874b8
0x00000020
0x22c6d8: 0x0068a610 0x00000000 0x0000001d
0x00000000
Ernie Coskrey
SteelEye Technology, Inc.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/