BusyBox Bug and Patch Tracking
BusyBox
  

Viewing Issue Simple Details Jump to Notes ] View Advanced ] Issue History ] Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0005004 [BusyBox] Other minor always 09-15-08 22:08 10-27-08 05:38
Reporter xmuchgw View Status public  
Assigned To BusyBox
Priority normal Resolution unable to reproduce  
Status closed   Product Version 1.10.x
Summary 0005004: Shell command will hang minicom. When minicom is hanging, reboot/poweroff commands are useless
Description package:busybox
version:1.10.2

When I execute following shell script on my development board in HyperTerminal,
about 5~30 minuters later, the HyperTerminal hangs until press any key from keyboard.

   while true
   do
        ls -l
   done

When my HyperTerminal is hanging, I login my development board by telnet.
And found that, reboot and power commands are NOT workable.
But others shell commands, such as cd/ls/ps are workable.
Additional Information The same result if use minicom to instead of HyperTerminal.
My shell is ash.
Attached Files  2008-09-16.txt [^] (13,055 bytes) 09-16-08 01:42
 telnetd.log [^] (6,057 bytes) 09-16-08 19:19
 init.c.patch [^] (1,321 bytes) 09-18-08 23:24
 serial.log [^] (63,265 bytes) 09-18-08 23:25

- Relationships

- Notes
(0011484)
Vladimir
09-15-08 22:35

Looks like system resources hunger.
Try

   while true
   do
        ls -l
        free
   done

Is free memory decreasing?
 
(0011494)
vda
09-16-08 14:34

Regarding your "killall init" strace. It definitely working correctly - it signaled init with TERM:

# /strace -fF killall init
execve("/usr/bin/killall", ["killall", "init"], [/* 12 vars */]) = 0
...
close(3) = 0
kill(1, SIGTERM) = 0
exit_group(0) = ?

so the reason why init does not reboot, is somewhere in init code (or in the script run from init when it gets TERM).
 
(0011504)
vda
09-16-08 14:38

While you run this:

while true; do ls -l; done

can you determine which telnetd process is responsible for this session, and run "strace -tt -o telnetd.log -p <telnetd's_pid>" until this hang happens? Attach resulting log to this bug. (You may want to daemonize strace process so that it does not require a separate telnet connection to be open).
 
(0011514)
xmuchgw
09-16-08 18:51
edited on: 09-16-08 19:02

1)When I run the script as follow
   while true
   do
        ls -l
        free
   done
Found the free memory is not decreasing.

2)I think halt.c has sent the SIGTERM signal to the init process.
But init process can not receive the signal. Because my debug messages in init.c are not printed.

3)HyperTerminal/minicom is connected with development board's ttyS0. I run the script in HyperTerminal/minicom, not in telnet terminal. When the HyperTerminal/minicom hangs, I open a telnet terminal to run "strace -tt -o telnetd.log -p <telnetd's_pid> &". And then run reboot. Look at the attached telnetd.log please.

 
(0011614)
vda
09-18-08 15:31

> Because my debug messages in init.c are not printed.

Can you show what messages did you add there? (Simply attach a patch to this bug).
 
(0011624)
vda
09-18-08 15:36

> 3)HyperTerminal/minicom is connected with development board's ttyS0. I run the script in HyperTerminal/minicom, not in telnet terminal.

Aha, so the the session over serial link hangs, not telnet session. What program is uses to initiate this session? getty or something else?

> When the HyperTerminal/minicom hangs, I open a telnet terminal to run "strace -tt -o telnetd.log -p <telnetd's_pid> &". And then run reboot.

strace serial session then, not telnetd. "strace -tt -o serial.log -f -p <ash's pid> &". And start strace BEFORE you run "while" loop, because you need to capture the moment it hangs.

> Look at the attached telnetd.log please.

Because you straced your own telnetd session, I just see "reboot" being run there. Not useful.
 
(0011654)
xmuchgw
09-18-08 23:26

>Aha, so the the session over serial link hangs, not telnet session. What program is uses to initiate this session? getty or something else?
  The driver of my serial is 8250.c base on linux kernel 2.6.23. My /etc/inittab is as follow:
# Note: BusyBox init works just fine without an inittab. If no inittab is
# found, it has the following default behavior:
         ::sysinit:/etc/init.d/rcS
         ::ctrlaltdel:/sbin/reboot
         ::shutdown:/sbin/swapoff -a
         ::shutdown:/bin/umount -a -r
         ::restart:/sbin/init
