This is the mail archive of the
mailing list for the Cygwin project.
Re: new snapshot with some tty/WinMe fixes
- From: "Pierre A. Humblet" <Pierre dot Humblet at ieee dot org>
- To: cygwin at cygwin dot com
- Date: Sat, 03 Jan 2004 18:16:28 -0500
- Subject: Re: new snapshot with some tty/WinMe fixes
At 01:19 PM 1/3/2004 -0500, Christopher Faylor wrote:
>I managed to get a WinMe installation up and running here so I can now
>debug some of the problems that show up there. And, they were
>interesting problems indeed. It seems like something sometimes starts
>up a stray thread on WinMe and that thread does not register itself with
>the new signal handler. It somehow doesn't even go through the DLL
>thread initialization code. So, all of my new code which allows signals
>to threads got confused by this.
>I've worked around this in an ugly way but at least I am not seeing
>the random failures that I was consistently getting. I will run
>the testsuite on this soon to see if it there are any more gotchas
>but I thought I'd get a new version uploaded.
>I also noticed YA handle leak in the new tty inheritance code with
>my old friend vfork, so I have hopefully fixed that. I tried all
>of the test cases that Pierre previously reported but I'm sure I
>missed one. I didn't change any of the fork handling, AFAIK, just
>vfork. That means that /bin/sh and make are potentially affected.
CYGWIN_ME-4.90 hpn5170x 1.5.6s(0.108/3/2) 20040103 13:16:07 i686 unknown unknown Cygwin
1) With the snapshot I can start cygwin programs fine and I have not observed
2) The regression repeated before (see original mail for more details) is still there:
"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)."
3) There is another regression that I had also observed with the previous snapshot,
but after sending my previous message: the Console is not properly freed after
setsid when CYGWIN=notty. Programs such as inetd do not go in the background when
starting from a command.com window or from the Windows "run" menu.
Things are fine with CYGWIN=tty
By the way, I don't understand why open_fhs is modified in the slave tty and ctty
code. The only purpose I see in open_fhs is to free the console at the right time.
Why should the presence of a slave tty, possibly connected to an entirely different
console window, impact on the local console? (this is not a new issue).
However things are not fine when building from CVS, even after cleaning the
Cygwin object directory and running configure. Programs die on startup as shown
below. It's related to the threadinfo stuff.
Starting program: /usr/bin/ls.exe
Program received signal SIGSEGV, Segmentation fault.
[Switching to thread -189799.0xfdba3341]
0x00c9e65a in ?? ()
(gdb) info threads
* 3 thread -189799.0xfdba3341 0x00c9e65a in ?? ()
2 thread -189799.0xfd8a60f5 0xbff8a127 in KERNEL32!ExpandEnvironmentStringsW
() from /c/WINDOWS/SYSTEM/KERNEL32.DLL
1 thread -189799.0xfdbcf3fd _vfprintf_r (data=0x84e650, fp=0x84e040,
fmt0=0x6101df61 "cYgstd %x %x %x", ap=0x84e0c8 "\020á\204")
#0 0x00c9e65a in ?? ()
#1 0x610041f0 in _threadinfo::call2(unsigned long (*)(void*, void*), void*, vo
d*) (func=0xc9e650, arg=0xc9e414, buf=0xc9c790)
#2 0x610041b8 in _threadinfo::call(unsigned long (*)(void*, void*), void*) (
func=0xc9e650, arg=0xc9e414) at ../../../../src/winsup/cygwin/cygtls.cc:44
#3 0x610f5780 in ZZ12cygheap_initE23cygheap_protect_storage ()
#4 0x00c9e390 in ?? ()
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html