Re: numerous bugs i've found in cygwin while developing XEmacs

[Christopher Faylor <cgf-cygwin at cygwin dot com>]

On Mon, Jun 03, 2002 at 08:21:08AM -0700, Ben Wing wrote:
>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.

Would you like to maintain a "known bug" list?  I'll set you up with cvs web
page access, if so.

>[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.

This is obviously not supposed to be the way things work.  It can't be as
simple as "mmap doesn't work across forks".

>[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.

^D is no sent asynchronously, AFAIK.  Since ptys are working relatively well
with things like ssh and rxvt, I don't think they can be quite that broken.
You never know, of course.

>[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.

Yep.  gdb has problems.  Attaching to a running process isn't one of them, though.
The other ones are annoying but they are known.

>[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.

Cygwin doesn't lock any resource that I'm aware of.

>[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.

Cygwin uses windows pids.  Any UNIX program which expects pids to be sequential
is completely, totally, irretrievably broken.

>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.

It may seem obvious but cygwin does go out its way to ensure that the
same pid is not used twice in succession.

>[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.

There is nothing simple about caching filesystem information.  We have
been trying to speed up stat operations, however.  See the recent
discussions in this and the cygwin-developers mailing list.

>[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].

'mv' comes from 'fileutils'.  It is apparently working as designed.

>[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.]

If you have a personal interest in it, why doesn't someone submit a patch?
Why are you relying on us to drive setup.exe development if it is so crucial
to your plans?

Hmm.  Now that I think of it, I don't recall ever seeing any setup patches
from Xemacs.

Anyway, thanks for your report.  I'll try to keep this in mind if I happen
to be working on the sections of code that you mention.

cgf

--
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/