[BUG] running mc "over" running one
Pavel Roskin
proski at gnu.org
Mon Nov 4 05:47:57 UTC 2002
Hello, Jose!
Sorry that I didn't not reply earlier.
> It is indeed a subshell problem, see ahead.
Good to know.
> > > 13963 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0 13963
> > > rt_sigsuspend([]
> >
> > There have been significant changes near this point in subshell.c
>
> You mean at synchronize?
Yes, but it was a wild guess. Now we have more data.
> Exactly. I've done some further debugging and find it to stop after
> failing at FD_ISSET's in feed_subshell at subshell.c (967 and
> following -- only the first call to feed_subshell get FD_ISSET ok).
Sorry, references to line numbers are useless without version number.
There is no FD_ISSET in line 967 in the CVS version of subshell.c.
Besides, I don't understand "failing at FD_ISSET" - FD_ISSET returns a
non-zero value if there was an event on the file descriptor in question.
No event is not a failure.
> It then just returns to init_subshell and gets stuck there.
That's serious. I have always suspected that the code for restarting the
subshell is broken. I don't know how you get there, but at least it's
something that can be reproduced and fixed if needed.
Please comment out this code and try again:
/* Restart the subshell if it has died by SIGHUP, SIGQUIT, etc. */
while (!subshell_alive && !quit && use_subshell)
init_subshell ();
I understand that's what you mean under "It then just returns to
init_subshell".
> [japc at morgoth:/tmp/mc-2002-10-25-22.ALTERED/src]$ ps auxw | grep 'bash -rcfile'
> japc 7796 0.0 1.1 4632 1416 pts/5 S 03:11 0:00 bash -rcfile .bashrc
> japc 7802 0.0 0.9 4524 1208 pts/6 T 03:11 0:00 bash -rcfile .bashrc
>
> As you can see the second one stays stopped. That is most certainly
> related with the
>
> g_snprintf (precmd, sizeof (precmd), "precmd() {pwd>&%d;kill -STOP $$ }\n",
>
> at subshell.c
Yes, it's supposed to deliver SIGCHLD to the parent. synchronize() waits
for SIGCHLD and restarts the subshell. That's done so that the subshell
can signal that it has completed the command.
> Of course that if I do a #undefine HAVE_SUBSHELL_SUPPORT the problems go
> away.
I think that "mc -u" should have the same effect.
> Hope this helps.
I know that when we had similar problems in Cygwin, there were many talks
and no results until I installed Cygwin and reproduced the problem. I
don't expect this problem to be fixed unless you give more details about
where exactly the second mc stops.
If you have a problem with restarting the subshell, it can probably be
fixed, but the question would remain why it happens for you.
Hint - to debug such problems, you need a trap for the second mc -
something like this in the beginning (e.g in main()):
int gdb_hold = 1;
while (gdb_hold)
sleep (1);
Then you run gdb is a separate terminal, load the second mc and attach gdb
to the mc process using the "attach" command. Now you can use
set var gdb_hold=0
to make the process continue. Hope this helps :-)
--
Regards,
Pavel Roskin
More information about the mc-devel
mailing list