Re: Please try the latest snapshot

[Achim Gratz]

Christopher Faylor  cygwin.com> writes:
> The latest snapshot has some more signal-handling restructuring.
> I'd appreciate it if people would check it out.

Looks good so far.  I've had a compile that would pretty often lock up cmake
during the config phase so that it needed to be killed from task manager. 
That seems to be gone, as well as the hangs that git would sometimes produce
when doing lots of git-receive-pack back-to-back.


Regards,
Achim.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Please try the latest snapshot

[Christopher Faylor]

On Wed, Apr 10, 2013 at 09:20:26AM -0400, Christopher Faylor wrote:
>The latest snapshot has some more signal-handling restructuring.
>I'd appreciate it if people would check it out.

http://cygwin.com/snapshots/

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Please try the latest snapshot

[Christopher Faylor]

The latest snapshot has some more signal-handling restructuring.
I'd appreciate it if people would check it out.

cgf

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Please try the latest snapshot [Re: 1.7.8: write fails with EAGAIN]

[Christopher Faylor]

On Mon, Mar 07, 2011 at 11:38:49AM -0500, Christopher Faylor wrote:
>On Mon, Mar 07, 2011 at 10:37:08AM -0500, Christopher Faylor wrote:
>>On Mon, Mar 07, 2011 at 11:39:51AM +0100, Corinna Vinschen wrote:
>>>On Mar  5 21:12, Robert Wruck wrote:
>>>> Hi,
>>>> 
>>>> recently, I found that cygwin-git was not able to 'cat-file' files
>>>> that exceeded some size (in my case about 80MB).
>>>> I tracked this down to the cygwin implementation of write() that
>>>> behaves quite odd in some cases.
>>>> 
>>>> I wrote a small program (source attached) that mmaps a given file
>>>> and tries to write it to another file or stdout.
>>>> 
>>>> The results vary:
>>>> 
>>>> If the destination is a file (`writetest infile outfile` or
>>>> `writetest infile > outfile`), the write succeeds in a single call.
>>>> 
>>>> If the destination is a pipe (`writetest infile | cat > outfile`),
>>>> the write succeeds in most cases. BUT:
>>>> 
>>>> Under WinXP (XP Service Pack 2, 32bit), the call returns -1 and
>>>> errno=EAGAIN. Nevertheless, SOME data is written to the pipe (in my
>>>> case 4096 byte for each call).
>>>> This breaks git since it does an infinite loop while errno=EAGAIN.
>>>
>>>Hang on, you are saying that a *blocking* write(2) to a pipe returns
>>>with EAGAIN?  Are you sure?  It would be quite a surprise if git would
>>>actually do that.  EAGAIN is only an expected error for non-blocking
>>>I/O, so applications which use blocking I/O usually only test for EINTR.
>>
>>I can barely convince myself that there's a pathological case where an
>>EAGAIN could leak out.  I'm investigating now.
>
>Actually, in this case, it looks like the problem is that Windows
>doesn't like sending a huge buffer to a pipe.  The errno in this case
>should probably be something like EFBIG rather than EAGAIN.
>
>Does git deal with this type of errno gracefully or does it just abort
>if the write() fails for any reason?  I'd rather just fail and let the
>caller deal with it than complicate Cygwin's code by trying to loop
>writing smaller amount of data to the pipe so I'd prefer just changing
>the errno if that solves the problem.

I've just uploaded a snapshot which attempts to work around this
problem.  I ended up making some fairly substantial changes to the
pipe handling so this needs some serious testing, especially on
different platforms, e.g., XP, XP64, Windows 2008, etc.

Please try the latest snapshot at:

http://cygwin.com/snapshots/

cgf

cgf

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: ssh-add hangers -- please try the latest snapshot

[Andrew Schulman]

> Hi All...
> 
> With the latest snapshot, I can not see the problem now.
> 
> It also seemd to take a long time sometimes with the previous snapshot 
> (March 4) in ssh-add. That also seems better now. But I really don't have 
> enough data to say much here...it just seems better.

You're right-- after the first invocation, ssh-add would work, but 
strace showed that the troublesome call would take about 1 s to return.  
That time is now < 1 ms.


--
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: ssh-add hangers -- please try the latest snapshot

[Andrew Schulman]

> On Thu, Mar 10, 2005 at 08:24:25AM -0500, Chuck wrote:
> >Christopher Faylor wrote:
> >>Corinna identified a couple of problems and checked in some fixes which
> >>may solve the problem with ssh-add hanging.
> >>
> >>Please try the latest snapshot and report success for failure here.
> >>
> >>http://cygwin.com/snapshots/
> >
> >Seems to have fixed the problem.  Thanks Corinna, Christopher, Andrew,
> >and anyone else involved.
> 
> Andrew, does this solve your problem?

Yes, the hang is gone when I use 2005-03-09 snapshot.  And, the formerly 
troublesome call now returns in < 1 ms, instead of ~1 s as before.  As 
Chuck said, thanks to you and Corinna for pursuing and fixing this.

> I have been puzzling over the segv that you reported trying to figure
> out how it could possibly happen.  I checked in a half-hearted attempt
> to fix it but I'm not too confident that it will rectify anything.  It's
> dying in networking code at a very strange place.

Agreed.  I can tell you that the problem isn't fixed in the 2005-03-09 
snapshot, but I'll continue discussion of that problem in the other 
thread.

Andrew.


--
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/

ssh-add hangers -- please try the latest snapshot

[Karl M]

Hi All...
With the latest snapshot, I can not see the problem now.
It also seemd to take a long time sometimes with the previous snapshot 
(March 4) in ssh-add. That also seems better now. But I really don't have 
enough data to say much here...it just seems better.

Thanks,
...Karl

--
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: ssh-add hangers -- please try the latest snapshot

[Christopher Faylor]

On Thu, Mar 10, 2005 at 08:24:25AM -0500, Chuck wrote:
>Christopher Faylor wrote:
>>Corinna identified a couple of problems and checked in some fixes which
>>may solve the problem with ssh-add hanging.
>>
>>Please try the latest snapshot and report success for failure here.
>>
>>http://cygwin.com/snapshots/
>
>Seems to have fixed the problem.  Thanks Corinna, Christopher, Andrew,
>and anyone else involved.

Andrew, does this solve your problem?

I have been puzzling over the segv that you reported trying to figure
out how it could possibly happen.  I checked in a half-hearted attempt
to fix it but I'm not too confident that it will rectify anything.  It's
dying in networking code at a very strange place.

cgf

--
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: ssh-add hangers -- please try the latest snapshot

[Chuck]

Christopher Faylor wrote:
> Corinna identified a couple of problems and checked in some fixes
> which may solve the problem with ssh-add hanging.
> 
> Please try the latest snapshot and report success for failure here.
> 
> http://cygwin.com/snapshots/
> 
> cgf
> 

Seems to have fixed the problem. Thanks Corinna, Christopher, Andrew,
and anyone else involved.
-- 
To reply by email remove "_nospam"


--
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/

ssh-add hangers -- please try the latest snapshot

[Christopher Faylor]

Corinna identified a couple of problems and checked in some fixes
which may solve the problem with ssh-add hanging.

Please try the latest snapshot and report success for failure here.

http://cygwin.com/snapshots/

cgf

--
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: please try the latest snapshot

[Rajesh Balakrishnan]

Hi,

