[#4102] Exit status is not correct in msh

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

[#4102] Exit status is not correct in msh

Submitted By: Jie Zhang

Open Date

2008-05-14 04:03:56     Close Date

2008-07-20 21:05:22

Priority:

Low     Assignee:

Nobody

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.:

App binary format:

N/A     

Summary: Exit status is not correct in msh

Details:

 

msh returns wrong exit status for command that cannot execute correctly. According to

 

http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html

 

[quote]

The exit status of a command that terminated because it received a signal shall be reported as greater than 128.

[/quote]

 

The convention of bash is to return (128 + signal number). But msh returns -1 in that case.

 

[quote]

If a command is not found, the exit status shall be 127. If the command name is found, but it is not an executable utility, the exit status shall be 126.

[/quote]

 

But msh returns 255 for both cases.

 

The first case affects gcc testing. abort is called in toolchain test cases when they fail. A program calls abort kills itself with a SIGABRT signal. In msh, the exit status is -1 for that program. But Dejagnu can only handle exit status larger than or equal to 0. Thus Dejagnu gets 0 for the aborted program, which means success! So there are some tests in toolchain testing which are PASS now, but indeed they should be FAIL. And there are some other tests which are XPASS now, but should be XFAIL.

 

I'll commit a patch to fix the first case soon. The second case does not affect toolchain testing, I'll leave it open now.

 

Follow-ups

 

--- Michael Hennerich                                        2008-05-29 08:34:03

Exit code after signals was already fixed; so we fixed only ENOENT and

"cannot execute" cases to return 127 and 126.

 

Also has an unrelated fix to the case where ENOEXEC was correctly trying to

exec the shell but was passing incorrect argv[0].

--

vda

 

--- Jie Zhang                                                2008-07-20 21:05:21

Fixed. Close.

 

 

 

    Files

    Changes

    Commits

    Dependencies

    Duplicates

    Associations

    Tags

 

File Name     File Type     File Size     Posted By

No Files Were Found

Attachments

    Outcomes