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

Nicholas Wourms nwourms@netscape.net
Sun Dec 28 23:19:00 GMT 2003


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



More information about the Cygwin mailing list