Re: Cygserver 100% CPU (was: References to both cygwin1.dll and msvcrt.dl
On Oct 1 07:24, Patrick Samson wrote: --- Corinna Vinschen wrote: On Sep 30 23:41, Patrick Samson wrote: Now, when it's wrong, I can see: good morning (error=4)! Error 4 is EINTR on the return of msleep(). Subsequently semop() returns with this EINTR. Are you set up to build cygwin? If so, could you please test the following patch to cygserver and if it changes anything for you? Same behaviour. As soon as there are some error=4, it will hang. On service stop, postgres may stop some of its backends, but not all of them, and stay in 'Stopping' state. I'm still hoping for a simple testcase... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:[EMAIL PROTECTED] Red Hat, 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/
Re: Cygserver 100% CPU (was: References to both cygwin1.dll and msvcrt.dl
--- Corinna Vinschen wrote: On Oct 1 07:24, Patrick Samson wrote: --- Corinna Vinschen wrote: On Sep 30 23:41, Patrick Samson wrote: Now, when it's wrong, I can see: good morning (error=4)! Error 4 is EINTR on the return of msleep(). Subsequently semop() returns with this EINTR. Are you set up to build cygwin? If so, could you please test the following patch to cygserver and if it changes anything for you? Same behaviour. As soon as there are some error=4, it will hang. On service stop, postgres may stop some of its backends, but not all of them, and stay in 'Stopping' state. I'm still hoping for a simple testcase... I'm still working on it (the problem, not the testcase, as it is probably a race condition). I'm looking at traces from cygserver.log. I found something strange. We may not focus too much on error=4. For each EINTR the semop() is called again and all is back to sleep. Even before the first error=4, the last op=1 is supposed to wake up all sem[] of the semid. But I could see that: sem 1 is never mentioned anywhere (?, but why not) sem 0, 10 are not in sleeping state, OK sem 2,3,4,5,6,7,8,9,10,12,14,15 are waked up, and set back to sleep, OK sem 11 and 13 ARE MISSING ! Why aren't 11 and 13 waked up? Because there were not put in a good state of sleeping? Hum... Look at the attached extract. You will see that inside the semop() for sem[11], the trace output is suspended and during that time 3 other semop() arrived, and even 1 more just after. So 4 calls are waiting for mutex semid at the same time. Operations for sem 9, 14, 2, 15 seem to be OK as they are well bound between Locked/Unlocked. But NOT for 13, for which the Unlocked seems to appear after the end of sem 15. The first Unlocked should be the one for putting sem 11 to sleep, but many things may have arrived before to reach the WaitForMultipleObjects(). So I suspect that something is corrupted in regard with the Event to wait for. Note: when everything was stopped, sem 11 was able to return from sleeping with EINTR. No trace for sem 13. But reminder that some processes, but all, were able to stop correctly. ___ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com cygserver9.log Description: cygserver9.log -- 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/
Re: Cygserver 100% CPU (was: References to both cygwin1.dll and msvcrt.dl
On Oct 4 07:02, Patrick Samson wrote: --- Corinna Vinschen wrote: I'm still hoping for a simple testcase... I'm still working on it (the problem, not the testcase, as it is probably a race condition). Too bad. I've checked in a patch to cygserver a few minutes ago. Since you're set up for building your own version, please try that one. It adds a tiny bit of debug output which might be interesting. I don't think it will solve the problem, though. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:[EMAIL PROTECTED] Red Hat, 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/
Re: Cygserver 100% CPU (was: References to both cygwin1.dll and msvcrt.dl
--- Corinna Vinschen wrote: On Sep 30 00:12, Patrick Samson wrote: I built the DLL another way, and now have: $ cygcheck ./dp40.dll .\dp40.dll D:\cygwin\bin\cygwin1.dll C:\WINNT\System32\ADVAPI32.DLL C:\WINNT\System32\ntdll.dll C:\WINNT\System32\KERNEL32.dll C:\WINNT\System32\USER32.dll C:\WINNT\System32\GDI32.dll C:\WINNT\System32\RPCRT4.dll D:\cygwin\bin\tcl84.dll C:\WINNT\System32\WS2_32.DLL C:\WINNT\System32\MSVCRT.dll --- C:\WINNT\System32\WS2HELP.dll Seems better, as msvcrt.dll is only there because of ws2_32 (winsock2). Which shouldn't be referenced at all. dp40.dll apparently references ws2_32.dll directly instead of using the Cygwin socket calls. There is the link command generated by autotools: gcc -mwin32 -g -O2 -o dp40.dll -shared -Wl,--export-all-symbols -Wl,-s dpChan.o dpCmds.o dpRPC.o dpPlugF.o dpFilte rs.o dpIdentity.o dpPackOff.o dpInit.o dpSerial.o dpSock.o dpWinInit.o dpWinSerial.o dpWinSock.o dpWinTcp.o dpWinUD P.o dpWinIPM.o -ltcl84 -lws2_32 If I omit -lws2_32, I receive undefined reference for winsock functions (one of the source has #include ws2tcpip.h for IP multicast). What should I do? __ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail -- 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/
Re: Cygserver 100% CPU (was: References to both cygwin1.dll and msvcrt.dl
--- Patrick Samson wrote:
With the third condition (pgAdmin) everything was
fine the whole night. And there is only 4
good night! messages in the middle of the night.
I guess this is because of one of the cron tasks
scheduled around 3AM to do maintenance tasks such
as VACUUM, pg_dumpall and a diff between replicated
DBs. These are also 4 good morning with error=0.
Now, when it's wrong, I can see:
good morning (error=4)!
Error 4 is EINTR on the return of msleep().
Subsequently semop() returns with this EINTR.
Does it mean that the caller doesn't support
correctly this interrupted call to semop()?
Back to source...
The caller code seems to be:
/*
* Note: if errStatus is -1 and errno == EINTR then it
means we
* returned from the operation prematurely because we
were sent a
* signal. So we try and lock the semaphore again.
*/
do
{
errStatus = semop(sema-semId, sops, 1);
} while (errStatus 0 errno == EINTR);
I don't understand. If semop() returns EINTR (value 4)
how can it be detected by the 'while'?
__
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail
--
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/
Re: Cygserver 100% CPU (was: References to both cygwin1.dll and msvcrt.dl
On Sep 30 23:41, Patrick Samson wrote:
Now, when it's wrong, I can see:
good morning (error=4)!
Error 4 is EINTR on the return of msleep().
Subsequently semop() returns with this EINTR.
Are you set up to build cygwin? If so, could you please test the
following patch to cygserver and if it changes anything for you?
Thanks,
Corinna
Index: winsup/cygserver/sysv_sem.cc
===
RCS file: /cvs/src/src/winsup/cygserver/sysv_sem.cc,v
retrieving revision 1.3
diff -p -u -r1.3 sysv_sem.cc
--- winsup/cygserver/sysv_sem.cc2 Mar 2004 11:08:35 - 1.3
+++ winsup/cygserver/sysv_sem.cc1 Oct 2004 11:02:49 -
@@ -,15 +,6 @@ semop(struct thread *td, struct semop_ar
semwait, 0);
DPRINTF((semop: good morning (error=%d)!\n, error));
- if (error != 0) {
-#ifdef __CYGWIN__
- if (error != EIDRM)
-#endif /* __CYGWIN__ */
- error = EINTR;
- goto done2;
- }
- DPRINTF((semop: good morning!\n));
-
/*
* Make sure that the semaphore still exists
*/
@@ -1137,6 +1128,20 @@ semop(struct thread *td, struct semop_ar
semptr-semzcnt--;
else
semptr-semncnt--;
+
+ /*
+* Is it really morning, or was our sleep interrupted?
+* (Delayed check of msleep() return code because we
+* need to decrement sem[nz]cnt either way.)
+*/
+ if (error != 0) {
+#ifdef __CYGWIN__
+ if (error != EIDRM)
+#endif /* __CYGWIN__ */
+ error = EINTR;
+ goto done2;
+ }
+ DPRINTF((semop: good morning!\n));
}
done:
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader mailto:[EMAIL PROTECTED]
Red Hat, 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/
Re: Cygserver 100% CPU (was: References to both cygwin1.dll and msvcrt.dl
On Sep 30 23:22, Patrick Samson wrote: --- Corinna Vinschen wrote: On Sep 30 00:12, Patrick Samson wrote: I built the DLL another way, and now have: $ cygcheck ./dp40.dll .\dp40.dll D:\cygwin\bin\cygwin1.dll C:\WINNT\System32\ADVAPI32.DLL C:\WINNT\System32\ntdll.dll C:\WINNT\System32\KERNEL32.dll C:\WINNT\System32\USER32.dll C:\WINNT\System32\GDI32.dll C:\WINNT\System32\RPCRT4.dll D:\cygwin\bin\tcl84.dll C:\WINNT\System32\WS2_32.DLL C:\WINNT\System32\MSVCRT.dll --- C:\WINNT\System32\WS2HELP.dll Seems better, as msvcrt.dll is only there because of ws2_32 (winsock2). Which shouldn't be referenced at all. dp40.dll apparently references ws2_32.dll directly instead of using the Cygwin socket calls. There is the link command generated by autotools: gcc -mwin32 -g -O2 -o dp40.dll -shared -Wl,--export-all-symbols -Wl,-s dpChan.o dpCmds.o dpRPC.o dpPlugF.o dpFilte rs.o dpIdentity.o dpPackOff.o dpInit.o dpSerial.o dpSock.o dpWinInit.o dpWinSerial.o dpWinSock.o dpWinTcp.o dpWinUD P.o dpWinIPM.o -ltcl84 -lws2_32 If I omit -lws2_32, I receive undefined reference for winsock functions (one of the source has #include ws2tcpip.h for IP multicast). What should I do? Nothing for now. If you don't need multicast, you can try to build without it but that's very likely not related to the cygserver problem. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:[EMAIL PROTECTED] Red Hat, 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/
Re: Cygserver 100% CPU (was: References to both cygwin1.dll and msvcrt.dl
--- Corinna Vinschen wrote: On Sep 30 23:41, Patrick Samson wrote: Now, when it's wrong, I can see: good morning (error=4)! Error 4 is EINTR on the return of msleep(). Subsequently semop() returns with this EINTR. Are you set up to build cygwin? If so, could you please test the following patch to cygserver and if it changes anything for you? cygserver.exe built, but /var/log/cygserver.log is 0KB What did I miss? I only replaced the original exe 101KB by the new one 1417KB on the test box (so conf is kept). ___ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com -- 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/
Re: Cygserver 100% CPU (was: References to both cygwin1.dll and msvcrt.dl
On Oct 1 06:05, Patrick Samson wrote: --- Corinna Vinschen wrote: On Sep 30 23:41, Patrick Samson wrote: Now, when it's wrong, I can see: good morning (error=4)! Error 4 is EINTR on the return of msleep(). Subsequently semop() returns with this EINTR. Are you set up to build cygwin? If so, could you please test the following patch to cygserver and if it changes anything for you? cygserver.exe built, but /var/log/cygserver.log is 0KB What did I miss? Dunno. How shall I know without any details? The patch I've posted has nothing whatsoever to do with logging, FWIW. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:[EMAIL PROTECTED] Red Hat, 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/
Re: Cygserver 100% CPU (was: References to both cygwin1.dll and msvcrt.dl
--- Corinna Vinschen wrote: On Oct 1 06:05, Patrick Samson wrote: --- Corinna Vinschen wrote: On Sep 30 23:41, Patrick Samson wrote: Now, when it's wrong, I can see: good morning (error=4)! Error 4 is EINTR on the return of msleep(). Subsequently semop() returns with this EINTR. Are you set up to build cygwin? If so, could you please test the following patch to cygserver and if it changes anything for you? cygserver.exe built, but /var/log/cygserver.log is 0KB What did I miss? Dunno. How shall I know without any details? The patch I've posted has nothing whatsoever to do with logging, FWIW. By default configure uses sysconfdir as /usr/local/etc so the exe was looking for .conf in this directory, which is empty. I had to ./configure --sysconfdir=/etc Now traces are there. Testing... __ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail -- 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/
Re: Cygserver 100% CPU (was: References to both cygwin1.dll and msvcrt.dl
--- Corinna Vinschen wrote: On Sep 30 23:41, Patrick Samson wrote: Now, when it's wrong, I can see: good morning (error=4)! Error 4 is EINTR on the return of msleep(). Subsequently semop() returns with this EINTR. Are you set up to build cygwin? If so, could you please test the following patch to cygserver and if it changes anything for you? Same behaviour. As soon as there are some error=4, it will hang. On service stop, postgres may stop some of its backends, but not all of them, and stay in 'Stopping' state. If I 'End Process' cygserver, PG used to disappear, except the last try where I had to 'End Process' two defunct postgres.exe. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- 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/
Re: Cygserver 100% CPU (was: References to both cygwin1.dll and msvcrt.dl
--- Patrick Samson wrote: --- Igor Pechtchanski wrote: On Mon, 27 Sep 2004, Patrick Samson wrote: I use a dll which have references to both cygwin and m$: $ cygcheck /usr/share/tcl8.4/dp4.0/win/dp40.dll D:/cygwin/usr/share/tcl8.4/dp4.0/win/dp40.dll D:\cygwin\bin\tcl84.dll C:\WINNT\System32\ADVAPI32.DLL C:\WINNT\System32\ntdll.dll C:\WINNT\System32\KERNEL32.dll C:\WINNT\System32\USER32.dll C:\WINNT\System32\GDI32.dll C:\WINNT\System32\RPCRT4.dll D:\cygwin\bin\cygwin1.dll - C:\WINNT\System32\msvcrt.dll C:\WINNT\System32\WS2_32.DLL C:\WINNT\System32\WS2HELP.dll Should I suspect this to be a possible source of trouble? Or does it mean nothing? Depends. Usually, this results in some sort of trouble, mostly because of the separate parallel stdio, malloc, etc implementations. You may be able to get away with it for a while if none of the msvcrt functions are actually called, but it may come back and bite you in the future. Igor Since my post I found a way to reproduce on development the problem I have on production. At some point cygserver hits 100%CPU and Postgres backends are no more able to serve requests. Now I must narrow the number of components involved, to prove that the culprit is really this DLL. As you suggest, it may be a mess with mem alloc. I built the DLL another way, and now have: $ cygcheck ./dp40.dll .\dp40.dll D:\cygwin\bin\cygwin1.dll C:\WINNT\System32\ADVAPI32.DLL C:\WINNT\System32\ntdll.dll C:\WINNT\System32\KERNEL32.dll C:\WINNT\System32\USER32.dll C:\WINNT\System32\GDI32.dll C:\WINNT\System32\RPCRT4.dll D:\cygwin\bin\tcl84.dll C:\WINNT\System32\WS2_32.DLL C:\WINNT\System32\MSVCRT.dll --- C:\WINNT\System32\WS2HELP.dll Seems better, as msvcrt.dll is only there because of ws2_32 (winsock2). But the problem is still there, so this may not be the primary cause. With cygserver debug, I found the same case as: http://sources.redhat.com/ml/cygwin/2004-07/msg01058.html (cygserver - Postgres Multiple connection Load Testing - Inifinte Loop). But this post has no reply :( The log file is full (75M in a few seconds!) with: cygserver: /netrel/src/cygwin-1.5.10-3/winsup/cygserver/bsd_mutex.cc, line 189: Unlockedmutex semid cygserver: /netrel/src/cygwin-1.5.10-3/winsup/cygserver/bsd_mutex.cc, line 227: Try locking mutex semid cygserver: /netrel/src/cygwin-1.5.10-3/winsup/cygserver/bsd_mutex.cc, line 227: Locked mutex semid cygserver: /netrel/src/cygwin-1.5.10-3/winsup/cygserver/sysv_sem.cc, line 1112: semop: good morning (error=0)! cygserver: /netrel/src/cygwin-1.5.10-3/winsup/cygserver/sysv_sem.cc, line 1121: semop: good morning! cygserver: /netrel/src/cygwin-1.5.10-3/winsup/cygserver/sysv_sem.cc, line 1049: semop: semaptr=A056AA0, sem_base=A05684C, semptr=A056870, sem[3]=0 : op=-1, flag=wait cygserver: /netrel/src/cygwin-1.5.10-3/winsup/cygserver/sysv_sem.cc, line 1053: semop: can't do it now cygserver: /netrel/src/cygwin-1.5.10-3/winsup/cygserver/sysv_sem.cc, line 1086: semop: rollback 0 through -1 cygserver: /netrel/src/cygwin-1.5.10-3/winsup/cygserver/sysv_sem.cc, line 1109: semop: good night! Got to upgrade to 1.5.11 and check if it's better. Meanwhile, Corinna, any obvious suggestion, looking at these above traces? __ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail -- 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/
Re: Cygserver 100% CPU (was: References to both cygwin1.dll and msvcrt.dl
--- Patrick Samson wrote: --- Patrick Samson wrote: Since my post I found a way to reproduce on development the problem I have on production. At some point cygserver hits 100%CPU and Postgres backends are no more able to serve requests. Now I must narrow the number of components involved, to prove that the culprit is really this DLL. As you suggest, it may be a mess with mem alloc. I built the DLL another way, and now have: $ cygcheck ./dp40.dll .\dp40.dll D:\cygwin\bin\cygwin1.dll C:\WINNT\System32\ADVAPI32.DLL C:\WINNT\System32\ntdll.dll C:\WINNT\System32\KERNEL32.dll C:\WINNT\System32\USER32.dll C:\WINNT\System32\GDI32.dll C:\WINNT\System32\RPCRT4.dll D:\cygwin\bin\tcl84.dll C:\WINNT\System32\WS2_32.DLL C:\WINNT\System32\MSVCRT.dll --- C:\WINNT\System32\WS2HELP.dll Seems better, as msvcrt.dll is only there because of ws2_32 (winsock2). But the problem is still there, so this may not be the primary cause. With cygserver debug, I found the same case as: http://sources.redhat.com/ml/cygwin/2004-07/msg01058.html (cygserver - Postgres Multiple connection Load Testing - Inifinte Loop). But this post has no reply :( The log file is full (75M in a few seconds!) with: cygserver: /netrel/src/cygwin-1.5.10-3/winsup/cygserver/bsd_mutex.cc, line 189: Unlockedmutex semid cygserver: /netrel/src/cygwin-1.5.10-3/winsup/cygserver/bsd_mutex.cc, line 227: Try locking mutex semid cygserver: /netrel/src/cygwin-1.5.10-3/winsup/cygserver/bsd_mutex.cc, line 227: Locked mutex semid cygserver: /netrel/src/cygwin-1.5.10-3/winsup/cygserver/sysv_sem.cc, line 1112: semop: good morning (error=0)! cygserver: /netrel/src/cygwin-1.5.10-3/winsup/cygserver/sysv_sem.cc, line 1121: semop: good morning! cygserver: /netrel/src/cygwin-1.5.10-3/winsup/cygserver/sysv_sem.cc, line 1049: semop: semaptr=A056AA0, sem_base=A05684C, semptr=A056870, sem[3]=0 : op=-1, flag=wait cygserver: /netrel/src/cygwin-1.5.10-3/winsup/cygserver/sysv_sem.cc, line 1053: semop: can't do it now cygserver: /netrel/src/cygwin-1.5.10-3/winsup/cygserver/sysv_sem.cc, line 1086: semop: rollback 0 through -1 cygserver: /netrel/src/cygwin-1.5.10-3/winsup/cygserver/sysv_sem.cc, line 1109: semop: good night! Got to upgrade to 1.5.11 and check if it's better. Meanwhile, Corinna, any obvious suggestion, looking at these above traces? Special note for Postgresql users: So far I can only reproduce this problem if these 3 conditions are met: - many connections (20, 25, 27) doing a simple SELECT - a script running SELECT, CREATE/DROP TABLE/INDEX ... - a pgAdmin III connected (but without activity) (Postgresql version 7.3.6) Quite the same with 1.5.11-3, only the loop is slower so the CPU is not 100% and the log file doesn't grow wildly. Just an extract of the log here (full file 263K on request): cygserver: /netrel/src/cygwin-1.5.11-1/winsup/cygserver/bsd_mutex.cc, line 189: Unlockedmutex semid cygserver: /netrel/src/cygwin-1.5.11-1/winsup/cygserver/bsd_mutex.cc, line 232: Try locking mutex semid cygserver: /netrel/src/cygwin-1.5.11-1/winsup/cygserver/bsd_mutex.cc, line 232: Locked mutex semid cygserver: /netrel/src/cygwin-1.5.11-1/winsup/cygserver/sysv_sem.cc, line 1112: semop: good morning (error=0)! cygserver: /netrel/src/cygwin-1.5.11-1/winsup/cygserver/sysv_sem.cc, line 1121: semop: good morning! cygserver: /netrel/src/cygwin-1.5.11-1/winsup/cygserver/sysv_sem.cc, line 1049: semop: semaptr=A056718, sem_base=A056440, semptr=A0564F4, sem[15]=0 : op=-1, flag=wait cygserver: /netrel/src/cygwin-1.5.11-1/winsup/cygserver/sysv_sem.cc, line 1053: semop: can't do it now cygserver: /netrel/src/cygwin-1.5.11-1/winsup/cygserver/sysv_sem.cc, line 1086: semop: rollback 0 through -1 cygserver: /netrel/src/cygwin-1.5.11-1/winsup/cygserver/sysv_sem.cc, line 1109: semop: good night! cygserver: /netrel/src/cygwin-1.5.11-1/winsup/cygserver/bsd_mutex.cc, line 189: Unlockedmutex semid cygserver: /netrel/src/cygwin-1.5.11-1/winsup/cygserver/bsd_mutex.cc, line 232: Try locking mutex semid cygserver: /netrel/src/cygwin-1.5.11-1/winsup/cygserver/bsd_mutex.cc, line 232: Locked mutex semid cygserver: /netrel/src/cygwin-1.5.11-1/winsup/cygserver/sysv_sem.cc, line 1112: semop: good morning (error=4)! cygserver: /netrel/src/cygwin-1.5.11-1/winsup/cygserver/sysv_sem.cc, line 1218: Unlockedmutex semid cygserver: /netrel/src/cygwin-1.5.11-1/winsup/cygserver/sysv_sem.cc, line 968: call to semop(65537, 0x22E444, 1) cygserver: /netrel/src/cygwin-1.5.11-1/winsup/cygserver/sysv_sem.cc, line 994: Try locking mutex semid cygserver: /netrel/src/cygwin-1.5.11-1/winsup/cygserver/sysv_sem.cc, line 994: Locked mutex semid cygserver: /netrel/src/cygwin-1.5.11-1/winsup/cygserver/sysv_sem.cc, line 1049: semop: semaptr=A056760, sem_base=A05650C, semptr=A056530, sem[3]=0 : op=-1, flag=wait cygserver:
Re: Cygserver 100% CPU (was: References to both cygwin1.dll and msvcrt.dl
Special note for Postgresql users: So far I can only reproduce this problem if these 3 conditions are met: - many connections (20, 25, 27) doing a simple SELECT - a script running SELECT, CREATE/DROP TABLE/INDEX ... - a pgAdmin III connected (but without activity) (Postgresql version 7.3.6) Doesn't fail by just changing pgAdmin III with pgAdmin II. What's the difference? III tries first to talk in protocol V3 with the PG backend. If the backend doesn't understand this version, which the case for v7.3.6, pgAdmin falls back to protocol V2 and things go on. We can see it in the PG log with: FATAL: unsupported frontend protocol Does it mean that the backend did something wrong with the IPCs when refusing V3 ...? ___ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com -- 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/
Re: Cygserver 100% CPU (was: References to both cygwin1.dll and msvcrt.dl
Sigh, Just after this post, I ran into the hang. So pgAdmin II is no better, may be just a little more difficult to fire the hang. Still searching ... --- Patrick Samson wrote: Special note for Postgresql users: So far I can only reproduce this problem if these 3 conditions are met: - many connections (20, 25, 27) doing a simple SELECT - a script running SELECT, CREATE/DROP TABLE/INDEX ... - a pgAdmin III connected (but without activity) (Postgresql version 7.3.6) Doesn't fail by just changing pgAdmin III with pgAdmin II. What's the difference? III tries first to talk in protocol V3 with the PG backend. If the backend doesn't understand this version, which the case for v7.3.6, pgAdmin falls back to protocol V2 and things go on. We can see it in the PG log with: FATAL: unsupported frontend protocol Does it mean that the backend did something wrong with the IPCs when refusing V3 ...? __ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail -- 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/
Re: Cygserver 100% CPU (was: References to both cygwin1.dll and msvcrt.dl
On Sep 30 00:12, Patrick Samson wrote: I built the DLL another way, and now have: $ cygcheck ./dp40.dll .\dp40.dll D:\cygwin\bin\cygwin1.dll C:\WINNT\System32\ADVAPI32.DLL C:\WINNT\System32\ntdll.dll C:\WINNT\System32\KERNEL32.dll C:\WINNT\System32\USER32.dll C:\WINNT\System32\GDI32.dll C:\WINNT\System32\RPCRT4.dll D:\cygwin\bin\tcl84.dll C:\WINNT\System32\WS2_32.DLL C:\WINNT\System32\MSVCRT.dll --- C:\WINNT\System32\WS2HELP.dll Seems better, as msvcrt.dll is only there because of ws2_32 (winsock2). Which shouldn't be referenced at all. dp40.dll apparently references ws2_32.dll directly instead of using the Cygwin socket calls. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:[EMAIL PROTECTED] Red Hat, 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/