# Start an "askfirst" shell on the console (whatever that may be)
        ::askfirst:-/bin/sh


>strace serial session then, not telnetd. "strace -tt -o serial.log -f -p <ash's pid> &". And start strace BEFORE you run "while" loop, because you need to capture the moment it hangs.
  Because the output message is too much. I only list the bottom message in serial.log file. Look at the attached serial.log please

>Can you show what messages did you add there? (Simply attach a patch to this bug).
  Please look at the init.c.patch.
 
(0011694)
vda
09-19-08 16:22

> The driver of my serial is 8250.c base on linux kernel 2.6.23. My /etc/inittab is as follow:
> ::askfirst:-/bin/sh

So it's a bare shell. Hmm. Try "exec getty <baudrate> -" and log in from resulting login prompt. Now run the test, does it still hang? (getty does some tty setup, maybe it would help).

>> strace serial session
> Because the output message is too much. I only list the bottom message in serial.log file. Look at the attached serial.log please

It shows that last write() syscall has blocked, as if kernel thinks the buffer is full or something like that.

> Please look at the init.c.patch.

static void halt_reboot_pwoff(int sig)
 {
        const char *m;
        int rb;
+ printf(__FILE__" [line: %d]\n", __LINE__);
+ message(L_CONSOLE | L_LOG, "[chgw] in function halt_reboot_pwoff!");

Not reliable if serial line is already bothched. may block.

+#ifdef R_DBG
+ printf(__FILE__" [line: %d] enable R_DBG\n", __LINE__);
+ if((dbg_fd=open("debug.log", O_WRONLY |O_TRUNC | O_CREAT | O_SYNC)) < 0)

Good idea to write a file to disk.
You forgot the mode (3rd param): open(name, O_xxx, 0666)
BTW, in strace I see that "debug.log" indeed exists. So signal handler in init.c _is reached_.

+ if(5 != write(dbg_fd, "11111", 5))
+ {
+ printf("open write 11111 error\n");
+ }

Don't bother with error checks. just use write(dbg_fd, "11111", 5), it's just debugging after all.

Add more such write's to find out where it stops in init.c
 
(0012334)
vda
09-28-08 16:19

xmuchgw, any news?
 
(0012514)
xmuchgw
09-29-08 19:20

I don't have any process.
I think it's my serial driver's problem. But I don't have any evidence to prove that. I am investigating it right now.
I will let you know if I have any process.
Thanks a lot for you support.
 
(0013684)
xmuchgw
10-16-08 02:44

I can not fix this bug.
I am sorry I give up to fix it.
 
(0013694)
vda
10-16-08 03:13

You were doing just fine in comment "09-18-08 23:26", I thought you will continue the same procedure - inserting write()s to a debug file in init code. It is a relatively simple way to find where is it stuck. And if you will find that place, it's possible you will just need to remove a code which tries to write to stdout/stderr and blocks on serial output there.

That might fix the bug.

If not, at least you will be able to show where exactly it hangs (blocks).
 

- Issue History
Date Modified Username Field Change
09-15-08 22:08 xmuchgw New Issue
09-15-08 22:08 xmuchgw Status new => assigned
09-15-08 22:08 xmuchgw Assigned To  => BusyBox
09-15-08 22:35 Vladimir Note Added: 0011484
09-16-08 01:42 xmuchgw File Added: 2008-09-16.txt
09-16-08 14:34 vda Note Added: 0011494
09-16-08 14:38 vda Note Added: 0011504
09-16-08 18:51 xmuchgw Note Added: 0011514
09-16-08 19:01 xmuchgw Note Edited: 0011514
09-16-08 19:02 xmuchgw Note Edited: 0011514
09-16-08 19:19 xmuchgw File Added: telnetd.log
09-18-08 15:31 vda Note Added: 0011614
09-18-08 15:36 vda Note Added: 0011624
09-18-08 23:24 xmuchgw File Added: init.c.patch
09-18-08 23:25 xmuchgw File Added: serial.log
09-18-08 23:26 xmuchgw Note Added: 0011654
09-19-08 16:22 vda Note Added: 0011694
09-28-08 16:19 vda Note Added: 0012334
09-29-08 19:20 xmuchgw Note Added: 0012514
10-16-08 02:44 xmuchgw Note Added: 0013684
10-16-08 03:13 vda Note Added: 0013694
10-27-08 05:38 vda Status assigned => closed
10-27-08 05:38 vda Resolution open => unable to reproduce


Copyright © 2000 - 2006 Mantis Group
Powered by Mantis Bugtracker