This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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.
>>>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 
>>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 
>><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.
>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, 
>>"_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.


Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]