Mail Archives: cygwin/2004/09/30/03:12:35
--- 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: Unlocked mutex 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/
- Raw text -