https://bugs.kde.org/show_bug.cgi?id=410599
Bug ID: 410599
Summary: Non-deterministic behaviour of pth_self_kill_15_other
test
Product: valgrind
Version: 3.15 SVN
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: general
Assignee: jsew...@acm.org
Reporter: stefan.maksimo...@rt-rk.com
CC: mips3...@gmail.com
Target Milestone: ---
A recent commit
https://sourceware.org/git/?p=valgrind.git;a=commit;h=63a9f0793113fd5d828ea7b6183812ad71f924f1
has introduced a test which exhibits different behaviour on some platforms.
Namely, running the pth_self_kill_15_other test on these can end in either of
the following:
1) the spawned thread finishes first
2) the main thread finishes first
Running the test multiple times in succession we observed that on x86 the test
finishes as described in the 2) case
whereas on others either of the two cases can be present.
We have seen this behaviour on different arm and mips platforms.
In the 2) case the output we get corresponds with the .exp file while in the 1)
case we get an extra 'Terminated' string from the kernel on stderr.
Moreover, we ran the test on arm/mips without the functionality the rest of
that patch provides, to test whether it really hangs/loops on arm/mips or not.
Interestingly the pth_self_kill_9 test behaves the same on arm/mips and x86
whereas the pth_self_kill_15_other does finish on arm/mips
(it prints the 'Terminated' message - the spawned thread finishes first).
A possible solution would be to make the test deterministic; one way would
consist of inserting a pthread_join call.
That would alter the test in terms of the output produced but we believe that
the nature of the test itself would remain intact.
Reading the commit message which introduced the tests, we gather that the
purpose was to test two scenarios(loop/hang) which the
commit was created to solve.
In case the above suggested change would not disrupt the intended functionality
of the test, would it be applicable?
What course of action would you recommend?
--
You are receiving this mail because:
You are watching all bug changes.
