Re: startx hanging - startup problem located
On 4/30/05, Alexander Gottwald <[EMAIL PROTECTED]> wrote: > > Just as expected. The forked xkbcomp does still hang forever. > > > // any chance at all what I'm seeing has something to do with the > > EINTR || ECHILD possibility above? > > Even then the xserver should continue. But it appears to be waiting for > the child which never exits properly. ok then, any chance the pipe(), fork() and _exit() semantics are involved? I wrote a small test program along the lines of what Popen() is doing, and on SunOS 5.8 the output is:: child :: myPID = 2998 :: 1 parent :: chPID = 2998 parent :: pd[0] = 3pd[1] = 4 2 3 4 5 6 7 8 9 10 Done.. child put 1442 bytes in fd 3 All done.. while on Linux 2.6.4-52-default and CYGWIN_NT-5.1 1.5.13(0.122/4/2) the output is: child :: myPID = 6295 :: 1 parent :: chPID = 6295 parent :: pd[0] = 3pd[1] = 4 2 3 4 5 6 7 8 9 10 Done.. child put 0 bytes in fd 3 All done.. a description of the test program: 1. the parent makes a pipe() and fork()s. the child slowly counts to 10 and then uses dup2() to make the 'w'||pd[1] end of the pipe into stdout and close()s the 'r'||pd[0] end of the pipe. (SunOS 5.8 creates a bidirectional pipe, while the Linux doc indicates it creates a unidirectional pipe with pd[0] ready to be read and pd[1] ready to be written) 2. the child then execl()s a shell which makes more output and _exit()s if the execl() is unsuccessful. 3. the parent sets SIGCHLD to SIG_IGN and close()s the 'w'||pd[1] end of the pipe. 4. the parent blocks in waitpid() until the child completes, then fstat()s the 'r'||pd[0] end of the pipe and reports the number of bytes written into it.
Re: startx hanging - startup problem located
On Fri, 29 Apr 2005, martouf . wrote: > thanks! I did try, and it behaved like this: > > 1. with "-kb" (kb ext disabled) it starts up just fine. > > 2. without "-kb" it 'hangs' with sh consuming >90% CPU right after the > 'Rules' line. Ending the sh process causes XWin to wake back up and > finish starting up then runs just fine. Just as expected. The forked xkbcomp does still hang forever. > // any chance at all what I'm seeing has something to do with the > EINTR || ECHILD possibility above? Even then the xserver should continue. But it appears to be waiting for the child which never exits properly. bye ago -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
Re: startx hanging - startup problem located
On Fri, 29 Apr 2005, Alexander Gottwald wrote:
>> uhh, don't you mean System(), Popen() and Pclose() ?
>
> No. I mean Fopen. This is the only place where /bin/cat is mentioned.
oh yes, ok, I see now. thanks.
>> They're contained within an entire "#if !defined(WIN32)" stanza and I'm not
>> sure what that means with respect to Cygwin.
>
> WIN32 is only for mingw and native compiler like msvc.
ok. first time looking through XWin source, so I am completely
unfamiliar with its cpp vars.
> I've compiled XWin with HAS_SAVED_IDS_AND_SETEUID in os/utils.c
> http://www.freedesktop.org/~ago/XWin.exe.bz2
>
> Feel free to try.
thanks! I did try, and it behaved like this:
1. with "-kb" (kb ext disabled) it starts up just fine.
2. without "-kb" it 'hangs' with sh consuming >90% CPU right after the
'Rules' line. Ending the sh process causes XWin to wake back up and
finish starting up then runs just fine.
An interesting code pattern I see (and am not sure if it's
significant) in os/utils.c:
[paraphrasing]
Popen() {
.
.
switch (pid = fork()) {
.
. execl("/bin/sh", "sh", "-c", command, (char *)NULL);
_exit(127);
}
/* Avoid EINTR during stdio calls */
OsBlockSignals ();
.
.
}
Pclose(){
.
.
do {
pid = waitpid(cur->pid, &pstat, 0);
} while (pid == -1 && errno == EINTR);
.
.
/* allow EINTR again */
OsReleaseSignals ();
.
.
}
// with SIGCHLD set to SIG_IGN/SIG_BLOCK, then waitpid() should never
be interrupted
// by a signal and will never exit with EINTR. It may exit with ECHILD, though.
// Does Cygwin behave the same way?
[more paraphrasing -- this next bit is more interesting to me]
Fopen(){
.
.
#ifndef HAS_SAVED_IDS_AND_SETEUID
switch (pid = fork()) {
.
.
execl("/bin/cat", "cat", file, (char *)NULL);
_exit(127);
}
/* Avoid EINTR during stdio calls */
OsBlockSignals ();
.
.
#else
.
.
}
Fclose(){
#ifdef HAS_SAVED_IDS_AND_SETEUID
return fclose(iop);
#else
return Pclose(iop);
#endif
}
// any chance at all what I'm seeing has something to do with the
EINTR || ECHILD possibility above?
Re: startx hanging - startup problem located
On Fri, 29 Apr 2005, martouf . wrote: > uhh, don't you mean System(), Popen() and Pclose() ? No. I mean Fopen. This is the only place where /bin/cat is mentioned. > They're > contained within and entire "#if !defined(WIN32)" stanza and I'm not > sure what that means with respect to Cygwin. WIN32 is only for mingw and native compiler like msvc. I've compiled XWin with HAS_SAVED_IDS_AND_SETEUID in os/utils.c http://www.freedesktop.org/~ago/XWin.exe.bz2 Feel free to try. bye ago -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
Re: startx hanging - startup problem located
I don't have /tmp mounted as anything. / is mounted in binmode. $ mount C:\cygwin\bin on /usr/bin type system (binmode) C:\cygwin\lib on /usr/lib type system (binmode) C:\cygwin on / type system (binmode) c: on /cygdrive/c type system (binmode,noumount) On 4/29/05, Alexander Gottwald <[EMAIL PROTECTED]> wrote: > > maybe /tmp mounted in textmode? > > strace will show unlimited cycles of textmode/binmode tests then. >
Re: startx hanging - startup problem located
uhh, don't you mean System(), Popen() and Pclose() ? They're contained within and entire "#if !defined(WIN32)" stanza and I'm not sure what that means with respect to Cygwin. Did something change in fork(), exec() or exit() between 1.5.12 and 1.5.13 ? On 4/29/05, Alexander Gottwald <[EMAIL PROTECTED]> wrote: > No. It does. > > Check > http://cvs.freedesktop.org/xorg/xc/programs/Xserver/os/utils.c?rev=1.15&view=auto > for the actual code (check Fopen and Fclose) >
Re: startx hanging - startup problem located
On Fri, 29 Apr 2005, martouf . wrote: > I don't have ZoneAlarm. > > I get past the xkbcomp problem by disabling keyboard extensions, at > which point 'cat' spins at >90% CPU on .Xauthority instead of 'sh' > spinning on xkbcomp. maybe /tmp mounted in textmode? strace will show unlimited cycles of textmode/binmode tests then. > I did not have this problem with an older cygwin.dll (see my earlier message). > http://cygwin.com/ml/cygwin-xfree/2005-03/msg00048.html > > Is the fork emulation not wait()ing properly? 'cat' seems to be > defunct at the time it is spinning, and yet it consumes CPU. trying > to deliver SIGCHLD? return value from exit()? No. It does. Check http://cvs.freedesktop.org/xorg/xc/programs/Xserver/os/utils.c?rev=1.15&view=auto for the actual code (check Fopen and Fclose) bye ago -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
Re: startx hanging - startup problem located
I don't have ZoneAlarm. I get past the xkbcomp problem by disabling keyboard extensions, at which point 'cat' spins at >90% CPU on .Xauthority instead of 'sh' spinning on xkbcomp. I did not have this problem with an older cygwin.dll (see my earlier message). http://cygwin.com/ml/cygwin-xfree/2005-03/msg00048.html Is the fork emulation not wait()ing properly? 'cat' seems to be defunct at the time it is spinning, and yet it consumes CPU. trying to deliver SIGCHLD? return value from exit()? On 4/29/05, Alexander Gottwald <[EMAIL PROTECTED]> wrote: > XWin tries to start xkbcomp. This process start fails because ZoneAlarm > has broken the network stack and the cygwin fork emulation does not work > properly. Disabling XKB is a workaround but not the solution. Every user > which had this problem could confirm that uninstalling ZoneAlarm 5 (just > disabling does not help) did solve the problem. So this is obviously a > firewall problem. >
Re: startx hanging - startup problem located
On Thu, 28 Apr 2005, martouf . wrote: > in reference to my earlier message > http://cygwin.com/ml/cygwin-xfree/2005-03/msg00048.html > and the following message > http://cygwin.com/ml/cygwin-xfree/2005-04/msg00152.html > > I can state I am -not- having a "personal firewall problem". With the > help of 'Process Explorer' from sysinternals.com, I have been able to > determine it is caused by 'cat.exe' using >90% CPU. XWin tries to start xkbcomp. This process start fails because ZoneAlarm has broken the network stack and the cygwin fork emulation does not work properly. Disabling XKB is a workaround but not the solution. Every user which had this problem could confirm that uninstalling ZoneAlarm 5 (just disabling does not help) did solve the problem. So this is obviously a firewall problem. bye ago -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
Re: Process Explorer (was: startx hanging - startup problem located)
"martouf ." wrote: > yes, bringing up the Threads tab on processes like 'xterm' and 'sh' > causes a new thread "ntdll.dll!RtlConvertUiListToApiList+0xNNN" to be > created. It is simple to remedy this by killing the thread. Having > done so, CPU usage returns to normal and the Cygwin process becomes > responsive again. Right. That's what I do as well when it happens. I just wanted to make sure that what you are seeing is not due to process explorer. 'cat' is such a simple program that I'd be surprised if it is directly related to the problem at hand. It may be the symptom, but I'd be very surprised if 'cat' itself was the problem. The stack trace that process explorer gives you is a bunch of Native APIs in NTDLL (most of which undocumented) and as such is more or less useless. If you build cat with debugging symbols and attach to the hung process with gdb it would give a much better idea. Or try commenting out things in startx until you can pin down the behavior that causes it. Or run strace and see what calls lead up to the hang. But I've got to say, even though you seem to have ruled out "firewall" issues, these sorts of hangs when starting XWin are almost always due to some kind of third party software the inserts itself into the winsock network stack in some fashion. Brian
Re: Process Explorer (was: startx hanging - startup problem located)
"Brian Dessent" wrote: > Specifically, if you click on the Threads tab of the Properties page of a > process, > ProcExp attaches its own thread to the process and this causes the Cygwin > process to consume 100% cpu. yes, bringing up the Threads tab on processes like 'xterm' and 'sh' causes a new thread "ntdll.dll!RtlConvertUiListToApiList+0xNNN" to be created. It is simple to remedy this by killing the thread. Having done so, CPU usage returns to normal and the Cygwin process becomes responsive again.
Re: startx hanging - startup problem located
I started by using Windows Task Manager to try to find the 'hanging' problem, and after sorting the process list by CPU usage - there was 'cat' spinning away. Process Explorer v9.02 provided the same data. Trying to 'cat /proc/PIDNO/cmdline' would only provide "". It does not matter if I use 'rootless' or 'multiwindow' - X stops at the "Rules" line (although I often see a clipboard connection message).
Re: startx hanging - startup problem located
"martouf ." wrote: > I can state I am -not- having a "personal firewall problem". With the > help of 'Process Explorer' from sysinternals.com, I have been able to > determine it is caused by 'cat.exe' using >90% CPU. I wouldn't be so sure. Process Explorer is a nice tool but it doesn't always play nice with Cygwin. Specifically, if you click on the Threads tab of the Properties page of a process, ProcExp attaches its own thread to the process and this causes the Cygwin process to consume 100% cpu. You can trivially demonstrate this by clicking on any normal Cygwin process in ProcExp and then going to the Threads tab in properties. The cpu usage will shoot to 100%, sometimes shared between the process being examined and csrss.exe. This does not mean there's anything wrong with the process, it means that whatever ProcExp is doing is too invasive. Brian
startx hanging - startup problem located
in reference to my earlier message http://cygwin.com/ml/cygwin-xfree/2005-03/msg00048.html and the following message http://cygwin.com/ml/cygwin-xfree/2005-04/msg00152.html I can state I am -not- having a "personal firewall problem". With the help of 'Process Explorer' from sysinternals.com, I have been able to determine it is caused by 'cat.exe' using >90% CPU. I am disabling the keyboard extensions (see my earlier message). The 'cat' command line is: C:\cygwin\bin\cat.exe /home/martouf/.Xauthority The hanging thread stack is: ntdll.dll!KiFastSystemCallRet ntdll.dll!LdrInitializeThunk+0x29 ntdll.dll!LdrFindResourceDirectory_U+0x276 ntdll.dll!RtlLookupElementGenericTable+0x185 ntdll.dll!RtlLookupElementGenericTable+0x80 ntdll.dll!KiUserApcDispatcher+0x7 If I just kill the 'cat' process, then X starts up and functions. 'cat' will spin away indefinitely. hope this helps...
