Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

replaying a built-in returned a different result than expected #77

Closed
NOMORECOFFEE opened this issue Dec 8, 2015 · 3 comments
Closed
Labels
bug Issues where the tool is not behaving according to expectations. help wanted Issues that anyone could start working on. An invitation to the community.

Comments

@NOMORECOFFEE
Copy link

I got this error message while running concurerror

veselov@poisk-001:/media/data/Concuerror$ ./concuerror -m send_order
Concuerror started at 08 Dec 2015 13:11:11
Writing results in concuerror_report.txt

Info: Instrumented io_lib
Info: Instrumented send_order
Info: Instrumented crypto
Info: Instrumented erlang
Info: You can see pairs of racing instructions (in the report and --graph) with '--show_races true'
Error: On step 1, replaying a built-in returned a different result than expected:
  original:
    {event,<0.53.0>,
       {builtin_event,<0.53.0>,undefined,false,
                      {erlang,spawn,
                              [erlang,apply,[#Fun<send_order.1.58635779>,[]]]},
                      <0.63.0>,ok,false},
       #Ref<0.0.0.133>,
       [2318,{file,"erlang.erl"}],
       [{new,<0.63.0>}]}
  new:
    {event,<0.53.0>,
       {builtin_event,<0.53.0>,undefined,false,
                      {erlang,spawn,
                              [erlang,apply,[#Fun<send_order.1.58635779>,[]]]},
                      <0.63.0>,ok,false},
       #Ref<0.0.0.133>,
       [2318,{file,"erlang.erl"}],
       [{new,<0.63.0>}]}

Please notify the developers, as this is a bug of Concuerror.

Done! (Exit status: error)
  Summary: 1 errors, 2/128 interleavings explored
-module(send_order).
-export([test/0]).

test() ->
    Orig = [I || <<I>> <= crypto:rand_bytes(128)],
    Master = self(),
    [spawn(fun() -> Master ! I end) || I <- Orig],
    Orig = [receive I -> I end || _ <- Orig].
@aronisstav
Copy link
Member

Thanks for the bug report!

The problem here is the call to crypto:rand_bytes/1, which ultimately results to a call to a NIF, whose result is impossible to control just by instrumenting the Erlang source code. Concuerror requires this level of control, in order to be able to ensure that it can reach the 'same state' as in a previous scheduling and only afterwards have different things happening.

Concuerror should of course report this limitation and not crash. I will write a patch for this, but it will not really make the particular test work, just fail in a better way.

@NOMORECOFFEE
Copy link
Author

Thanks @aronisstav !

this is test with crypto:rand_bytes/1 work

-module(sleep_sort).
-export([test/0]).

test() ->
    Orig = [I || <<I>> <= crypto:rand_bytes(128)],
    Master = self(),
    Sorted = lists:sort(Orig),
    [spawn(fun() -> timer:sleep(I), Master ! I end) || I <- Orig],
    Sorted = [receive I -> I end || _ <- Orig].

@aronisstav
Copy link
Member

Indeed, but it shouldn't. It should have the same problem.

aronisstav added a commit to aronisstav/Concuerror that referenced this issue Dec 8, 2015
Stateless systematic testing requires that any state of the program that has
already been visited can be reached again just by making the same scheduling
choices. In order for this to work, one must control all other sources of
nondeterminism.

NIFs unfortunately cannot, in general, be guaranteed to return the same result
for each call with the same arguments. With this patch Concuerror aborts
attempts to run code that is loading NIFs.

Fixes parapluu#77.
@aronisstav aronisstav added the in progress There is someone currently working on the issue. Should have at least a branch that refers to it. label Dec 8, 2015
@aronisstav aronisstav added help wanted Issues that anyone could start working on. An invitation to the community. and removed in progress There is someone currently working on the issue. Should have at least a branch that refers to it. labels Jul 8, 2016
@aronisstav aronisstav added the bug Issues where the tool is not behaving according to expectations. label Dec 12, 2016
aronisstav added a commit to aronisstav/Concuerror that referenced this issue Mar 9, 2018
Stateless model checking requires that any state of the program
can reliably be reached just by making the
same scheduling choices. In order for this to work, one must control
all other sources of nondeterminism. NIFs cannot, in general, be
guaranteed to return the same result for each call with the same
arguments, nor can they be detected/intercepted.

With this patch Concuerror emits a warning when
instrumenting modules that may try to load NIFs.

Fixes parapluu#77.
aronisstav added a commit to aronisstav/Concuerror that referenced this issue Mar 12, 2018
With this patch Concuerror will emits a warning when
instrumenting modules that may try to load NIFs.

NIFs cannot, in general, be guaranteed to return the same result
for each call with the same arguments, nor can they be
detected/intercepted. Stateless model checking requires that any
state of the program can reliably be reached just by making the
same scheduling choices. In order for this to work, one must
control all other sources of nondeterminism.

Fixes parapluu#77.
aronisstav added a commit to aronisstav/Concuerror that referenced this issue Mar 12, 2018
With this patch Concuerror will emits a warning when
instrumenting modules that may try to load NIFs.

NIFs cannot, in general, be guaranteed to return the same result
for each call with the same arguments, nor can they be
detected/intercepted. Stateless model checking requires that any
state of the program can reliably be reached just by making the
same scheduling choices. In order for this to work, one must
control all other sources of nondeterminism.

Fixes parapluu#77.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Issues where the tool is not behaving according to expectations. help wanted Issues that anyone could start working on. An invitation to the community.
Projects
None yet
Development

No branches or pull requests

2 participants