This snapshot (20040306) fixes some of the problems with running emacs.
The problem existed even with snapshot of 20040225 (hadn't tried 0305).

emacs (under X11) has been running fine for over a day now.
It used to crash randomly (SEGV), earlier.

Thanks,
rb

Christopher Faylor wrote: 
> The latest snapshot should fix "virtual memory exhausted" errors that
> were reported when running "make -j".
> 
> I am close to releasing cygwin 1.5.8 so I want to verify that this is
> fixed.
> 
> http://cygwin.com/snapshots/
> 
> cgf


__
Do you Yahoo!?
Yahoo! Search - Find what you’re looking for faster
http://search.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: please try the latest snapshot

[Volker Quetschke]

OK, did that, and got a freeze after 196 iterations. Still using your
make with debug info.
This time my script enabled the malloc debug info

strace -mall+malloc -o strace.out make -j -f MakefileV > $logname 2>> 
$logerr

so the strace is very long, you can find it here:



Unfortunately I pressed CTRL-c before looking at the running
processes, I cannot say where it was hanging.

I've run it twice so far, 128 iterations, then about 2500, running it a 
third time now.  In both cases, it was make hanging with 0% cpu usage, 
and I lost the strace from the second run (I tried using "/bin/kill -f 
pid", and the return code from the make process was 0, so the script 
kept going).
The first run (mentioned above) were 196 iterations, I startet the
script again and got an error, not a hang, after 1987 iterations:
make: *** wait: Interrupted system call.  Stop.
make: *** Waiting for unfinished jobs
make: *** Waiting for unfinished jobs
make: *** Waiting for unfinished jobs
make: *** Waiting for unfinished jobs
make: *** Waiting for unfinished jobs
make: *** Waiting for unfinished jobs
I have a strace with malloc for this too, shall I put
it somewhere on the web?
Volker

--
PGP/GPG key  (ID: 0x9F8A785D)  available  from  wwwkeys.de.pgp.net
key-fingerprint 550D F17E B082 A3E9 F913  9E53 3D35 C9BA 9F8A 785D
--
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: please try the latest snapshot

[Rolf Campbell]

Volker Quetschke wrote:

Christopher Faylor wrote:

The latest snapshot should fix "virtual memory exhausted" errors that
were reported when running "make -j".
I am close to releasing cygwin 1.5.8 so I want to verify that this is
fixed.
OK, did that, and got a freeze after 196 iterations. Still using your
make with debug info.
This time my script enabled the malloc debug info

strace -mall+malloc -o strace.out make -j -f MakefileV > $logname 2>> 
$logerr

so the strace is very long, you can find it here:



Unfortunately I pressed CTRL-c before looking at the running
processes, I cannot say where it was hanging.
Volker

I've run it twice so far, 128 iterations, then about 2500, running it a 
third time now.  In both cases, it was make hanging with 0% cpu usage, 
and I lost the strace from the second run (I tried using "/bin/kill -f 
pid", and the return code from the make process was 0, so the script 
kept going).

-Rolf

--
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: please try the latest snapshot

[Volker Quetschke]

Christopher Faylor wrote:
The latest snapshot should fix "virtual memory exhausted" errors that
were reported when running "make -j".
I am close to releasing cygwin 1.5.8 so I want to verify that this is
fixed.
OK, did that, and got a freeze after 196 iterations. Still using your
make with debug info.
This time my script enabled the malloc debug info

strace -mall+malloc -o strace.out make -j -f MakefileV > $logname 2>> 
$logerr

so the strace is very long, you can find it here:



Unfortunately I pressed CTRL-c before looking at the running
processes, I cannot say where it was hanging.
Volker

--
PGP/GPG key  (ID: 0x9F8A785D)  available  from  wwwkeys.de.pgp.net
key-fingerprint 550D F17E B082 A3E9 F913  9E53 3D35 C9BA 9F8A 785D
--
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/

please try the latest snapshot

[Christopher Faylor]

The latest snapshot should fix "virtual memory exhausted" errors that
were reported when running "make -j".

I am close to releasing cygwin 1.5.8 so I want to verify that this is
fixed.

http://cygwin.com/snapshots/

cgf

--
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: Please try the latest snapshot -- it is close to cygwin 1.5.6

[Pierre A. Humblet]

Christopher Faylor wrote:
>
>I fixed some more problems with both vfork and with fork recently.  The
>fixes are currently in cvs.

It's much better. 

CYGWIN_ME-4.90 hpn5170x 1.5.6(0.108/3/2) 2003-12-29 22:44 i686 unknown
unknown Cygwin

I only have problems with the more complicated tests.
Open two tty windows, tty0 and tty1.
In the tty0 window, type
setsid bash -c "echo hello > /dev/tty1; /bin/sleep 10; /bin/echo there >
/dev/tty"
 
Note the first echo is a built-in and the last /dev/tty (not /dev/tty1). 
Things go as I think they should: "echo" & "there" appear in the tty1 window, 
and ps shows that bash and sleep have tty1 as ctty. 

However when using sh,
setsid sh -c "echo hello > /dev/tty1; /bin/sleep 10; /bin/echo there >
/dev/tty"
sh and the final echo hang forever (with echo in the "O" state in ps),
and sh cannot be terminated with kill (OK from the task manager).
Moreover sysinternals shows that tty1 is not opened in sh, nor in /bin/echo
(despite
being the ctty), although it is open in /bin/sleep.
(My sandbox is slightly different from cvs, but "it shouldn't matter").
 
Also I still observe processes terminating with the "error in Cygwin1.dll"
popup 
(exim, mutt, tty, id, dircolors). JIT gdb kicked in once. Only thread 1 was
active 
and I couldn't get any useful info. I didn't see the "proc lock"
system_printf.

Pierre


--
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: Please try the latest snapshot -- it is close to cygwin 1.5.6

[Christopher Faylor]

On Mon, Dec 29, 2003 at 10:04:01PM -0500, Christopher Faylor wrote:
>On Sun, Dec 28, 2003 at 12:26:32PM -0500, Nicholas Wourms wrote:
>>Pierre A. Humblet wrote:
>>>At 12:46 PM 12/27/2003 -0500, Christopher Faylor wrote:
>>>
I missed the 'sh -c' clue in your previous message.  Since sh uses
vfork, that indicates a vfork problem.  I've checked in some more
changes to deal with this.  It seems to do the right thing both with sh
-c and without.  It also should have the added benefit of doing the
right thing wrt deallocating the console appropriately since open_fhs
should now track the ctty usecount.  This was screwed up before,
apparently even before I started mucking with the tty stuff.

I sure do hate usage counting.

cgf
>>>
>>>
>>>Yes, that works fine now, as does bash -c inetd.
>>>
>>
>>Sorry to jump in on this, but I run into a few problems with the changes 
>>you made last night and one issue which has been a problem for some time 
>>now.
>>
>>This is on my Win2k box and all problems were noticed when I logged in 
>>remotely via ssh (I have not tried locally).  If it makes any 
>>difference, the /usr/src dir, where all my project and cygwin source is 
>>contained, is a managed mount.
>>
>>Issues from yesterday's checkin:
>>1)When run by itself from the command line, `make` is not forking 
>>properly for recursive makes, instead it aborts and returns a bogus 
>>HANGUP signal to the console.  This is easily seen when attempting to 
>>build the Cygwin tree.  I cannot provide any useful output since it 
>>appears that calling the process from within gdb or through strace 
>>actually keeps make from failing to fork, but make still screws up the 
>>order of entry into subdirs.
>
>I routinely check correct cygwin operation by building cygwin so I can't
>reproduce this.
>
>>2)`procps auxf` incorrectly identifies top-parent processes as 
>>, even though ps and the nt process monitor shows them to be 
>>valid.  However, for postgres's postmaster, the parent and *all* 
>>children are labeled as  even though I can confirm that the 
>>server is up and running.
>
>A trivial test of this, which is to run "procps auwx" from a command prompt,
>does not demonstrate this here.
>
>>3)Running configure scripts using sh.exe (which is default when you 
>>./configure) always hangs, whereas running them through bash.exe works 
>>fine (although it does hang from time to time).  In either case, when it 
>>hangs, doing ctrl-c will drop you to the command line.  However, the 
>>process isn't terminated, like one would expect.  Also, it refuses to 
>>obey any signal except SIGKILL.
>
>I don't use bash very often.  I use zsh or just the command prompt.  I
>can run 'sh /whereever/configure' just fine.
>
>>Existing issues since 1.5.5:
>>3)I find myself involuntarily "logged-out" of my sessions at random 
>>intervals.  This is especially prevalent when doing massive recursive 
>>`rm -rf`'s or `grep -rn`'s or any other form of intensive disk i/o. 
>>However, whatever is causing it seems to be getting fixed, since this 
>>happens less frequently then it used to.  A small kludge I use to get 
>>around this is by running links.exe then using ctrl-Z to send it to a 
>>stopped state.  Then if it tries to log me out, it will fail because I 
>>have a stopped process.
>
>Again, I don't see this, so I don't know how it could be fixed.
>
>>4)lynx crashes on startup, dropping me back to the command line. 
>>Running it through gdb, the segfault happens at line 81 of cygtls.cc, 
>>"_last_thread->next = this" which is inside the function 
>>_threadinfo::init_thread(void*).  Unfortunately, my system is in a state 
>>where I cannot get make to run correctly, so trying to build a debug 
>>version of lynx at this point is not feasible.  I should note that I do 
>>not see this problem inside links.
>
>Since cygtls.c is a recent addition, this is not a 1.5.5 issue.  lynx
>also works fine here.

Btw, I should point out, that I am using the most recent version of
cygwin currently in CVS.  I didn't try this with the cygwin vintage that
this message refers to but I haven't made any changes which would cause
any of the above to work any better.

cgf

--
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: Please try the latest snapshot -- it is close to cygwin 1.5.6

[Christopher Faylor]

On Sat, Dec 27, 2003 at 06:28:09PM -0500, Pierre A. Humblet wrote:
>...when I launch inetd from an rxvt window running bash, or from a Dos
>window running cygwin.bat with tty, I still see tty handles in inetd.

I fixed some more problems with both vfork and with fork recently.  The
fixes are currently in cvs.

cgf

--
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: Please try the latest snapshot -- it is close to cygwin 1.5.6

[Christopher Faylor]

On Sun, Dec 28, 2003 at 12:26:32PM -0500, Nicholas Wourms wrote:
>Pierre A. Humblet wrote:
>>At 12:46 PM 12/27/2003 -0500, Christopher Faylor wrote:
>>
>>>I missed the 'sh -c' clue in your previous message.  Since sh uses
>>>vfork, that indicates a vfork problem.  I've checked in some more
>>>changes to deal with this.  It seems to do the right thing both with sh
>>>-c and without.  It also should have the added benefit of doing the
>>>right thing wrt deallocating the console appropriately since open_fhs
>>>should now track the ctty usecount.  This was screwed up before,
>>>apparently even before I started mucking with the tty stuff.
>>>
>>>I sure do hate usage counting.
>>>
>>>cgf
>>
>>
>>Yes, that works fine now, as does bash -c inetd.
>>
>
>Sorry to jump in on this, but I run into a few problems with the changes 
>you made last night and one issue which has been a problem for some time 
>now.
>
>This is on my Win2k box and all problems were noticed when I logged in 
>remotely via ssh (I have not tried locally).  If it makes any 
>difference, the /usr/src dir, where all my project and cygwin source is 
>contained, is a managed mount.
>
>Issues from yesterday's checkin:
>1)When run by itself from the command line, `make` is not forking 
>properly for recursive makes, instead it aborts and returns a bogus 
>HANGUP signal to the console.  This is easily seen when attempting to 
>build the Cygwin tree.  I cannot provide any useful output since it 
>appears that calling the process from within gdb or through strace 
>actually keeps make from failing to fork, but make still screws up the 
>order of entry into subdirs.

I routinely check correct cygwin operation by building cygwin so I can't
reproduce this.

>2)`procps auxf` incorrectly identifies top-parent processes as 
>, even though ps and the nt process monitor shows them to be 
>valid.  However, for postgres's postmaster, the parent and *all* 
>children are labeled as  even though I can confirm that the 
>server is up and running.

