I have discovered where the problem is occuring.
Function msh_main calls one_command. It calls setjmp:
if (setjmp(failpt) || yyparse() || intr) {
DBGPRINTF(("ONECOMMAND: this is not good.\n"));
Next execute is called. Execution reaches the 'broken:' section. In the
case of a ctrl c, intr and interactive are set, and fail is eventually
run.
Inside of fail(), longjmp returns to the setjmp that was set inside of
one_command.
POSIX states that it is undefined whether setjmp saves the signal mask.
It also says that it is undefined whether longjmp restores the signal
mask. For me, the second ctrl-c results in all signals being blocked for
msh.
I believe that the solution is the following: (my local cvs 1.2 is
version busybox-1.7.2)
Index: uClinux-dist/user/busybox/shell/msh.c
===================================================================
RCS file: /var/cvs/firmware/uClinux-dist/user/busybox/shell/msh.c,v
retrieving revision 1.2
diff -u -r1.2 msh.c
--- uClinux-dist/user/busybox/shell/msh.c 5 Nov 2007 20:43:35
-0000 1.2
+++ uClinux-dist/user/busybox/shell/msh.c 19 Feb 2008 22:00:31
-0000
@@ -824,7 +824,7 @@
static void fail(void) ATTRIBUTE_NORETURN;
static void fail(void)
{
- longjmp(failpt, 1);
+ siglongjmp(failpt, 1);
/* NOTREACHED */
}
@@ -1376,9 +1376,9 @@
execflg = 0;
failpt = m1;
- setjmp(failpt); /* Bruce Evans' fix */
+ sigsetjmp(failpt, 0); /* Bruce Evans' fix */
failpt = m1;
- if (setjmp(failpt) || yyparse() || intr) {
+ if (sigsetjmp(failpt, 0) || yyparse() || intr) {
DBGPRINTF(("ONECOMMAND: this is not good.\n"));
while (e.oenv)
I'm not sure if my uClibc is incorrect, or if it should be compiled for
BSD/SysV style jmp calls, or what. Let me know what you think.
- Jate S.
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Jate Sujjavanich
Sent: Monday, February 18, 2008 1:02 PM
To: Denys Vlasenko
Cc: [email protected]
Subject: RE: msh and signals lost due to blocking
Denys,
I had to import a patch from busybox cvs to get mount working. That
explains why I can compile. I tried your suggestion, but everything
works fine on x86.
I just got strace working on my Coldfire platform and had some
interesting results. See the attached file.
# strace -tt -F -o /var/msh.log /bin/busybox msh # sleep 5 [CTRL-C
interrupts sleep] # sleep 5 [CTRL-C interrupts sleep] # sleep 5 [CTRL-C
does nothing!] # exit #
On the second command executed, there is the explicit system call
blocking signals. I have not yet been able to figure out where this
happens in the msh code. Unfortunately, gdb is intercepting all the
SIGINT's and is preventing the bug from occuring.
Hopefully, you or someone with a greater understanding of the code knows
where this is occuring. In the meantime, I'll try to isolate the bug as
well.
- Jate S.
-----Original Message-----
From: Denys Vlasenko [mailto:[EMAIL PROTECTED]
Sent: Monday, February 11, 2008 10:43 AM
To: Jate Sujjavanich
Cc: [email protected]
Subject: Re: msh and signals lost due to blocking
On Tuesday 29 January 2008 22:51, Jate Sujjavanich wrote:
> I compiled busybox for x86, and the bug does not appear to manifest
> itself. I've been reproducing it by running a ping and hitting ctrl-C
> from the shell prompt. After about four successes, the signal block
> occurs. With version 1.7.2 on x86, I can do this at will.
Strange, with your .config I caanot duplicate it.
BTW, your .config does not even buld on NOMMU, I had to disable
CONFIG_MOUNT, otherwise I was getting
mount.c:(.text.daemonize+0x3): undefined reference to
`BUG_fork_is_unavailable_on_nommu'
Did you make any modifications to the source?
So, with attached .config, and with busybox 1.7.2 built statically
against uclibc, with this change in platform.h for forcing NOMMU:
...
#if 1
//defined __UCLIBC__ && __UCLIBC_MAJOR__ >= 0 && __UCLIBC_MINOR__ >= 9
&&
// __UCLIBC_SUBLEVEL__ > 28 && !defined __ARCH_USE_MMU__
#define BB_MMU 0
#define BB_NOMMU 1
...
I can run msh and can run "ping 127.0.0.1" from it, and it is
interruptible by Ctrl-C every time. Same with "sleep 10".
Can you build busybox with the attached .config and above platform.h
change on x86 and try it?
If Ctrl-C indeed stops working for you, run
strace -f -tt -o msh.log ./busybox msh
reproduce the bug ad send msh.log to the list.
--
vda
************************************************************************
************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals &
computer viruses.
************************************************************************
************
************************************************************************
************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals &
computer viruses.
************************************************************************
************
_______________________________________________
busybox mailing list
[email protected]
http://busybox.net/cgi-bin/mailman/listinfo/busybox
