Menu
▾
▴
#314 thread/stress.icn only fails half the time
Testing an old git from ~ 4/21/21
with old gcc 10.2 (ubuntu)
stress.icn fails about half the time.
memory violation
No errors w. recent gcc 9 on newer git.
Runtime is ~1sec on a 6 core ryzen, ~6sec on an old 4 core A10.
Can you scale the test? Maybe repeat if under 4 seconds wall clock?
Related
@cvevans, have you try increasing the run time on the Ryzen machine and observed any failures ?
I did boost it 10x, and failure rate is about the same.
Most failures are early, but I did see one later on.
I just did a build with
-O3 -march=bdver1 -mno-fma4 -mno-xop -mno-lwp
(runs on AMD bulldozer or newer AMD)
and got no failures yet at 10x runtime on 6 core Ryzen
11s clock
1m27s CPU time
build with
-march=znver2
fails every time at startup
(all on last year's gcc10)
-march=core2
(runs on intel core2, athlon64, or newer)
all thread tests ok,
no fails yet on stress
-march=nocona -mno-sse3
(runs on intel p4-nocona, core2, athlon64, or newer)
(correction, -march=core2 is core2 or bulldozer or newer)
stress ran 10x, no fails
possible fix:
add
-fno-strict-aliasing
to LDFLAGS
After running prelink on the test system, I can no longer reproduce the failure in stress.
We probably need stress to continually create new threads, as most failures were very early.
FYI: stress always gives immediate memory violation or segfault
on an i9 12900, ubuntustudio jammy livecd,
slightly older kernel 5.15.0-54
Note: this is still old 12/22/2020 v13.3 unicon
cobench and stressco are fine.
update:
still fails > 1 in 8 runs on Zen2 ryzen
Unicon master @ 230612
Ubuntu budgie livecd 230904,
kernel 6.2.0-32-generic,
NO prelink
Gcc 11.4.0-1ubuntu1~22.04 @ 230513
Stress.icn ran 8x ok, then memory violation ,
twice.
But:
set CFLAGS to -O3 -march=znver2 ...
rebuilt on overlayfs, ran 110x ok!
Last edit: Charles Evans 2023-09-22
link w. -fno-strict-aliasing
did not help
I've probably seen this - I have a program that eats and breathes
threads (it searches for the shortest path through a maze trying paths
in parallel) that consistently dies with a memory violation on a 180x60
maze, and often dies on smaller mazes. It appears to be somewhere in
the C code but I don't know enough to track it down. If you get a fix
for you problem I'll try it on mine!
On 9/22/23 10:38, Charles Evans wrote:
--
Steve Wampler - sbw@tapestry.tucson.az.us
The gods that smiled at your birth are now laughing out loud - fortune cookie
Related
Bugs: #314
Steve, did you do a build ?
run configure with any options?
with ./configure --enable-ovld
gdb reports segfault in
markblock at rmemmgt.r:1020
valgrind reports many overreads ,
all 8 bytes
fyi : stress does not do overloading
fyi: overloading fails GC if threaded
bug[#183]
so far non-ovld iconx ran stress clean (once)
in valgrind.
Related
Bugs: #183
ovld:
valgrind stress : 1 good run
next run 10 errors,
invalid read size 4
in sweep (rmemmgt.r:1316)
address is not stack'd, malloc'd or recently free'd