A trivial test of this, which is to run "procps auwx" from a command prompt,
does not demonstrate this here.

>3)Running configure scripts using sh.exe (which is default when you 
>./configure) always hangs, whereas running them through bash.exe works 
>fine (although it does hang from time to time).  In either case, when it 
>hangs, doing ctrl-c will drop you to the command line.  However, the 
>process isn't terminated, like one would expect.  Also, it refuses to 
>obey any signal except SIGKILL.

I don't use bash very often.  I use zsh or just the command prompt.  I
can run 'sh /whereever/configure' just fine.

>Existing issues since 1.5.5:
>3)I find myself involuntarily "logged-out" of my sessions at random 
>intervals.  This is especially prevalent when doing massive recursive 
>`rm -rf`'s or `grep -rn`'s or any other form of intensive disk i/o. 
>However, whatever is causing it seems to be getting fixed, since this 
>happens less frequently then it used to.  A small kludge I use to get 
>around this is by running links.exe then using ctrl-Z to send it to a 
>stopped state.  Then if it tries to log me out, it will fail because I 
>have a stopped process.

Again, I don't see this, so I don't know how it could be fixed.

>4)lynx crashes on startup, dropping me back to the command line. 
>Running it through gdb, the segfault happens at line 81 of cygtls.cc, 
>"_last_thread->next = this" which is inside the function 
>_threadinfo::init_thread(void*).  Unfortunately, my system is in a state 
>where I cannot get make to run correctly, so trying to build a debug 
>version of lynx at this point is not feasible.  I should note that I do 
>not see this problem inside links.

Since cygtls.c is a recent addition, this is not a 1.5.5 issue.  lynx
also works fine here.

cgf

--
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: Please try the latest snapshot -- it is close to cygwin 1.5.6

[Nicholas Wourms]

Pierre A. Humblet wrote:
At 12:46 PM 12/27/2003 -0500, Christopher Faylor wrote:

I missed the 'sh -c' clue in your previous message.  Since sh uses
vfork, that indicates a vfork problem.  I've checked in some more
changes to deal with this.  It seems to do the right thing both with sh
-c and without.  It also should have the added benefit of doing the
right thing wrt deallocating the console appropriately since open_fhs
should now track the ctty usecount.  This was screwed up before,
apparently even before I started mucking with the tty stuff.
I sure do hate usage counting.

cgf


Yes, that works fine now, as does bash -c inetd.

Sorry to jump in on this, but I run into a few problems with the changes 
you made last night and one issue which has been a problem for some time 
now.

This is on my Win2k box and all problems were noticed when I logged in 
remotely via ssh (I have not tried locally).  If it makes any 
difference, the /usr/src dir, where all my project and cygwin source is 
contained, is a managed mount.

Issues from yesterday's checkin:
1)When run by itself from the command line, `make` is not forking 
properly for recursive makes, instead it aborts and returns a bogus 
HANGUP signal to the console.  This is easily seen when attempting to 
build the Cygwin tree.  I cannot provide any useful output since it 
appears that calling the process from within gdb or through strace 
actually keeps make from failing to fork, but make still screws up the 
order of entry into subdirs.

2)`procps auxf` incorrectly identifies top-parent processes as 
, even though ps and the nt process monitor shows them to be 
valid.  However, for postgres's postmaster, the parent and *all* 
children are labeled as  even though I can confirm that the 
server is up and running.

3)Running configure scripts using sh.exe (which is default when you 
./configure) always hangs, whereas running them through bash.exe works 
fine (although it does hang from time to time).  In either case, when it 
hangs, doing ctrl-c will drop you to the command line.  However, the 
process isn't terminated, like one would expect.  Also, it refuses to 
obey any signal except SIGKILL.

Existing issues since 1.5.5:
3)I find myself involuntarily "logged-out" of my sessions at random 
intervals.  This is especially prevalent when doing massive recursive 
`rm -rf`'s or `grep -rn`'s or any other form of intensive disk i/o. 
However, whatever is causing it seems to be getting fixed, since this 
happens less frequently then it used to.  A small kludge I use to get 
around this is by running links.exe then using ctrl-Z to send it to a 
stopped state.  Then if it tries to log me out, it will fail because I 
have a stopped process.

4)lynx crashes on startup, dropping me back to the command line. 
Running it through gdb, the segfault happens at line 81 of cygtls.cc, 
"_last_thread->next = this" which is inside the function 
_threadinfo::init_thread(void*).  Unfortunately, my system is in a state 
where I cannot get make to run correctly, so trying to build a debug 
version of lynx at this point is not feasible.  I should note that I do 
not see this problem inside links.

Although I'm further investigating these problems, I thought I might 
share them since the next release is being discussed.

Cheers,
Nicholas


--
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: Please try the latest snapshot -- it is close to cygwin 1.5.6

[Pierre A. Humblet]

At 12:46 PM 12/27/2003 -0500, Christopher Faylor wrote:
>
>I missed the 'sh -c' clue in your previous message.  Since sh uses
>vfork, that indicates a vfork problem.  I've checked in some more
>changes to deal with this.  It seems to do the right thing both with sh
>-c and without.  It also should have the added benefit of doing the
>right thing wrt deallocating the console appropriately since open_fhs
>should now track the ctty usecount.  This was screwed up before,
>apparently even before I started mucking with the tty stuff.
>
>I sure do hate usage counting.
>
>cgf

Yes, that works fine now, as does bash -c inetd.

However when I launch inetd from an rxvt window running bash, or
from a Dos window running cygwin.bat with tty, I still see tty handles
in inetd.

CYGWIN_ME-4.90 hpn5170x 1.5.6(0.108/3/2) 2003-12-27 17:25 i686 unknown unknown Cygwin

I ran   strace -o trace rxvt -d :0 -e bash 
followed by inetd in the rxvt window.

The trace, available on http://mysite.verizon.net/phumblet/trace,
shows that the usecount is off by one. 

Correct run (bash -c inetd):
  159  220557 [main] inetd 34889607 setsid: sid 34889607, pgid 34889607, ctty -1, 
open_fhs 3
  168  220725 [main] inetd 34889607 fhandler_tty_slave::close: /dev/tty2 closed, 
decremented open_fhs 2, usecount 2

Incorrect run (under rxvt)
  167   88587 [main] inetd 34937947 setsid: sid 34937947, pgid 34937947, ctty -1, 
open_fhs 3
  159   88746 [main] inetd 34937947 fhandler_tty_slave::close: /dev/tty2 closed, 
decremented open_fhs 2, usecount 3


Pierre


--
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: Please try the latest snapshot -- it is close to cygwin 1.5.6

[Christopher Faylor]

On Fri, Dec 26, 2003 at 10:27:51PM -0500, Pierre A. Humblet wrote:
>At 09:40 PM 12/26/2003 -0500, Christopher Faylor wrote:
>>
>>I tried the current CVS version and I don't see any stray tty garbage
>>with inetd.  I never tried this with an older snapshot, however, so I
>>don't know if I would have been lucky before.  I did try a much simpler
>>test case which worked incorrectly with CYGWIN=tty and correctly after
>>today's initial setsid change.
>
>Here both exim and inetd are still off, with
>
>CYGWIN_ME-4.90 hpn5170x 1.5.6(0.108/3/2) 2003-12-26 22:04 i686 unknown unknown Cygwin
>
>The trace of sh -c inetd in on http://mysite.verizon.net/phumblet/trace
>
>The problem is the same, AFAICS there is an unaccounted for jump in usecount.
>
>  177  298078 [main] SH 480747 fhandler_tty_slave::open: /dev/tty0 opened, 
> incremented open_fhs 4, archetype usecount 4
>  178  336409 [main] sh 480747 fhandler_tty_slave::dup: incremented open_fhs 5, 
> archetype usecount 6

I missed the 'sh -c' clue in your previous message.  Since sh uses
vfork, that indicates a vfork problem.  I've checked in some more
changes to deal with this.  It seems to do the right thing both with sh
-c and without.  It also should have the added benefit of doing the
right thing wrt deallocating the console appropriately since open_fhs
should now track the ctty usecount.  This was screwed up before,
apparently even before I started mucking with the tty stuff.

I sure do hate usage counting.

cgf

--
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: Please try the latest snapshot -- it is close to cygwin 1.5.6

[Christopher Faylor]

On Sat, Dec 27, 2003 at 05:29:56PM +0100, Philippe Torche wrote:
>>So, if you were just reporting this as a data point, then thanks.  If
>>you are expecting me to do something about it, then, you will,
>>unfortunately, be disappointed.
>:-( Not you but other maybe !

Ok.  I'll just ignore your periodic reports of the same problem from now
on.

Or, if you want to send me a 4 Xeon system, I'll look into the problem.
This is not something that can be easily debugged remotely.

cgf

--
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: Please try the latest snapshot -- it is close to cygwin 1.5.6

[Philippe Torche]

Christopher Faylor wrote:
On Fri, Dec 26, 2003 at 05:37:36PM +0100, Philippe Torche wrote:

Christopher Faylor wrote:

The subject says it all.

I'm hoping to release cygwin 1.5.6 shortly after Christmas.
I've tested it (CVS version 12:35 GMT + 1) on our 4 Xeon on W2003S and 
unfortunately my previous test case (run_t.sh and t.sh) always fails. 
I've replace bash with sh and no problem anymore (not have wait enough 
maybe) ! A bash bug ?


Let me be extremely clear about this again: I don't have a 4 Xeon
processor running W2003S.  I will not be able to test this and I,
frankly, don't care much about this corner case -- especially if it is
not a regression from previous releases.
So, if you were just reporting this as a data point, then thanks.  If
you are expecting me to do something about it, then, you will,
unfortunately, be disappointed.
:-( Not you but other maybe ! If you show old threads, I'm not alone 
with this problem ! I can't give access to a multi CPU computer (client 
machine), but maybe somebody can ?


