This is the mail archive of the cygwin@cygwin.com 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


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/


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