blob: 2955e22c52316ec08af356bc118bc0cb23ed548f (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
|
#!/bin/sh
# Trigger a bug that would cause 'sort' to reference stale thread stack memory.
# Copyright (C) 2010 Free Software Foundation, Inc.
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
# You should have received a copy of the GNU General Public License
# along with this program. If not, see <http://www.gnu.org/licenses/>.
# written by Jim Meyering and Paul Eggert
. "${srcdir=.}/init.sh"; path_prepend_ ../src
print_ver_ sort
very_expensive_
valgrind --help >/dev/null || skip_ "requires valgrind"
test "$(nproc)" = 1 && skip_ "requires a multi-core system"
# gensort output seems to trigger the failure more often,
# so prefer gensort if it is available.
(gensort -a 10000 in) 2>/dev/null ||
seq -f %-98f 10000 | shuf > in ||
framework_failure_
# With the bug, 'sort' would fail under valgrind about half the time,
# on some circa-2010 multicore Linux platforms. Run the test 100 times
# so that the probability of missing the bug should be about 1 in
# 2**100 on these hosts.
for i in $(seq 100); do
valgrind --quiet --error-exitcode=3 \
sort -S 100K --parallel=2 in > /dev/null ||
{ fail=$?; echo iteration $i failed; Exit $fail; }
done
Exit $fail
|