Software Archive
Read-only legacy content
17061 ディスカッション

cilkscreen returns 0 when races found

zardosht_kasheff
ビギナー
1,196件の閲覧回数
When running cilkscreen on the compiled output of simple_race.cpp (that comes as an example with cilkscreen), we noticed that cilkscreen returns 0 even though races are found.

Is there any way to get it to return non-zero? This makes automated testing more difficult.
0 件の賞賛
9 返答(返信)
Brandon_H_Intel
従業員
1,196件の閲覧回数
Hi Zardosht,

I've submitted this feature request. The Cilk Plus team will consider it, and I'll keep you up to date on their status.
Brandon_H_Intel
従業員
1,196件の閲覧回数
Hi Zardosht,

The version of cilkscreen available now that supports 12.1 now implements this functionality under a -c option passed to cilkscreen. Let me know if you have any further questions.
BradleyKuszmaul
ビギナー
1,196件の閲覧回数
There may stil bel a minor bug in the way the new version of cilkscreen works. The manual says that the exit code the number of races detected. What if 256 races are detected? If you call exit(N) then the exit code equals N%256. Could cilkscreen return 0 when there a nonzero number of races?
I think it would make more sense to return a particular exit code (specified on the command line) when a race is detected. Look at how valgrind handles --error-exitcode
-Bradley
Barry_T_Intel
従業員
1,196件の閲覧回数

I hadn't realized that Linux limited the exit codes to 0-255. Is there a reason for the limit? The exit() function takes a full in, not a char.

In any event, I'll change it as follows:

If you don't specify -c, the return code is the value returned by the application. This matches the prior behavior.

If you specify -c , Cilkscreen will return if any errors are found. If no errors are found, Cilkscreen will return 0.

- Barry

BradleyKuszmaul
ビギナー
1,196件の閲覧回数
It has to do with the way the wait(2) system call is designed. They pack a bunch of information into an integer (e.g., did the process exit or signal?) They allocated only 8 bits for the exit code.

Take a look at the man page for wait(2), looking at the documentation for WEXITSTATUS.
This is a unix-ism. As far as I can tell, the C99 standard just defines EXIT_SUCCESS and EXIT_FAILURE. Other exit values are undefined. I think EXIT_SUCCESS is defined to be zero.

I understand that on Windows the exit code can be an integer. You could still get an overflow, and I don't know what happens.
BradleyKuszmaul
ビギナー
1,196件の閲覧回数
Also, cilkscreen should return whatever the application returns if no errors are found:
application returns 0, no cilkscreen errors --> return 0.
application returns R, no cilkscreen errors --> return R.
application returns R, cilkscreen errors, -c C specified --> return C.
application returns R, cilkscreen errors, no C specified, return R.
Barry_T_Intel
従業員
1,196件の閲覧回数
> Also, cilkscreen should return whatever the application returns if no errors are found

Then how do you differentiate between "Cilkscreen found no errors" and "The application returned an error"?

- Barry
BradleyKuszmaul
ビギナー
1,196件の閲覧回数
(a) It's usually not important to distinguish between Cilkscreen errors and application errors. We run cilkscreen (and valgrind) in automated tests. We need to know whether the test succeeded, not how it failed. If a test is failing we can watch it more carefully to figure out what's going on.
(b) When we do need to distinguish, we use a different error code. For all the code we run under valgrind, we know what possible exit status codes it might use. We tell valgrind to use a different error code.
We want to be able to use Cilkscreen the way we use Valgrind in automated tests.
-Bradley
Barry_T_Intel
従業員
1,196件の閲覧回数
OK. That's what I'll implement.

- Barry
返信