The test suite runs soon happily (except now 3 cases) with my Athlon on 
WinXP, and I'm preparing to run it tomorrow on our 4 Xeon.
:-) The test case give me the same result


I think I will have to give a gold star to the person who figures out
why those three cases are "failing".  It really isn't that hard.


--
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: Please try the latest snapshot -- it is close to cygwin 1.5.6

[Pierre A. Humblet]

At 09:40 PM 12/26/2003 -0500, Christopher Faylor wrote:
>
>I tried the current CVS version and I don't see any stray tty garbage
>with inetd.  I never tried this with an older snapshot, however, so I
>don't know if I would have been lucky before.  I did try a much simpler
>test case which worked incorrectly with CYGWIN=tty and correctly after
>today's initial setsid change.

Here both exim and inetd are still off, with

CYGWIN_ME-4.90 hpn5170x 1.5.6(0.108/3/2) 2003-12-26 22:04 i686 unknown unknown Cygwin

The trace of sh -c inetd in on http://mysite.verizon.net/phumblet/trace

The problem is the same, AFAICS there is an unaccounted for jump in usecount.

  177  298078 [main] SH 480747 fhandler_tty_slave::open: /dev/tty0 opened, incremented 
open_fhs 4, archetype usecount 4
  178  336409 [main] sh 480747 fhandler_tty_slave::dup: incremented open_fhs 5, 
archetype usecount 6

The trace also shows e.g. open_fhs -3

Still waiting for exim to misbehave.

Pierre
 

--
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: Please try the latest snapshot -- it is close to cygwin 1.5.6

[Pierre A. Humblet]

On Fri, Dec 26, 2003 at 09:40:10PM -0500, Christopher Faylor wrote:
> On Fri, Dec 26, 2003 at 09:13:36PM -0500, Pierre A. Humblet wrote:
> >At 05:59 PM 12/26/2003 -0500, Christopher Faylor wrote:
> >>I added strace debugging.  You can use that as a clue for what I was
> >>talking about and make it visible if you can't run exim under strace.
> >
> >I put a try_to_debug(1). Waiting for something to happen.
> 
> Thanks, for debugging this but that wasn't specifically what I was
> talking about.  If you go back and read the message, you'll see that I
> was talking about your 'get_proc_lock' problem.

