Re[2]: Status of MC

[Pavel Roskin <proski gnu org>]

Hello!

> PR> It depends on how intrusive it is.  I would prefer to check for bugs, not 
> PR> for versions.  I know, it can be hard to check how signals from the child 
> PR> are processed.  You can always keep that patch in the Cygwin port tree, or 
> PR> whatever it's called.  MC should not become a library of workarounds.
> 
> Ok...  I'm just sending it and you decide :) And you're right - I can apply it
> myself when releasing the Cygwin package.

I like your programming style, but your patch is a bit too heavy for mc.

Actually, I applied a patch today that resembles my original patch, but it
may be more reliable.

=====================
diff -u -r1.48 -r1.49
--- subshell.c	19 Aug 2002 02:06:01 -0000	1.48
+++ subshell.c	19 Aug 2002 22:28:02 -0000	1.49
@@ -1039,6 +1039,12 @@
     sigaddset (&sigchld_mask, SIGCHLD);
     sigprocmask (SIG_BLOCK, &sigchld_mask, &old_mask);
 
+    /*
+     * SIGCHLD should not be blocked, but we unblock it just in case.
+     * This is known to be useful for cygwin 1.3.12 and older.
+     */
+    sigdelset (&old_mask, SIGCHLD);
+
     /* Wait until the subshell has stopped */
     while (subshell_alive && !subshell_stopped)
 	sigsuspend (&old_mask);
=====================

The difference is that old_mask is "repared" after sigprocmask(), not
before, so if the "glitch" happens in _that_ sigprocmask(), we still can
compensate for it.

I tried really hard and could not make mc hang with the subshell when
using the new patch.  I'm using the current binary version Cygwin that I
update every day by setup.exe.

I think this patch should be sufficient, and there is no need to disable
the subshell for older Cygwin versions, unless you can make mc hang even
with this patch, which is now on CVS.

And by the way, I fixed a coredump under Cygwin in fish if ssh is missing.  
It's perhaps one of the most amazing bugs I've ever seen!

To run ssh, mc forks.  The child connects its output to a pipe.  The
parent printes all that output on the screen, so that possible warnings
and password prompts from ssh are visible (they mess the screen, but it's
another matter).  The child tries to run ssh, and if it fails, it calls a
function vfs_die(), which displays a message box.  Yeah right, it was
feeding the escape sequences to draw the box to the parent process, so
that would display the error message!

It didn't work on Linux and caused a crash on Cygwin.  I didn't try to
investigate the reasons for the crash, I simply replaced vfs_die() with
_exit(), which was sufficient.

While fixing this, I also fixed another remote buffer overflow in fish,
hopefully not exloitable (because it can overwrite only one byte after the
buffer), but nasty nevertheless.

Now I'm concerned that the guy who wrote that "message from hell" code is
now an active Linux kernel developer.  Perhaps I should backup more often
:-)

-- 
Regards,
Pavel Roskin