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