Re: [BUG] running mc "over" running one

[Pavel Roskin <proski gnu org>]

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