[#4194] [ltp] A bug in LTP test case cause execve05 crashed in smp kernel

Submitted By: Vivi Li

Open Date

2008-06-24 22:16:57 Close Date

2009-03-02 05:11:02

Priority:

Medium Assignee:

Sonic Zhang

Status:

Closed Fixed In Release:

N/A

Found In Release:

N/A Release:

Category:

N/A Board:

N/A

Processor:

BF561 Silicon Revision:

Is this bug repeatable?:

Yes Resolution:

Fixed

Uboot version or rev.:

Toolchain version or rev.:

08r1.5-11

App binary format:

N/A

Summary: [ltp] A bug in LTP test case cause execve05 crashed in smp kernel

Details:

For smp kernel enabled with write through and slob options, ltp test case execve05 crashed.

This ltp case is not compiled with -mstack-check-l1 option.

root:/> export PATH=$PATH:/bin

root:/> export TMP=/tmp

root:/> echo $PATH

/bin:/usr/bin:/etc:/sbin:/usr/sbin:/bin

root:/> chmod 777 /tmp

root:/>

root:/> execve05 -F /bin/test3

NULL pointer access (probably) from 0x00240e02 on CPU0

Defered Exception context

CURRENT PROCESS:

COMM=test3 PID=109

TEXT = 0x00240040-0x00240f60 DATA = 0x00240f64-0x00241104

BSS = 0x00241104-0x00241354 USER-STACK = 0x00249fe4

return address: [0x00240e02]; contents of:

0x00240de0: 0010 434b c682 8043 5603 c682 8280 e146

0x00240df0: 7efe e147 8101 3212 5748 e106 feff e107

0x00240e00: 0100 [9012] 5032 43d1 5808 5438 0c00 1408

0x00240e10: 5815 5070 43c0 5841 5479 0c01 1ff3 e491

SEQUENCER STATUS: Not tainted

SEQSTAT: 00002027 IPEND: 0030 SYSCFG: 0036

HWERRCAUSE: 0x0

EXCAUSE : 0x27

RETE: <0x00000000> /* Maybe null pointer? */

RETN: <0x00256000> /* unknown address */

RETX: <0x00240e02> [ test3 + 0xdc2 ]

RETS: <0x00240be0> [ test3 + 0xba0 ]

PC : <0x00240e02> [ test3 + 0xdc2 ]

DCPLB_FAULT_ADDR: <0x00000000> /* Maybe null pointer? */

ICPLB_FAULT_ADDR: <0x00240e02> [ test3 + 0xdc2 ]

PROCESSOR STATE:

R0 : 00002f2f R1 : 2f2f0000 R2 : 00000000 R3 : 0000002f

R4 : 00240140 R5 : 2f2f2f2f R6 : 7efefeff R7 : 81010100

P0 : 00249f5d P1 : 00000003 P2 : 00000000 P3 : 00249fe8

P4 : 0094c2d4 P5 : 00240f64 FP : 00249f68 SP : 00255f24

LB0: 00240aa5 LT0: 00240aa4 LC0: 00000000

LB1: 03211c9d LT1: 03211c96 LC1: 00000000

B0 : 00000000 L0 : 00000000 M0 : 00000000 I0 : 00249efd

B1 : 00000000 L1 : 00000000 M1 : 00000000 I1 : 00958f58

B2 : 00000000 L2 : 00000000 M2 : 00000000 I2 : 00000000

B3 : 00000000 L3 : 00000000 M3 : 00000000 I3 : 00000000

A0.w: 00000000 A0.x: 00000000 A1.w: 00000000 A1.x: 00000000

USP : 00249f68 ASTAT: 02002020

Hardware Trace:

0 Target : <0x00004f4c> { _trap_c + 0x0 }

Source : <0x00009d40> { _exception_to_level5 + 0xc0 }

1 Target : <0x00009d00> { _exception_to_level5 + 0x80 }

Source : <0x00009cf6> { _exception_to_level5 + 0x76 }

2 Target : <0x00009c80> { _exception_to_level5 + 0x0 }

Source : <0x00009bd8> { _ex_trap_c + 0x68 }

3 Target : <0x00009bb2> { _ex_trap_c + 0x42 }

Source : <0x00009ba8> { _ex_trap_c + 0x38 }

4 Target : <0x00009b70> { _ex_trap_c + 0x0 }

Source : <0x0000990a> { _ex_workaround_261 + 0x3a }

5 Target : <0x000098f2> { _ex_workaround_261 + 0x22 }

Source : <0x000098e8> { _ex_workaround_261 + 0x18 }

6 Target : <0x000098d0> { _ex_workaround_261 + 0x0 }

Source : <0x00009e0c> { _trap + 0x64 }

7 Target : <0x00009dec> { _trap + 0x44 }

Source : <0x00009ddc> { _trap + 0x34 }

8 Target : <0x00009dd4> { _trap + 0x2c }

Source : <0x00009de0> { _trap + 0x38 }

9 Target : <0x00009dde> { _trap + 0x36 }

Source : <0x00009dcc> { _trap + 0x24 }

10 Target : <0x00009da8> { _trap + 0x0 }

Source : <0x00009b12> { _bfin_return_from_exception + 0xe }

11 Target : <0x00009b04> { _bfin_return_from_exception + 0x0 }

Source : <0x000098fa> { _ex_workaround_261 + 0x2a }

12 Target : <0x000098f2> { _ex_workaround_261 + 0x22 }

Source : <0x000098e8> { _ex_workaround_261 + 0x18 }

13 Target : <0x000098d0> { _ex_workaround_261 + 0x0 }

Source : <0x00009e0c> { _trap + 0x64 }

14 Target : <0x00009dec> { _trap + 0x44 }

Source : <0x00009ddc> { _trap + 0x34 }

15 Target : <0x00009dd4> { _trap + 0x2c }

Source : <0x00009de0> { _trap + 0x38 }

Stack from 00255f04:

00000000 00009d44 ffb00028 ffb00028 ffb00024 00249f5c 00240140 0024082c

00240e02 00000030 00002027 00000000 00256000 00240e02 00240e02 00240be0

00002f2f 02002020 03211c9d 00240aa5 03211c96 00240aa4 00000000 00000000

00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

00000000 00000000 00958f58 00249efd 00249f68 00249f68 00240f64 0094c2d4

Call Trace:

[<00002f2f>] _do_rt_sigreturn+0x7e7/0x888

Follow-ups

--- Graf Yang 2008-06-27 07:25:55

This is not the kernel bug.

execve05.c have two issues:

1.Assume firstly forked thread will run before secondly forked thread, this

cause s the test maybe fail.

2.When test fail, it will call execve(test_name, argv, env) with argv[0]=0,

this causes the NULL pointer dump.

--- Robin Getz 2008-06-27 10:21:47

If this is a test case issue - it still needs to get fixed - but I would think

that it would have been found on other SMP machines. ?

--- Mike Frysinger 2008-06-27 11:41:49

the point of the sync pipe logic is to prevent any race conditions. so it

doesnt matter what order things run in initially as the sync pipe will force

explicit order.

the crash due to argv[0] being NULL is a bug in uClibc, not the test case

--- Mike Frysinger 2008-06-27 15:14:16

ive committed a fix for the argv[0] = NULL bug in uClibc

--- Graf Yang 2008-06-28 02:11:24

Hi Mike, What is the 'sync pipe'? Is it related with execve05.c?

I found the thread child2 sometimes call execve(test_name,...) prior to thread

child1 opening test_name. In this case test failed. Otherwise it pass.

Hi Robin, I tested execve05 on my Dell-D630(Intel Core2 cpu), all passed. In

all the cases the child1 will opening 'test_name' prior to child2, and child2

get the error ETXTBSY, it's just the expected result of execve05.c.

If I add a sleep(1) in the child1 (before it call open(test_name, O_WRONLY)),

the test not pass.

I guess the execve05.c just want to get the ETXTBSY which returned by

execve(test_name,...), when the file have been opened with O_WRONLY flag. But it

seems execve05.c can't ensure the file be opened before it is execved. Maybe we

can add a sleep(1) before execve(test_name, ...) to ensure the open operation is

prior to execve().

What's your opion?

--- Mike Frysinger 2008-06-28 05:29:07

i was looking at the execve05.c that we have in ltp trunk. it uses sync pipes

to force strict ordering. it seems the old version of ltp we're using does not

have this code, so it fails.

--- Robin Getz 2009-01-08 14:41:44

It sounds like this should go away when we update to latest LTP?

--- Vivi Li 2009-01-08 23:06:31

Cause there is SMP boot problem at present, I will test it after this bug is

fixed.

--- Sonic Zhang 2009-01-14 22:16:00

Fixed. Don't add l1 stack check flag for SMP kernel.

Also add proper file open flags and modes.

--- Vivi Li 2009-03-02 05:11:02

OK, close it. Thanks!

Files

Changes

Commits

Dependencies

Duplicates

Associations