Wind River Support Network

HomeDefectsLIN5-18562
Fixed

LIN5-18562 : After updates to RCPL12 from RCPL3, the read system call's behaviour was changed, and cause customer's application error.

Created: Apr 22, 2014    Updated: Dec 19, 2017
Resolved Date: May 4, 2014
Found In Version: 5.0.1.12
Fix Version: 5.0.1.15
Severity: Standard
Applicable for: Wind River Linux 5
Component/s: Kernel

Description

With the same application, but it do different behavior in WRLinux 5.0 RCPL3 and RCPL12
/************************************************************/
Differences:
RCPL3:
root@ localhost:~# ps -auf
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root     8510  0.0  0.0   3448  1700 pts/1    Ss   16:10   0:00 -sh
root     8507   1.1  0.1  25648  5080 pts/1    Sl+  16:12   0:00  \_ /local/bin/imish

RCPL12:
root@ PC2:~# ps -auf
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root     16863  0.0  0.0   3448  1700 pts/1    Ss   16:20   0:00 -sh
root     16828  1.1  0.1  25648  5080 pts/1    Sl+  16:32   0:00  \_ /local/bin/imish

After Kill -9 8510  and 16863 ,

RCPL3:
root@ localhost:~# ps -ef | grep imish
root     16874 16831  0 16:40 pts/2    00:00:00 grep imish

RCPL12:
root@PC2:~# ps -ef | grep imish
root     16828 16863  0 16:32 pts/1    00:00:00 /local/bin/imish
root     16874 16831  0 16:40 pts/2    00:00:00 grep imish

imish got in to wrong status and not exited in RCPL12 version; but RCPL3’ process has exited normally.
The attachment is the strace from killing parant process to the end. 
From the strace we can see in RCL12, there is a more line SIGCONT signal than RCPL3, is it the root cause?

Note: In customer’s process “imish”, they set 
SIGHUP ? action: SIGIGN;
SIGINT ? action: user defined.;
SIGTERM ? action: calling exit;
/************************************************************/


After investigation, this issue looks only have relation with kernel(update glibc will not trigger this issue).

The error occur in read function when application receiving SIGHUP(should ignore it), in application,  "read(0,buf,1)" returns 0 in RPCL3 but return -1 in RPCL12.

The different return value causes the final different process state.

RCPL3
/***********************************/
rt_sigaction(SIGHUP, {SIG_IGN, [HUP], SA_RESTART}, {0x805f4c0, [HUP], SA_RESTART}, 8) = 0 rt_sigprocmask(SIG_SETMASK, [HUP], NULL, 8) = 0
kill(0, SIGHUP)                         = 0
sigreturn() (mask [])                   = 3
--- SIGHUP {si_signo=SIGHUP, si_code=SI_USER, si_pid=8507, si_uid=0} ---
read(0, "", 1)                          = 0
time(NULL)                              = 1397232281
rt_sigprocmask(SIG_BLOCK, [HUP INT QUIT TERM CONT STOP TS /***********************************/


RCPL12
/***********************************/
rt_sigprocmask(SIG_BLOCK, [CONT], [HUP CONT], 8) = 0 rt_sigaction(SIGCONT, {SIG_DFL, [CONT], SA_RESTART}, {0x805f680, [CONT], SA_RESTART}, 8) = 0 rt_sigprocmask(SIG_SETMASK, [HUP CONT], NULL, 8) = 0
kill(0, SIGCONT)                        = 0
sigreturn() (mask [HUP])                = 1
--- SIGCONT {si_signo=SIGCONT, si_code=SI_USER, si_pid=16828, si_uid=0} --- rt_sigprocmask(SIG_BLOCK, [HUP], [HUP], 8) = 0 ioctl(0, SNDCTL_TMR_STOP or SNDRV_TIMER_IOCTL_GINFO or TCSETSW, {B38400 opost isig icanon echo ...}) = 0 rt_sigaction(SIGHUP, {SIG_IGN, [HUP], SA_RESTART}, {0x805f680, [HUP], SA_RESTART}, 8) = 0 rt_sigprocmask(SIG_SETMASK, [HUP], NULL, 8) = 0
kill(0, SIGHUP)                         = 0
sigreturn() (mask [])                   = 3
--- SIGHUP {si_signo=SIGHUP, si_code=SI_USER, si_pid=16828, si_uid=0} ---
read(0, 0xbfc8eb6f, 1)                  = -1 EIO (Input/output error)
write(1, "\7", 1)                       = -1 EIO (Input/output error)
ioctl(0, FIONREAD, [0])                 = 0
ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, {B38400 opost isig icanon echo ...}) = 0 ioctl(0, SNDCTL_TMR_STOP or SNDRV_TIMER_IOCTL_GINFO or TCSETSW, {B38400 opost isig -icanon -echo ...}) = 0
read(0, 0xbfc8eb6f, 1)                  = -1 EIO (Input/output error)
/***********************************/

Steps to Reproduce

Produce Steps:
1.         Use ssh to login on a target.
2.         Run example process.
3.         on target, run `strace -p xx`
4.         On another ssh sesssion, Kill -9 the parent process to see what happened to child process in strace log of target


I've put the example codes into attachment.

Other Downloads


Live chat
Online