--- Corinna Vinschen wrote:
> I've checked in a patch which uses a somewhat more
> complicated
> synchronization method in msleep. The testsuite
> testcases still
> work as expected but I would like to get some
> feedback on your issue.
> Please test cygserver from the next Cygwin snapshot
> or
On Dec 22 19:18, Corinna Vinschen wrote:
> On Dec 22 08:03, Patrick Samson wrote:
> > Corinna,
> > I just want to make sure you didn't miss my post
> > in november, about this same subject:
> > http://sources.redhat.com/ml/cygwin/2004-11/msg00749.html
> > If you read it and didn't have anything to
On Dec 22 08:03, Patrick Samson wrote:
> Corinna,
> I just want to make sure you didn't miss my post
> in november, about this same subject:
> http://sources.redhat.com/ml/cygwin/2004-11/msg00749.html
> If you read it and didn't have anything to suggest
> it's fine for me and sorry for this remaind
Corinna,
I just want to make sure you didn't miss my post
in november, about this same subject:
http://sources.redhat.com/ml/cygwin/2004-11/msg00749.html
If you read it and didn't have anything to suggest
it's fine for me and sorry for this remainder.
If you didn't, please have a look.
I don't know
(This is a continuation of previous postings in
Oct 2004)
In my last trial, I saw cygserver at 100%
for about 20 s, and then back naturally to 0.
Looking at the log, the loops are:
(with one or more sem[x])
return from WaitForMultipleObjects() ...
bsd_mutex.cc, line 235: Try locking mutex semid
forgot the log file. Here is it.
___
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com
cygserver.log.bz2
Description: cygserver.log.bz2
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem rep
--- Corinna Vinschen wrote:
> 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
On Tue, Oct 05, 2004 at 07:44:03AM -0700, Patrick Samson wrote:
>--- Corinna Vinschen wrote:
>
>> 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
--- Corinna Vinschen wrote:
> 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
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
--- 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().
> > > > Subseque
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.
> >
> >
--- 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
--- 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().
> > > > Subseq
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.
> >
> >
--- 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
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
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
--- 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_dump
--- 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:\W
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\S
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
> 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 ver
--- 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 comp
--- 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:\
25 matches
Mail list logo
