[#3816] [ltp] Some ltp test cases will crash when invoked without specifying path

Document created by Aaronwu Employee on Aug 28, 2013
Version 1Show Document
  • View in full screen mode

[#3816] [ltp] Some ltp test cases will crash when invoked without specifying path

Submitted By: Vivi Li

Open Date

2008-01-07 03:40:55     Close Date

2008-02-13 02:58:14

Priority:

Medium     Assignee:

Mike Frysinger

Bryan Wu

Status:

Closed     Fixed In Release:

N/A

Found In Release:

N/A     Release:

Category:

N/A     Board:

N/A

Processor:

N/A     Silicon Revision:

Is this bug repeatable?:

Yes     Resolution:

Fixed

Uboot version or rev.:

    Toolchain version or rev.:

toolchain-2008_Jan_01

App binary format:

N/A     

Summary: [ltp] Some ltp test cases will crash when invoked without specifying path

Details:

 

Some ltp test cases will crash when invoked without specifying path. Take fcntl21 as a example:

 

Put fcntl21 in /bin, then invoke it as "./fcntl21", it will pass.

----

root:/bin> ./fcntl21

fcntl21     0  INFO  :  Enter block 1

fcntl21     0  INFO  :  Test block 1: PASSED

fcntl21     0  INFO  :  Exit block 1

fcntl21     0  INFO  :  Enter block 2

fcntl21     0  INFO  :  Test block 2: PASSED

fcntl21     0  INFO  :  Exit block 2

fcntl21     0  INFO  :  Enter block 3

fcntl21     0  INFO  :  Test block 3 : PASSED

fcntl21     0  INFO  :  Exit block 3

fcntl21     0  INFO  :  Enter block 4

fcntl21     0  INFO  :  Test block 4: PASSED

fcntl21     0  INFO  :  Exit block 4

fcntl21     0  INFO  :  Enter block 5

fcntl21     0  INFO  :  Test block 5: PASSED

fcntl21     0  INFO  :  Exit block 5

fcntl21     0  INFO  :  Enter block 6

fcntl21     0  INFO  :  Test block 6 PASSED

fcntl21     0  INFO  :  Exit block 6

fcntl21     0  INFO  :  Enter block 7

fcntl21     0  INFO  :  Test block 7: PASSED

fcntl21     0  INFO  :  Exit block 7

fcntl21     0  INFO  :  Enter block 8

fcntl21     0  INFO  :  Test block 8: PASSED

fcntl21     0  INFO  :  Exit block 8

fcntl21     0  INFO  :  Enter block 9

fcntl21     0  INFO  :  Test block 9: PASSED

fcntl21     0  INFO  :  Exit block 9

fcntl21     0  INFO  :  Enter block 10

fcntl21     0  INFO  :  Test block 10: PASSED

fcntl21     0  INFO  :  Exit block 10

fcntl21     0  INFO  :  Enter block 11

fcntl21     0  INFO  :  Test block 11: PASSED

fcntl21     0  INFO  :  Exit block 11

root:/bin>

----

 

Put fcntl21 in /bin, then invoke it as "fcntl21", it will crash.

----

root:/bin> fcntl21

NULL pointer access (probably)

Defered Exception context

CURRENT PROCESS:

COMM=fcntl21 PID=139

TEXT = 0x00320040-0x0032bf00  DATA = 0x0032bf04-0x0032f024

BSS = 0x0032f024-0x00333f14   USER-STACK = 0x00334f78

 

return address: [0x00326c72]; contents of:

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

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

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

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

 

SEQUENCER STATUS:

SEQSTAT: 00060027  IPEND: 0030  SYSCFG: 0006

  HWERRCAUSE: 0x18

  EXCAUSE   : 0x27

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

RETN: <0x00320000> [ fcntl21 + 0x0 ]

RETX: <0x00326c72> [ fcntl21 + 0x6c32 ]

RETS: <0x00326f74> [ fcntl21 + 0x6f34 ]

PC  : <0x00326c72> [ fcntl21 + 0x6c32 ]

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

ICPLB_FAULT_ADDR: <0x00326c72> [ fcntl21 + 0x6c32 ]

 

PROCESSOR STATE:

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

R4 : 003207b4    R5 : 2f2f2f2f    R6 : 7efefeff    R7 : 81010100

P0 : 00334ef1    P1 : 00000003    P2 : 00000000    P3 : 00334f7c

P4 : 00414fc0    P5 : 0032bf04    FP : 00334efc    SP : 0031ff24

LB0: 00326b59    LT0: 00326b58    LC0: 00000000

LB1: 00405ed5    LT1: 00405ed4    LC1: 00000000

B0 : 00000000    L0 : 00000000    M0 : 00000000    I0 : 00334e91

B1 : 00000000    L1 : 00000000    M1 : 00000000    I1 : 00414f70

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

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

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

USP : 00334efc  ASTAT: 02002020

 

Hardware Trace:

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

     Source : <0xffa00ad4> { _exception_to_level5 + 0xb4 }

   1 Target : <0xffa00a20> { _exception_to_level5 + 0x0 }

     Source : <0xffa00978> { _ex_trap_c + 0x5c }

   2 Target : <0xffa0091c> { _ex_trap_c + 0x0 }

     Source : <0xffa007a4> { _ex_workaround_261 + 0x1c }

   3 Target : <0xffa00788> { _ex_workaround_261 + 0x0 }

     Source : <0xffa00b74> { _trap + 0x28 }

   4 Target : <0xffa00b4c> { _trap + 0x0 }

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

   5 Target : <0xffa008b0> { _bfin_return_from_exception + 0x0 }

     Source : <0xffa0079a> { _ex_workaround_261 + 0x12 }

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

     Source : <0xffa00b74> { _trap + 0x28 }

   7 Target : <0xffa00b4c> { _trap + 0x0 }

     Source : <0x00326c6e> [ fcntl21 + 0x6c2e ]

   8 Target : <0x00326c52> [ fcntl21 + 0x6c12 ]

     Source : <0x00326c22> [ fcntl21 + 0x6be2 ]

   9 Target : <0x00326c14> [ fcntl21 + 0x6bd4 ]

     Source : <0x00326f70> [ fcntl21 + 0x6f30 ]

  10 Target : <0x00326f6c> [ fcntl21 + 0x6f2c ]

     Source : <0x00326f64> [ fcntl21 + 0x6f24 ]

  11 Target : <0x00326f54> [ fcntl21 + 0x6f14 ]

     Source : <0x00328902> [ fcntl21 + 0x88c2 ]

  12 Target : <0x003288e6> [ fcntl21 + 0x88a6 ]

     Source : <0x003258e8> [ fcntl21 + 0x58a8 ]

  13 Target : <0x003258d6> [ fcntl21 + 0x5896 ]

     Source : <0x003270c4> [ fcntl21 + 0x7084 ]

  14 Target : <0x003270bc> [ fcntl21 + 0x707c ]

     Source : <0x00327114> [ fcntl21 + 0x70d4 ]

  15 Target : <0x0032710c> [ fcntl21 + 0x70cc ]

     Source : <0x00326b5a> [ fcntl21 + 0x6b1a ]

Stack from 0031ff04:

        00000000 ffa00ad8 00144790 00144790 00144784 00334ef0 003207b4 00328b34

        00326c72 00000030 00060027 00000000 00320000 00326c72 00326c72 00326f74

        00002f2f 02002020 00405ed5 00326b59 00405ed4 00326b58 00000000 00000000

        00000017 00000000 00000017 00000000 00000000 00000000 00000000 00000000

        00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

        00000000 00000000 00414f70 00334e91 00334efc 00334efc 0032bf04 00414fc0

 

Call Trace:

[<00002f2f>] _do_signal+0x2df/0xd74

[<00002f2f>] _do_signal+0x2df/0xd74

 

cd /bin

fcntl21     0  INFO  :  Enter block 1

fcntl21     1  FAIL  :  Unexpected death of child process

root:/bin>

----

 

 

I tested on ltp-full-20071031 with toolchain-2008_Jan_01 and latest kernel source.

When I tested ltp-full-20071031 with toolchain-2007_Oct_07 and latest kernel, no such problem.

 

The similar problem happens to following test cases:

execve05, fcntl15, fcntl17, fcntl19, fcntl20, fcntl21, flock03, kill03, kill04, kill06, kill07, kill08, kill12, mkdir09, msgctl07, msgrcv01, msgrcv05, msgrcv06, msgsnd05, msgsnd06, nanosleep03, pipe02, pipe04, pipe11, ptrace01, ptrace02, recv01, recvfrom01, recvmsg01, rename14, rmdir03, etc.

 

Follow-ups

 

--- Bryan Wu                                                 2008-01-18 05:13:57

This should be a toolchain issue.

 

Same kernel and same LTP source code compiled with different toolchain.

2007-Nov-29 toolchain fails

2007-Nov-22 toolchain pass

 

-Bryan Wu

 

--- Mike Frysinger                                           2008-01-18 05:22:55

please test with a toolchain from today as there have been some exec fixes in

there

 

--- Bryan Wu                                                 2008-01-19 04:19:22

I tested the latest toolchain which is toolchain-2008_Jan_19_03_36 copied from

Vivi's auto-building machine.

 

This issue is still there.

 

-Bryan

 

--- Bryan Wu                                                 2008-01-20 21:20:58

Hi Bernd,

 

I am not very sure it's following patch introduced this bug:

 

libc/unistd/exec.c

---

r1975 | bernds | 2007-11-23 08:38:06 +0800 (Fri, 23 Nov 2007) | 7 lines

 

Upstream r19163 | vda | 2007-07-19 00:32:40 +0200 (Thu, 19 Jul 2007) | 5 lines

 

execXp should go to next PATH dir on any error except ENOEXEC,

not just on ENOENT (in particular, on EPERM). At least glibc does so.

Fixing this.

---

 

From Nov 22, 2007 to Nov 28, 2007, Toolchain got lots of checkin mainly related

with uClibc update.

 

Could you please help me to take a look at this?

 

Thanks

Regards,

-Bryan Wu

 

--- Mike Frysinger                                           2008-01-21 02:49:41

i'm looking at it for a different bug Robin pointed out

 

--- Mike Frysinger                                           2008-01-26 04:41:25

please retest with latest trunk / branch

 

--- Bryan Wu                                                 2008-01-28 23:14:12

yes, it fixed.

 

I tested with 28/01/2008 08R1 branch toolchain.

After I get latest trunk toolchain, I will retest it.

 

Thanks

-Bryan

 

--- Bryan Wu                                                 2008-01-29 04:20:04

Tested 28/01/2008 trunk toolchain, it's fixed.

 

Vivi, could you please validate and close this bug.

 

Thanks

-Bryan

 

--- Vivi Li                                                  2008-02-13 05:06:58

It's OK now. So close it. Thanks!

 

 

 

    Files

    Changes

    Commits

    Dependencies

    Duplicates

    Associations

    Tags

 

File Name     File Type     File Size     Posted By

No Files Were Found

Attachments

    Outcomes