From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29107 invoked by alias); 3 Jun 2002 15:20:00 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 29100 invoked from network); 3 Jun 2002 15:19:58 -0000 Received: from unknown (HELO cpimssmtpu09.email.msn.com) (207.46.181.84) by sources.redhat.com with SMTP; 3 Jun 2002 15:19:58 -0000 Received: from neeeeeee ([67.41.26.180]) by cpimssmtpu09.email.msn.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 3 Jun 2002 08:18:24 -0700 Message-ID: <02fd01c20b12$49edbff0$0201a8c0@neeeeeee> From: "Ben Wing" To: Subject: numerous bugs i've found in Cygwin while developing XEmacs Date: Mon, 03 Jun 2002 08:20:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 03 Jun 2002 15:18:24.0707 (UTC) FILETIME=[E78F4130:01C20B11] X-SW-Source: 2002-06/txt/msg00075.txt.bz2 it would be nice if there were a "known bug" list posted somewhere so I had a sense if I'm just duplicating stuff already known about. it's true, the mailing list archives are there, but it's often hard to figure out if the bug has been reported or whether it ought to be fixed already but isn't, etc: I am using: ~/school/post-college/art256/final/shrunk 2032$ uname -a CYGWIN_NT-5.0 NEEEEEEE 1.3.10(0.51/3/2) 2002-02-25 11:14 i686 unknown [1] mmap[] and fork[]. The "pdump" [portable dumper] method of implementing undumping for XEmacs writes out all the data into a large file during building, and then reads it in when the program starts. the file looks like this: -rw-r--r-- 1 Ben Wing None 3280684 Jun 2 02:58 xemacs.dmp if mmap support exists, it's loaded using mmap[]. This fails miserably when a fork[] happens, as the child evidently doesn't get the mmap[]ed data visible in it and thus seg faults occur. [2] race conditions with pty's. XEmacs implements "process" objects, which allow I/O to/from a subprocess. This can be implemented either with pty's or pipes. I recently rewrote the synchronous "call-process" command (which runs a command and waits to completion) using the asynchronous process objects. first, note that the process's stdin descriptor has been set to non-blocking. now, when the process has input, we go into a tight loop sending as much data as we can, until it blocks. at that point, we "accept process output" by waiting up to 1 second, using select() to check for output from the process and grab it -- this may allow the process to start reading more input. the tight loop exits as soon as the system has accepted all data. next thing, we send an "EOF" to the process -- for pipes, this means to close the descriptors, but for pty's this means to send the ^D character. at that point, we go into a loop, doing "accept process output" until we get a SIGCHLD signal indicating the process has terminated. now, if i create a simple program that echoes its input to output, and run the above code using a few lines as input [usually, in fact, this: ;; This buffer is for notes you don't want to save, and for Lisp evaluation. ;; If you want to create a file, first visit that file with C-x C-f, ;; then enter the text in that file's own buffer. (C-x is the standard ;; XEmacs abbreviation for `Control+x', i.e. hold down the Control key ;; while hitting the x key.) ;; ;; For Lisp evaluation, type an expression, move to the end and hit C-j. ], then if i've chosen to use pipes, all is well. however, with pty's, things get messed up. first of all, the output from the process consists not only of the process's actual output, but, before its output is most of the first line of input [60 chars or so, it varies]. secondly, the process never terminates. it appears that the ^D is not getting sent synchronously to the PTY, but is sent more like a signal, leapfrogging over any pending input -- thus, it must be that when we sent the ^D, about 60 chars have made it to the PTY and the rest are being buffered. the PTY then reechoes the first line [like it should], and of course never closes the input. evidently you need to make ^D synchronous. [3] problems with the debugger. [a] The "STOP" button never ever works for me. It does not stop XEmacs from running, and after 2 seconds asks if you want to unattach from the process. if you do, things get majorly wedged -- gdb hangs, and if you try to kill it from the Task Manager, that hangs, too. Rebooting your system in an orderly way doesn't work because there's simply no way to kill gdb. You have to hit the front-panel reset button. BTW XEmacs is a window process, not a console process; i dunno if this matters. [b] can't attach to a running process. [c] can't ^C a running process from the console [related to [a], certainly]. [d] periodic crashes and hangs, can't duplicate; in general, it seems buggy and not very reliable. [4] interference between Cygwin and MS DevStudio If I'm running a Cygwin compile [i.e. using make/gcc/etc] in the background, MS DevStudio is *waaaaaaaaaaaaaaaaaaaaay* slow when loading. In particular, when it gets to the "loading workspace" phase, which normally takes a few seconds, it may take 2 minutes or more. It seems like Cygwin is locking some resources in an anti-social fashion. I've seen other similar problems, e.g. I'm sure that running two compiles in the background at once is far slower than running them in series, but I can't be so specific. [5] Cygwin's non-standard way of allocating processes causes problems >From bash, if you execute five subshells one right after the other, and do echo $$ in each one, you get a weird sequence like this: 1036 1492 2036 1412 1560 this is clearly echoing the Win32 process numbers, which are perhaps assigned at random so as to increase security (remember the C.1 Windows NT compliance?). However, this can screw up Unix programs, which expect the numbers to be assigned sequentially. Particularly, if I'm running two cvs updates at once, chances are that one of them will abort at a random point saying "cannot create temporary file" or something of that sort. It appears that cvs update runs at least one subprocess per file, and that subprocess creates a temporary file based on the process number. it seems that what's happening is that, with process numbers being assigned at random, it's inevitable that eventually two subprocesses running one right after the other, one called by the each update process, will get the same process number, and they will interfere. obvious solution is to not directly use the Win32 process, but to create special Cygwin process numbers that increment by 1 in an orderly fashion. [6] Slowness -- An opendir() loop with a stat() to get directory status, etc. is somewhere around 10-50x as slow as without the stat(). This probably accounts for much of the slowness in ls, find, cp, etc. Given that most or all of the information needed for the stat() is available as part of the underlying FindNextFile call, and in the case of a symlink, it's easy to use that same info to determine whether the expensive symlink check needs to be done [system file or ends with .lnk], some simple caching could cause quite dramatic speed improvements. -- XEmacs `configure', which for the most part runs gcc repeatedly to check for the presence and absence of various features, is *DOG* slow. It takes upwards of 10 minutes on my Pentium III 700Mhz -- compared to maybe 3 minutes on my old Pentium 90Mhz running Linux from 8 years ago! Compilation in general is way slow, too. The obvious culprit is process spawning. gcc spawns a number of sub-processes -- has it been rewritten to use spawn() instead of fork()? This should happen to all basic cygwin tools, if possible. (If gcc has already been rewritten this way, I have no idea what's going on. But the apparent antisocial behavior mentioned above w.r.t. DevStudio could well be the tricky locking and such that goes on in order to implement fork().) [7] "mv does a copy when you didn't ask it to" This is a personal pet peeve of mine. Evidently this is by design, but the fact that if you accidentally have a shell cd'd to a directory in the middle of a tree you'd like to move, then mv tries to do the move by copying the *WHOLE DAMN THING*, is just very wrong and certainly counter to the "don't do weird and potentially dangerous magic unless the user said so" principle. mv should just report an `Access Denied' error in this case; if you want the copy-then-erase behavior, use `mv -r' [granted, it doesn't currently exist, but a flag exactly like this did and maybe does exist in BSD]. [8] Cygwin bash doesn't let you exit the console automatically when you shut down This can be controlled using SetConsoleCtrlHandler and SetProcessShutdownParameters. Particularly if bash is just sitting there idle, it should allow itself to be shut down automatically and do the equivalent of calling `exit'. [9] Cygwin setup program does not register itself in the control panel list of apps or provide an uninstall routine. [We at XEmacs have a personal interest in this one since we use the Cygwin setup program to construct our own setup program.] ben -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/