summaryrefslogtreecommitdiff
path: root/test/nptl/tst-kill4.c
diff options
context:
space:
mode:
authorVineet Gupta <Vineet.Gupta1@synopsys.com>2017-12-08 10:07:56 -0800
committerWaldemar Brodkorb <wbx@openadk.org>2017-12-10 10:49:38 +0100
commit6449cfcf3e58e05a101531cf612a658817c498a5 (patch)
tree2f2834b6a35dced854a2b7a9bf96d4dfce958a20 /test/nptl/tst-kill4.c
parentf95204473ee18e37bd69e8c007fe06a0e3ef4678 (diff)
Fix subtle race in tst-cancel2 / tst-cancelx2
When ran on ARC, these tests would ocassionally fail | [ARCLinux]# for i in 1 2 3 4 5 ; do ./tst-cancel2; echo $?; done | write succeeded | result is wrong: expected 0xffffffff, got 0x1 | 1 <-- fail | 0 <-- pass | 0 <--- pass | 0 <-- pass | write succeeded | result is wrong: expected 0xffffffff, got 0x1 | 1 <-- fail Same test (which originated form glibc) doesn't fail in glibc builds. Turns out there's a subtle race in uclibc version The test creates a new thread, makes it do a looong write call, and parent then cancels the thread, expecting it to unwind out of write call cleanly. However the write (even for 10k bytes) could finish before parent gets a chance to resume and/or cancel it, causing the occasional failure. Fix this subtelty by making it write not just once but forever. Cc: Cupertino Miranda <cmiranda@synopsys.com> Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
Diffstat (limited to 'test/nptl/tst-kill4.c')
0 files changed, 0 insertions, 0 deletions