numerous bugs i've found in Cygwin while developing XEmacs

["Ben Wing" <ben at 666 dot com>]

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/