Yes, I put the try_to_debug just after the
 system_printf ("couldn't get proc lock

By the way, I never saw any problems with exim on NT4 either...

> >I looked at your latest change in syscalls.cc. 
> >It seems to me that setsid should simply call close all the time if (cygheap->ctty)
> >and let close() take care of usecount.
> 
> I had already checked in a change to this effect but I missed...

The latest change I saw was not decrementing usecount at all, so it wouldn't do
the right thing if inetd closes the tty after calling setsid
 
> >Ditto in pinfo::set_ctty where a problem similar to the one you
> >addressed also exists.
> 
> this.  Thanks.  I've checked in a new fix as well as a similar change
> for close_all_files.
> 
> >I don't think that will take care of everything, but I can't follow
> >what's happening when tracing sh -c inetd
> 
> I tried the current CVS version and I don't see any stray tty garbage
> with inetd.  I never tried this with an older snapshot, however, so I
> don't know if I would have been lucky before.  I did try a much simpler
> test case which worked incorrectly with CYGWIN=tty and correctly after
> today's initial setsid change.

OK, I'll run cvs update.

Pierre


--
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: Please try the latest snapshot -- it is close to cygwin 1.5.6

[Christopher Faylor]

On Fri, Dec 26, 2003 at 09:13:36PM -0500, Pierre A. Humblet wrote:
>At 05:59 PM 12/26/2003 -0500, Christopher Faylor wrote:
>>I added strace debugging.  You can use that as a clue for what I was
>>talking about and make it visible if you can't run exim under strace.
>
>I put a try_to_debug(1). Waiting for something to happen.

Thanks, for debugging this but that wasn't specifically what I was
talking about.  If you go back and read the message, you'll see that I
was talking about your 'get_proc_lock' problem.

>>>Also, while running sysinternals I noticed to the exim daemon still had tty
>>>related handles, despite setsid(). Ditto for inetd.
>>
>>Calling setsid does not automatically eliminate tty handles.
>
>This is what inetd does:
>   if (setsid() == -1)
>   return (-1);
>
>   if (!noclose && (fd = open(PATH_DEVNULL, O_RDWR, 0)) != -1) {
>   (void)dup2(fd, STDIN_FILENO);
>   (void)dup2(fd, STDOUT_FILENO);
>   (void)dup2(fd, STDERR_FILENO);
>***
>Before your last changes, strace was showing 
>  160  282749 [main] inetd 34569887 close: close (2)
>  361  283110 [main] inetd 34569887 fhandler_tty_slave::close: decremented open_fhs 
> 0, archetype usecount 2
>  198  283308 [main] inetd 34569887 fhandler_tty_slave::close: just exiting because 
> archetype usecount is > 0
>  163  283471 [main] inetd 34569887 close: 0 = close (2)
>  160  283631 [main] inetd 34569887 dtable::dup2: 2 = dup2 (3, 2)
>***
>
>Now usecount is even higher
>
>  159  292878 [main] inetd 1086339 close: close (2)
>  181  293059 [main] inetd 1086339 fhandler_tty_slave::close: decremented open_fhs 0, 
> archetype usecount 3
>  313  293372 [main] inetd 1086339 fhandler_tty_slave::close: just returning because 
> archetype usecount is > 0
>  175  293547 [main] inetd 1086339 close: 0 = close (2)
>  158  293705 [main] inetd 1086339 dtable::dup2: 2 = dup2 (3, 2)
>
>
>I looked at your latest change in syscalls.cc. 
>It seems to me that setsid should simply call close all the time if (cygheap->ctty)
>and let close() take care of usecount.

I had already checked in a change to this effect but I missed...

>Ditto in pinfo::set_ctty where a problem similar to the one you
>addressed also exists.

this.  Thanks.  I've checked in a new fix as well as a similar change
for close_all_files.

>I don't think that will take care of everything, but I can't follow
>what's happening when tracing sh -c inetd

I tried the current CVS version and I don't see any stray tty garbage
with inetd.  I never tried this with an older snapshot, however, so I
don't know if I would have been lucky before.  I did try a much simpler
test case which worked incorrectly with CYGWIN=tty and correctly after
today's initial setsid change.

cgf

--
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: Please try the latest snapshot -- it is close to cygwin 1.5.6

[Christopher Faylor]

On Fri, Dec 26, 2003 at 05:59:59PM -0500, Christopher Faylor wrote:
>On Fri, Dec 26, 2003 at 03:46:41PM -0500, Pierre A.  Humblet wrote:
>>Also, while running sysinternals I noticed to the exim daemon still had
>>tty related handles, despite setsid().  Ditto for inetd.
>
>Calling setsid does not automatically eliminate tty handles.

I made some more changes to the tty code to eliminate a long-standing
handle leak when CYGWIN=tty.  I also *think* I eliminated a source
of opened tty handles but I haven't checked the inetd case and need
to go back to doing something besides working on cygwin.

I haven't been able to duplicate any problems with exim on any of my
NT-like systems, which is hardly surprising, since I know nothing about
it or how to set it up.

cgf

--
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: Please try the latest snapshot -- it is close to cygwin 1.5.6

[Pierre A. Humblet]

At 05:59 PM 12/26/2003 -0500, Christopher Faylor wrote:
>
>I added strace debugging.  You can use that as a clue for what I was
>talking about and make it visible if you can't run exim under strace.

I put a try_to_debug(1). Waiting for something to happen.


>>Also, while running sysinternals I noticed to the exim daemon still had tty
>>related handles, despite setsid(). Ditto for inetd.
>
>Calling setsid does not automatically eliminate tty handles.
>

This is what inetd does:
if (setsid() == -1)
return (-1);

if (!noclose && (fd = open(PATH_DEVNULL, O_RDWR, 0)) != -1) {
(void)dup2(fd, STDIN_FILENO);
(void)dup2(fd, STDOUT_FILENO);
(void)dup2(fd, STDERR_FILENO);
***
Before your last changes, strace was showing 
  160  282749 [main] inetd 34569887 close: close (2)
  361  283110 [main] inetd 34569887 fhandler_tty_slave::close: decremented open_fhs 0, 
archetype usecount 2
  198  283308 [main] inetd 34569887 fhandler_tty_slave::close: just exiting because 
archetype usecount is > 0
  163  283471 [main] inetd 34569887 close: 0 = close (2)
  160  283631 [main] inetd 34569887 dtable::dup2: 2 = dup2 (3, 2)
***

Now usecount is even higher

  159  292878 [main] inetd 1086339 close: close (2)
  181  293059 [main] inetd 1086339 fhandler_tty_slave::close: decremented open_fhs 0, 
archetype usecount 3
  313  293372 [main] inetd 1086339 fhandler_tty_slave::close: just returning because 
archetype usecount is > 0
  175  293547 [main] inetd 1086339 close: 0 = close (2)
  158  293705 [main] inetd 1086339 dtable::dup2: 2 = dup2 (3, 2)


I looked at your latest change in syscalls.cc. 
It seems to me that setsid should simply call close all the time if (cygheap->ctty)
and let close() take care of usecount.
Ditto in pinfo::set_ctty where a problem similar to the one you addressed also exists.

I don't think that will take care of everything, but I can't follow what's happening
when tracing sh -c inetd

Usecount jumps by 2 when open_fhs goes up by 1.

  179  854139 [main] SH 34649867 fhandler_tty_slave::open: /dev/tty1 opened, 
incremented open_fhs 3, archetype usecount 4

  237  880231 [main] sh 34649867 fhandler_tty_slave::dup: incremented open_fhs 4, 
archetype usecount 6

The trace is on http://mysite.verizon.net/phumblet/trace if interested.

Pierre


--
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: Please try the latest snapshot -- it is close to cygwin 1.5.6

[Christopher Faylor]

On Fri, Dec 26, 2003 at 03:46:41PM -0500, Pierre A. Humblet wrote:
>On Wed, Dec 24, 2003 at 06:27:59PM -0500, Christopher Faylor wrote:
>> On Wed, Dec 24, 2003 at 06:15:24PM -0500, Pierre A. Humblet wrote:
>> >At 11:59 AM 12/24/2003 -0500, Christopher Faylor wrote:
>> >>On Wed, Dec 24, 2003 at 10:29:51AM -0500, Pierre A. Humblet wrote:
>> >>>On Tue, Dec 23, 2003 at 05:28:16PM -0500, Christopher Faylor wrote:
>>  The subject says it all.
>>  
>>  I'm hoping to release cygwin 1.5.6 shortly after Christmas.
>> >>>
>> >>>On WinMe the queue runner forked by the exim daemon still occasionally 
>> >>>produces a popup indicating an error in Cygwin1.dll
>> >>
>> >>"a popup indicating an error"...?
>> >>
>> >>Not too helpful.
>> >
>> >It has happened once more, but differently. ps shows the child as defunct.
>> >Sysinternals shows everything normal, pinfo exists in the child.
>> >There is no fork failure, in fact the one I mentioned earlier is the only
>> >one out of 17070 runs. 
>> >
>> >This time when I killed the daemon (just to see), I got
>> > 330495 [main] exim 34658275 proc_subproc: couldn't get proc lock.
>> >Something is wrong.
>> > 330520 [main] exim 34658275 proc_subproc: couldn't get proc lock.
>> >Something is wrong
>> 
>> If you have the time could you add some more debugging output to the
>> failing cases that lead to this message and try running it with that?
>
>I updated from cvs and noticed you had already added debug info.

I added strace debugging.  You can use that as a clue for what I was
talking about and make it visible if you can't run exim under strace.

>CYGWIN_ME-4.90 hpn5170x 1.5.6(0.108/3/2) 2003-12-26 12:15 i686 unknown unknown Cygwin
>
>-996371854 [main] exim 219879 proc_subproc: couldn't get proc lock. what 4, val 
>1628435976
>-996369556 [main] exim 219879 proc_subproc: couldn't get proc lock. what 4, val 
>1628435976
>
>Also, while running sysinternals I noticed to the exim daemon still had tty
>related handles, despite setsid(). Ditto for inetd.

Calling setsid does not automatically eliminate tty handles.

cgf

--
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: Please try the latest snapshot -- it is close to cygwin 1.5.6

[Pierre A. Humblet]

On Wed, Dec 24, 2003 at 06:27:59PM -0500, Christopher Faylor wrote:
> On Wed, Dec 24, 2003 at 06:15:24PM -0500, Pierre A. Humblet wrote:
> >At 11:59 AM 12/24/2003 -0500, Christopher Faylor wrote:
> >>On Wed, Dec 24, 2003 at 10:29:51AM -0500, Pierre A. Humblet wrote:
> >>>On Tue, Dec 23, 2003 at 05:28:16PM -0500, Christopher Faylor wrote:
>  The subject says it all.
>  
>  I'm hoping to release cygwin 1.5.6 shortly after Christmas.
> >>>
> >>>On WinMe the queue runner forked by the exim daemon still occasionally 
> >>>produces a popup indicating an error in Cygwin1.dll
> >>
> >>"a popup indicating an error"...?
> >>
> >>Not too helpful.
> >
> >It has happened once more, but differently. ps shows the child as defunct.
> >Sysinternals shows everything normal, pinfo exists in the child.
> >There is no fork failure, in fact the one I mentioned earlier is the only
> >one out of 17070 runs. 
> >
> >This time when I killed the daemon (just to see), I got
> > 330495 [main] exim 34658275 proc_subproc: couldn't get proc lock.
> >Something is wrong.
> > 330520 [main] exim 34658275 proc_subproc: couldn't get proc lock.
> >Something is wrong
> 
> If you have the time could you add some more debugging output to the
> failing cases that lead to this message and try running it with that?

I updated from cvs and noticed you had already added debug info.

CYGWIN_ME-4.90 hpn5170x 1.5.6(0.108/3/2) 2003-12-26 12:15 i686 unknown unknown Cygwin

-996371854 [main] exim 219879 proc_subproc: couldn't get proc lock. what 4, val 
1628435976
-996369556 [main] exim 219879 proc_subproc: couldn't get proc lock. what 4, val 
1628435976

Also, while running sysinternals I noticed to the exim daemon still had tty
related handles, despite setsid(). Ditto for inetd.

Pierre 

--
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: Please try the latest snapshot -- it is close to cygwin 1.5.6

[Dr. Volker Zell]

> "Christopher" == Christopher Faylor <[EMAIL PROTECTED]> writes:

Christopher> The subject says it all.
Christopher> I'm hoping to release cygwin 1.5.6 shortly after Christmas.

I just checked cygwin1-20031225

Apache (1.3.24-5) stackdumps right away and wmaker (0.80.0-2) reproducable
after 5 !!! minutes. Sorry a party is going on, no more information right now...

A happy new year to all of you.

Christopher> cgf

Ciao
  Volker


--
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: Please try the latest snapshot -- it is close to cygwin 1.5.6

[Christopher Faylor]

On Fri, Dec 26, 2003 at 05:37:36PM +0100, Philippe Torche wrote:
>Christopher Faylor wrote:
>>The subject says it all.
>>
>>I'm hoping to release cygwin 1.5.6 shortly after Christmas.
>
>I've tested it (CVS version 12:35 GMT + 1) on our 4 Xeon on W2003S and 
>unfortunately my previous test case (run_t.sh and t.sh) always fails. 

Let me be extremely clear about this again: I don't have a 4 Xeon
processor running W2003S.  I will not be able to test this and I,
frankly, don't care much about this corner case -- especially if it is
not a regression from previous releases.

So, if you were just reporting this as a data point, then thanks.  If
you are expecting me to do something about it, then, you will,
unfortunately, be disappointed.

>The test suite runs soon happily (except now 3 cases) with my Athlon on 
>WinXP, and I'm preparing to run it tomorrow on our 4 Xeon.

I think I will have to give a gold star to the person who figures out
why those three cases are "failing".  It really isn't that hard.

--
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: Please try the latest snapshot -- it is close to cygwin 1.5.6

[Philippe Torche]

Christopher Faylor wrote:
The subject says it all.

I'm hoping to release cygwin 1.5.6 shortly after Christmas.

cgf

I've tested it (CVS version 12:35 GMT + 1) on our 4 Xeon on W2003S and 
unfortunately my previous test case (run_t.sh and t.sh) always fails. 
The test suite runs soon happily (except now 3 cases) with my Athlon on 
WinXP, and I'm preparing to run it tomorrow on our 4 Xeon.

Now, I should go, I'll will continue tomorrow.

Thanks you very much, Merry Christmas to all of you.

--
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: Please try the latest snapshot -- it is close to cygwin 1.5.6

[Christopher Faylor]

On Thu, Dec 25, 2003 at 04:05:24PM +0930, Trevor Forbes wrote:
>I run the testsuite when I built the dll which gives:
>
>FAIL: msgtest.c (execute)
>FAIL: semtest.c (execute)
>FAIL: shmtest.c (execute)
>FAIL: pthread/mainthreadexits.c (execute)

I think we've already been down the testsuite route.

The {msg,sem,shm}test failures should be obvious.

I'm working on mainthreadexits.

cgf

--
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: Please try the latest snapshot -- it is close to cygwin 1.5.6

[Trevor Forbes]

I was running the open_posix_testsuite against the current "homebuilt"
cygwin1.dll but I get the same error if I use the new dll to build
itself. It only happens randomly to gcc.exe but it always errors at the
same location "0x61085fba". 

I run the testsuite when I built the dll which gives:

FAIL: msgtest.c (execute)
FAIL: semtest.c (execute)
FAIL: shmtest.c (execute)
FAIL: pthread/mainthreadexits.c (execute)


=== winsup Summary ===

# of expected passes259
# of unexpected failures4
# of expected failures  14

The pthread test is the only abnormal failure as I am not using the
cygserver. I looked at the mainthreadexits.c test and I was not sure if
the test was correct. So that's what lead me to try out the
open_posix_testsuite.

I am currently "Googling" for different debugging methods and
contemplating having a Xmas drink or two. I tried the
"how-to-debug-cygwin.txt" but GDB did not provide any useful
information. 

Sorry I am not more helpful. 

Merry Xmas to all. 

Trevor




 


--
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: Please try the latest snapshot -- it is close to cygwin 1.5.6

[Christopher Faylor]

On Thu, Dec 25, 2003 at 09:07:51AM +0930, Trevor Forbes wrote:
>Using a CVS Head version, I get a popup with:
>
>The instruction at "0x61085fba" referenced memory at "0x61002f90".  The
>memory could not be "written"
>
>$ addr2line -e /bin/cygwin1.dll 61085fba
>/src/cygwin/obj/obj-org/i686-pc-cygwin/winsup/cygwin/../../../../../src/
>winsup/cygwin/shm.cc:331
>
>/* Try allocating memory before calling cygserver.  */ shm_shmid_list
>*ssh_new_entry = new (shm_shmid_list); if (!ssh_new_entry) { set_errno
>(ENOMEM);
>331>  return -1;
>}
>
>
>I am not sure if this is helpful...

You get a popup with WHAT?  Every single cygwin program?

cgf

--
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: Please try the latest snapshot -- it is close to cygwin 1.5.6

[Trevor Forbes]

Using a CVS Head version, I get a popup with:

The instruction at "0x61085fba" referenced memory at "0x61002f90". The
memory could not be "written"

$ addr2line -e /bin/cygwin1.dll 61085fba
/src/cygwin/obj/obj-org/i686-pc-cygwin/winsup/cygwin/../../../../../src/
winsup/cygwin/shm.cc:331

  /* Try allocating memory before calling cygserver. */
  shm_shmid_list *ssh_new_entry = new (shm_shmid_list);
  if (!ssh_new_entry)
{
  set_errno (ENOMEM);
331>  return -1;
}


I am not sure if this is helpful... 


Trevor




--
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: Please try the latest snapshot -- it is close to cygwin 1.5.6

[Christopher Faylor]

On Wed, Dec 24, 2003 at 06:15:24PM -0500, Pierre A. Humblet wrote:
>At 11:59 AM 12/24/2003 -0500, Christopher Faylor wrote:
>>On Wed, Dec 24, 2003 at 10:29:51AM -0500, Pierre A. Humblet wrote:
>>>On Tue, Dec 23, 2003 at 05:28:16PM -0500, Christopher Faylor wrote:
 The subject says it all.
 
 I'm hoping to release cygwin 1.5.6 shortly after Christmas.
>>>
>>>On WinMe the queue runner forked by the exim daemon still occasionally 
>>>produces a popup indicating an error in Cygwin1.dll
>>
>>"a popup indicating an error"...?
>>
>>Not too helpful.
>
>It has happened once more, but differently. ps shows the child as defunct.
>Sysinternals shows everything normal, pinfo exists in the child.
>There is no fork failure, in fact the one I mentioned earlier is the only
>one out of 17070 runs. 
>
>This time when I killed the daemon (just to see), I got
> 330495 [main] exim 34658275 proc_subproc: couldn't get proc lock.
>Something is wrong.
> 330520 [main] exim 34658275 proc_subproc: couldn't get proc lock.
>Something is wrong

If you have the time could you add some more debugging output to the
failing cases that lead to this message and try running it with that?

cgf

--
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: Please try the latest snapshot -- it is close to cygwin 1.5.6

[Pierre A. Humblet]

At 11:59 AM 12/24/2003 -0500, Christopher Faylor wrote:
>On Wed, Dec 24, 2003 at 10:29:51AM -0500, Pierre A. Humblet wrote:
>>On Tue, Dec 23, 2003 at 05:28:16PM -0500, Christopher Faylor wrote:
>>> The subject says it all.
>>> 
>>> I'm hoping to release cygwin 1.5.6 shortly after Christmas.
>>
>>On WinMe the queue runner forked by the exim daemon still occasionally 
>>produces a popup indicating an error in Cygwin1.dll
>
>"a popup indicating an error"...?
>
>Not too helpful.

It has happened once more, but differently. ps shows the child as defunct.
Sysinternals shows everything normal, pinfo exists in the child.
There is no fork failure, in fact the one I mentioned earlier is the only
one out of 17070 runs. 

This time when I killed the daemon (just to see), I got
 330495 [main] exim 34658275 proc_subproc: couldn't get proc lock.
Something is wrong.
 330520 [main] exim 34658275 proc_subproc: couldn't get proc lock.
Something is wrong

Pierre
 

--
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: Please try the latest snapshot -- it is close to cygwin 1.5.6

[Christopher Faylor]

On Wed, Dec 24, 2003 at 04:20:37PM -0500, Pierre A. Humblet wrote:
>At 11:59 AM 12/24/2003 -0500, you wrote:
>>On Wed, Dec 24, 2003 at 10:29:51AM -0500, Pierre A. Humblet wrote:
>>>On Tue, Dec 23, 2003 at 05:28:16PM -0500, Christopher Faylor wrote:
The subject says it all.

I'm hoping to release cygwin 1.5.6 shortly after Christmas.
>>>
>>>On WinMe the queue runner forked by the exim daemon still occasionally
>>>produces a popup indicating an error in Cygwin1.dll
>>
>>"a popup indicating an error"...?
>>
>>Not too helpful.
>
>I tried stracing the child, but got the same popup for strace.  In
>previous trials I had failed to attach to the child from gdb.

Have you rebuilt strace?  It was broken in 1.5.5.

>After pushing the close button (on the child), I noticed that the
>parent (daemon) exim showed too many pinfos.  It had 7 pinfos mapped
>files, although it had no running child.  I then killed -9 it, there
>was no error message.

That's not necessarily a problem if exim had unreaped zombies.

>The exim log shows a few interesting things:
>
>The last mention of the child pid was 
>(that may be misleading, reuse is a possibility)
>2003-12-24 13:29:08 Start queue run: pid=159063
>2003-12-24 13:29:08 End queue run: pid=159063
>
>At around the time when I started looking into it, I see
>
>2003-12-24 15:35:26 Start queue run: pid=153375
>2003-12-24 15:35:26 End queue run: pid=153375
>2003-12-24 15:36:26 Start queue run: pid=34403247
>2003-12-24 15:36:26 End queue run: pid=34403247
>
>Note a 5 min gap here, then
>
>2003-12-24 15:42:26 daemon: fork of queue-runner process failed: Resource
>temporarily unavailable
>2003-12-24 15:43:27 Start queue run: pid=176243
>2003-12-24 15:43:27 End queue run: pid=176243
>2003-12-24 15:44:27 Start queue run: pid=157315
>2003-12-24 15:44:27 End queue run: pid=157315
>2003-12-24 15:45:27 Start queue run: pid=153375
>2003-12-24 15:45:27 End queue run: pid=153375
>2003-12-24 15:46:27 Start queue run: pid=34403247
>2003-12-24 15:46:27 End queue run: pid=34403247
>2003-12-24 15:47:27 Start queue run: pid=178263
>2003-12-24 15:47:27 End queue run: pid=178263
>There is again a gap here.
>Next is normal, I killed -9 the parent.
>2003-12-24 15:54:23 50 select() failures: Bad file descriptor
>
>There were no other gaps since 12:36:58, when I had started the daemon.

There's really nothing here that is useful, unfortunately.
Have you ever tried running exim via strace rather than trying
to attach to it when it has a problem?

cgf

--
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: Please try the latest snapshot -- it is close to cygwin 1.5.6

[Pierre A. Humblet]

At 11:59 AM 12/24/2003 -0500, you wrote:
>On Wed, Dec 24, 2003 at 10:29:51AM -0500, Pierre A. Humblet wrote:
>>On Tue, Dec 23, 2003 at 05:28:16PM -0500, Christopher Faylor wrote:
>>> The subject says it all.
>>> 
>>> I'm hoping to release cygwin 1.5.6 shortly after Christmas.
>>
>>On WinMe the queue runner forked by the exim daemon still occasionally 
>>produces a popup indicating an error in Cygwin1.dll
>
>"a popup indicating an error"...?
>
>Not too helpful.

Here are a few more tidbits.
The exact popup text is:

Exim-4 has caused an error in CYGWIN1.DLL
Exim-4 will now close
If you continue to experience problems,
try restarting your computer 

ps shows the forked process in a normal state.

sysinternals shows it too. There is only one thread handle
and the pinfo mapped file is gone (it is still visible in the
parent). The cygwin & user mapped files are still there.

I tried stracing the child, but got the same popup for strace.
In previous trials I had failed to attach to the child from gdb.

After pushing the close button (on the child), I noticed 
that the parent (daemon) exim showed too many pinfos.
It had 7 pinfos mapped files, although it had no running child.
I then killed -9 it, there was no error message.

The exim log shows a few interesting things:

The last mention of the child pid was 
(that may be misleading, reuse is a possibility)
2003-12-24 13:29:08 Start queue run: pid=159063
2003-12-24 13:29:08 End queue run: pid=159063

At around the time when I started looking into it, I see

2003-12-24 15:35:26 Start queue run: pid=153375
2003-12-24 15:35:26 End queue run: pid=153375
2003-12-24 15:36:26 Start queue run: pid=34403247
2003-12-24 15:36:26 End queue run: pid=34403247

Note a 5 min gap here, then

2003-12-24 15:42:26 daemon: fork of queue-runner process failed: Resource
temporarily unavailable
2003-12-24 15:43:27 Start queue run: pid=176243
2003-12-24 15:43:27 End queue run: pid=176243
2003-12-24 15:44:27 Start queue run: pid=157315
2003-12-24 15:44:27 End queue run: pid=157315
2003-12-24 15:45:27 Start queue run: pid=153375
2003-12-24 15:45:27 End queue run: pid=153375
2003-12-24 15:46:27 Start queue run: pid=34403247
2003-12-24 15:46:27 End queue run: pid=34403247
2003-12-24 15:47:27 Start queue run: pid=178263
2003-12-24 15:47:27 End queue run: pid=178263
There is again a gap here.
Next is normal, I killed -9 the parent.
2003-12-24 15:54:23 50 select() failures: Bad file descriptor

There were no other gaps since 12:36:58, when I had started the
daemon.

Pierre

--
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: Please try the latest snapshot -- it is close to cygwin 1.5.6

[Christopher Faylor]

On Wed, Dec 24, 2003 at 10:29:51AM -0500, Pierre A. Humblet wrote:
>On Tue, Dec 23, 2003 at 05:28:16PM -0500, Christopher Faylor wrote:
>> The subject says it all.
>> 
>> I'm hoping to release cygwin 1.5.6 shortly after Christmas.
>
>On WinMe the queue runner forked by the exim daemon still occasionally 
>produces a popup indicating an error in Cygwin1.dll

"a popup indicating an error"...?

Not too helpful.

--
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: Please try the latest snapshot -- it is close to cygwin 1.5.6

[Pierre A. Humblet]

On Tue, Dec 23, 2003 at 05:28:16PM -0500, Christopher Faylor wrote:
> The subject says it all.
> 
> I'm hoping to release cygwin 1.5.6 shortly after Christmas.

On WinMe the queue runner forked by the exim daemon still occasionally 
produces a popup indicating an error in Cygwin1.dll

In addition kill -9  produces 

 518380 [main] exim 34647479 proc_subproc: couldn't get proc lock.  Something is wrong.
 518404 [main] exim 34647479 proc_subproc: couldn't get proc lock.  Something is wrong.
 518429 [main] exim 34647479 proc_subproc: couldn't get proc lock.  Something is wrong.

CYGWIN_ME-4.90 hpn5170x 1.5.6s(0.108/3/2) 20031223 11:45:22 

Ebenezer

--
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: Please try the latest snapshot -- it is close to cygwin 1.5.6

[Christopher Faylor]

On Tue, Dec 23, 2003 at 04:45:27PM -0600, Brian Ford wrote:
>On Tue, 23 Dec 2003, Christopher Faylor wrote:
>
>> On Tue, Dec 23, 2003 at 04:39:13PM -0600, Brian Ford wrote:
>> >Have you run the testsuite lately?  I get a heap of failures on NT4.
>> >But, in that timeframe, I certainly won't have time to look at them.
>>
>> You can safely assume that cygwin is not released without my running the
>> test suite.
>>
>> I haven't run it in the last couple of days, though.
>>
>I figured as much on both counts.

Did you figure that I was setting things up to run the test suite when
your email came in?

I was basically hoping for some more real world success or failures like
"rsync doesn't work" or "rxvt works fine".

--
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: Please try the latest snapshot -- it is close to cygwin 1.5.6

[Brian Ford]

On Tue, 23 Dec 2003, Christopher Faylor wrote:

> On Tue, Dec 23, 2003 at 04:39:13PM -0600, Brian Ford wrote:
> >Have you run the testsuite lately?  I get a heap of failures on NT4.
> >But, in that timeframe, I certainly won't have time to look at them.
>
> You can safely assume that cygwin is not released without my running the
> test suite.
>
> I haven't run it in the last couple of days, though.
>
I figured as much on both counts.

FWIW, I didn't have your latest fork.c change.  I am testing again now,
but probably won't have the results before I need to leave.

All, have a good holiday.

-- 
Brian Ford
Senior Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
Phone: 314-551-8460
Fax:   314-551-8444

--
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: Please try the latest snapshot -- it is close to cygwin 1.5.6

[Christopher Faylor]

On Tue, Dec 23, 2003 at 04:39:13PM -0600, Brian Ford wrote:
>Have you run the testsuite lately?  I get a heap of failures on NT4.
>But, in that timeframe, I certainly won't have time to look at them.

You can safely assume that cygwin is not released without my running the
test suite.

I haven't run it in the last couple of days, though.

cgf

--
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: Please try the latest snapshot -- it is close to cygwin 1.5.6

[Brian Ford]

On Tue, 23 Dec 2003, Christopher Faylor wrote:

> The subject says it all.
>
> I'm hoping to release cygwin 1.5.6 shortly after Christmas.
>
Have you run the testsuite lately?  I get a heap of failures on NT4.  But,
in that timeframe, I certainly won't have time to look at them.

lots of "child process exited abnormally" errors.

Just FYI.

-- 
Brian Ford
Senior Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
Phone: 314-551-8460
Fax:   314-551-8444

--
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/

Please try the latest snapshot -- it is close to cygwin 1.5.6

[Christopher Faylor]

The subject says it all.

I'm hoping to release cygwin 1.5.6 shortly after Christmas.

cgf

--
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: please try the latest snapshot

[Jason Tishler]

Chris,

On Fri, Jan 17, 2003 at 10:39:25PM -0500, Christopher Faylor wrote:
> On Fri, Jan 17, 2003 at 08:04:43PM -0500, Christopher Faylor wrote:
> >On Fri, Jan 17, 2003 at 04:17:27PM -0500, Jason Tishler wrote:
> >>I spoke too soon.  I'm getting segmentation faults and stuff like
> >>the following by just running ls:
> >>
> >>[snip]
> >
> >Could you get a gdb backtrace of this problem?
> 
> Nevermind.  I cd'ed around my disk like crazy until I could duplicate
> the problem.  I'm regenerating the snapshot now.

Sorry to leave you hanging, cd-ing like crazy, but I was involved in a
scheduled network maintenance operation last Friday from 8:00 PM EST to
12:00 AM EST.  Since this affected a customer facing system, I couldn't
steal any cycles to respond to your post.

Anyway, I just tried the 2003-Jan-19 snapshot.  All of the problems that
I reported in this thread appear to be corrected.

Thanks,
Jason

-- 
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D  8784 1AFD E4CC ECF4 8EF6

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: please try the latest snapshot

[Robert McNulty Junior]

It works. I can now proceed with my progrect(Making music with Cygwin,
EZPNO, and Timidity++
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf
Of Christopher Faylor
Sent: Friday, January 17, 2003 9:39 PM
To: [EMAIL PROTECTED]
Subject: Re: please try the latest snapshot


On Fri, Jan 17, 2003 at 08:04:43PM -0500, Christopher Faylor wrote:
>On Fri, Jan 17, 2003 at 04:17:27PM -0500, Jason Tishler wrote:
>>Chris,
>>
>>On Fri, Jan 17, 2003 at 02:49:24PM -0500, Jason Tishler wrote:
>>> On Fri, Jan 17, 2003 at 02:03:53PM -0500, Christopher Faylor wrote:
>>> > This should be fixed now.  It was a simple mistake, as far as I
>>> > could tell.  How does the refreshed snapshot look?
>>>
>>> Looking good!
>>
>>I spoke too soon.  I'm getting segmentation faults and stuff like the
>>following by just running ls:
>>
>>$ uname -a
>>CYGWIN_NT-5.0 TISHLERJASON 1.3.19s(0.71/3/2) 20030117 13:11:17 i686
unknown
>>$ cd src/pgsql
>>/home/jt/src/pgsql
>>$ ls
>>...
>> 636511 [unknown (0x900)] ? 2332 handle_exceptions: Exception:
STATUS_ACCESS_VIOLATION
>> 636647 [unknown (0x900)] ? 2332 handle_exceptions: Error while
dumping state (probably corrupted stack)
>
>Could you get a gdb backtrace of this problem?

Nevermind.  I cd'ed around my disk like crazy until I could duplicate the
problem.  I'm regenerating the snapshot now.

If it has this in the ChangeLog:

2003-01-17  Christopher Faylor  <[EMAIL PROTECTED]>

* cygheap.cc: Change most 'int's to 'unsigned's.
(_cmalloc): Only check for size of malloced region when calculating
budget.  Add overhead when performing the sbrk.  Previous change broke
_crealloc.

It should work.


cgf

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: please try the latest snapshot

[Christopher Faylor]

On Fri, Jan 17, 2003 at 08:04:43PM -0500, Christopher Faylor wrote:
>On Fri, Jan 17, 2003 at 04:17:27PM -0500, Jason Tishler wrote:
>>Chris,
>>
>>On Fri, Jan 17, 2003 at 02:49:24PM -0500, Jason Tishler wrote:
>>> On Fri, Jan 17, 2003 at 02:03:53PM -0500, Christopher Faylor wrote:
>>> > This should be fixed now.  It was a simple mistake, as far as I
>>> > could tell.  How does the refreshed snapshot look?
>>> 
>>> Looking good!
>>
>>I spoke too soon.  I'm getting segmentation faults and stuff like the
>>following by just running ls:
>>
>>$ uname -a
>>CYGWIN_NT-5.0 TISHLERJASON 1.3.19s(0.71/3/2) 20030117 13:11:17 i686 unknown
>>$ cd src/pgsql
>>/home/jt/src/pgsql
>>$ ls
>>...
>> 636511 [unknown (0x900)] ? 2332 handle_exceptions: Exception: 
>STATUS_ACCESS_VIOLATION
>> 636647 [unknown (0x900)] ? 2332 handle_exceptions: Error while dumping state 
>(probably corrupted stack)
>
>Could you get a gdb backtrace of this problem?

Nevermind.  I cd'ed around my disk like crazy until I could duplicate the
problem.  I'm regenerating the snapshot now.

If it has this in the ChangeLog:

2003-01-17  Christopher Faylor  <[EMAIL PROTECTED]>

* cygheap.cc: Change most 'int's to 'unsigned's.
(_cmalloc): Only check for size of malloced region when calculating
budget.  Add overhead when performing the sbrk.  Previous change broke
_crealloc.

It should work.


cgf

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: please try the latest snapshot

[Christopher Faylor]

On Fri, Jan 17, 2003 at 04:17:27PM -0500, Jason Tishler wrote:
>Chris,
>
>On Fri, Jan 17, 2003 at 02:49:24PM -0500, Jason Tishler wrote:
>> On Fri, Jan 17, 2003 at 02:03:53PM -0500, Christopher Faylor wrote:
>> > This should be fixed now.  It was a simple mistake, as far as I
>> > could tell.  How does the refreshed snapshot look?
>> 
>> Looking good!
>
>I spoke too soon.  I'm getting segmentation faults and stuff like the
>following by just running ls:
>
>$ uname -a
>CYGWIN_NT-5.0 TISHLERJASON 1.3.19s(0.71/3/2) 20030117 13:11:17 i686 unknown
>$ cd src/pgsql
>/home/jt/src/pgsql
>$ ls
>...
> 636511 [unknown (0x900)] ? 2332 handle_exceptions: Exception: 
>STATUS_ACCESS_VIOLATION
> 636647 [unknown (0x900)] ? 2332 handle_exceptions: Error while dumping state 
>(probably corrupted stack)

Could you get a gdb backtrace of this problem?

cgf

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: please try the latest snapshot

[David Rothenberger]

I am encountering sporadic segmentation faults from tools like ls and
find.  Specifically, I was invoking find as a child process from Cygwin
XEmacs, and it was getting a segmentation fault at different locations
in my (somewhat deep) directory structure.

After this started to occur, I started an rxvt window and when to the
top of the directory structure and did an 'ls'.  This also caused a
segmentation fault.

This does not happen all the time, even for that directory.  Reverting
back to 1.3.17 corrected the problem.

I will be happy to provide any additional information if instructions
for collecting the information is provided.

Dave

David Rothenberger wrote:
> 
> The latest 1-17 snapshot fixes the pipe problem for me.  No other
> problems detected so far.  Thanks!
> 
> Christopher Faylor wrote:
> >
> > The latest snapshot should fix some /etc handling problems (thanks to
> > ideas and code from Pierre Humblet), like the dreaded BSOD.  It may also
> > solve the "pipes are slow" problem.  There are also all of the fixes
> > accumulated since 1.3.18, of course.

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: please try the latest snapshot

[David Rothenberger]

The latest 1-17 snapshot fixes the pipe problem for me.  No other
problems detected so far.  Thanks!

Christopher Faylor wrote:
> 
> The latest snapshot should fix some /etc handling problems (thanks to
> ideas and code from Pierre Humblet), like the dreaded BSOD.  It may also
> solve the "pipes are slow" problem.  There are also all of the fixes
> accumulated since 1.3.18, of course.

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: please try the latest snapshot

[Jason Tishler]

Chris,

On Fri, Jan 17, 2003 at 02:49:24PM -0500, Jason Tishler wrote:
> On Fri, Jan 17, 2003 at 02:03:53PM -0500, Christopher Faylor wrote:
> > This should be fixed now.  It was a simple mistake, as far as I
> > could tell.  How does the refreshed snapshot look?
> 
> Looking good!

I spoke too soon.  I'm getting segmentation faults and stuff like the
following by just running ls:

$ uname -a
CYGWIN_NT-5.0 TISHLERJASON 1.3.19s(0.71/3/2) 20030117 13:11:17 i686 unknown
$ cd src/pgsql
/home/jt/src/pgsql
$ ls
...
 636511 [unknown (0x900)] ? 2332 handle_exceptions: Exception: 
STATUS_ACCESS_VIOLATION
 636647 [unknown (0x900)] ? 2332 handle_exceptions: Error while dumping state 
(probably corrupted stack)

Jason

-- 
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D  8784 1AFD E4CC ECF4 8EF6

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

FindFirstChangeNotification BSODs (Re: please try the latest snapshot)

[Ville Herva]

On Fri, Jan 17, 2003 at 12:52:16AM -0500, you [Christopher Faylor] wrote:
> The latest snapshot should fix some /etc handling problems (thanks to
> ideas and code from Pierre Humblet), like the dreaded BSOD.  It may also
> solve the "pipes are slow" problem.  There are also all of the fixes
> accumulated since 1.3.18, of course.
> 
> If I don't hear too many whines about this snapshot, it may become
> 1.3.19.

I've got a contact at Microsoft support who is listening about these BSOD
issues (I was quite surprised they actually answered when I submitted a
report on cygwin causing BSODs...). They are not quite keen on installing
the whole cygwin suite (be it free or not), though. However, if some of you
who have played with the /etc FindFirstChangeNotification stuff would have
the time and patience to wrap up a small .exe (preferably with source of
source) that reproduces the problem, I think they would be very interested
(only and assumption based on the pretty good feedback I've gotten so far).

I'm afraid I'm too busy and unversed to do that myself


-- v --

[EMAIL PROTECTED]

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: please try the latest snapshot

[Jason Tishler]

Chris,

On Fri, Jan 17, 2003 at 02:03:53PM -0500, Christopher Faylor wrote:
> This should be fixed now.  It was a simple mistake, as far as I could
> tell.  How does the refreshed snapshot look?

Looking good!

Thanks,
Jason

-- 
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D  8784 1AFD E4CC ECF4 8EF6

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: please try the latest snapshot

[Christopher Faylor]

On Fri, Jan 17, 2003 at 10:44:55AM -0500, Jason Tishler wrote:
>Chris,
>
>On Fri, Jan 17, 2003 at 12:52:16AM -0500, Christopher Faylor wrote:
>> If I don't hear too many whines about this snapshot, it may become
>> 1.3.19.
>
>The 2003-Jan-17 snapshot seems to fix the symlink problem that I
>mentioned in:
>
>http://cygwin.com/ml/cygwin/2003-01/msg00827.html
>
>However, sshd is failing with the following in sshd.log:
>
>C:\cygwin\usr\sbin\sshd.exe: *** internal error
>
>I know that the above is not much to go on, but I thought that it was
>better to start whining sooner rather that later. :,)  I will try to dig
>deeper.

This should be fixed now.  It was a simple mistake, as far as I could tell.
How does the refreshed snapshot look?

cgf

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: please try the latest snapshot

[Eric Hanchrow]

> "cgf" == Christopher Faylor <[EMAIL PROTECTED]> writes:

cgf> The latest snapshot should fix some /etc handling problems
cgf> (thanks to ideas and code from Pierre Humblet), like the
cgf> dreaded BSOD.

Where can I read more about that BSOD problem?  I'm getting
blue-screens myself and would like to see if the problem you fixed
seems like the problem I've been having.

-- 
PGP Fingerprint: 3E7B A3F3 96CA 8958 ACC5  C8BD 6337 0041 C01C 5276

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: please try the latest snapshot

[Dan Holmsand]

Dan Holmsand wrote:

Indeed it does seem to stop the BSODding on my machines. Thanks!


Still no BSOD.

However, now I'm having trouble with postgresql: the postmaster dies as 
soon as I exit psql. Reverting to a cygwin1.dll built from cvs from four 
days ago fixes the problem.

Here is what the postmaster.log says:

LOG:  server process (pid 1440) was terminated by signal 11
LOG:  terminating any other active server processes
LOG:  all server processes terminated; reinitializing shared memory and 
semaphores
IpcMemoryCreate: shmget(key=5432001, size=1441792, 03600) failed: Not 
enough core

This error usually means that PostgreSQL's request for a shared
memory segment exceeded available memory or swap space.
To reduce the request size (currently 1441792 bytes), reduce
PostgreSQL's shared_buffers parameter (currently 64) and/or
its max_connections parameter (currently 32).

The PostgreSQL Administrator's Guide contains more information about
shared memory configuration.

/dan



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: please try the latest snapshot

[Jason Tishler]

Chris,

On Fri, Jan 17, 2003 at 12:52:16AM -0500, Christopher Faylor wrote:
> If I don't hear too many whines about this snapshot, it may become
> 1.3.19.

The 2003-Jan-17 snapshot seems to fix the symlink problem that I
mentioned in:

http://cygwin.com/ml/cygwin/2003-01/msg00827.html

However, sshd is failing with the following in sshd.log:

C:\cygwin\usr\sbin\sshd.exe: *** internal error

I know that the above is not much to go on, but I thought that it was
better to start whining sooner rather that later. :,)  I will try to dig
deeper.

Thanks,
Jason

-- 
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D  8784 1AFD E4CC ECF4 8EF6

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: please try the latest snapshot

[Dan Holmsand]

Christopher Faylor wrote:

The latest snapshot should fix some /etc handling problems (thanks to
ideas and code from Pierre Humblet), like the dreaded BSOD.  It may also
solve the "pipes are slow" problem.  There are also all of the fixes
accumulated since 1.3.18, of course.


Indeed it does seem to stop the BSODding on my machines. Thanks!

/dan



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: please try the latest snapshot

[Christopher Faylor]

On Fri, Jan 17, 2003 at 05:54:57PM +1100, Eugene Rosenzweig wrote:
>It does fix the slow pipes on my machine when seti@home is running.

Ok, thanks.

If this is true to form, the next message will be from someone who
indicates that the snapshot either shows no change or makes things
worse.

cgf
--
Please use the resources at cygwin.com rather than sending personal email.
Special for spam email harvesters: send email to [EMAIL PROTECTED]
and be permanently blocked from mailing lists at sources.redhat.com

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: please try the latest snapshot

[Eugene Rosenzweig]

It does fix the slow pipes on my machine when seti@home is running.

- Original Message -
From: "Christopher Faylor" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, January 17, 2003 4:52 PM
Subject: please try the latest snapshot


> The latest snapshot should fix some /etc handling problems (thanks to
> ideas and code from Pierre Humblet), like the dreaded BSOD.  It may also
> solve the "pipes are slow" problem.  There are also all of the fixes
> accumulated since 1.3.18, of course.
>
> If I don't hear too many whines about this snapshot, it may become
> 1.3.19.
>
> cgf
> --
> Please use the resources at cygwin.com rather than sending personal email.
> Special for spam email harvesters: send email to
[EMAIL PROTECTED]
> and be permanently blocked from mailing lists at sources.redhat.com
>
> --
> Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
> Bug reporting: http://cygwin.com/bugs.html
> Documentation: http://cygwin.com/docs.html
> FAQ:   http://cygwin.com/faq/
>


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

please try the latest snapshot

[Christopher Faylor]

The latest snapshot should fix some /etc handling problems (thanks to
ideas and code from Pierre Humblet), like the dreaded BSOD.  It may also
solve the "pipes are slow" problem.  There are also all of the fixes
accumulated since 1.3.18, of course.

If I don't hear too many whines about this snapshot, it may become
1.3.19.

cgf
--
Please use the resources at cygwin.com rather than sending personal email.
Special for spam email harvesters: send email to [EMAIL PROTECTED]
and be permanently blocked from mailing lists at sources.redhat.com

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/