Use TestExclusionList in bringup_runtest.sh #106201
Conversation
dotnet-issue-labeler
bot
added
the
needs-area-label
dotnet-policy-service
bot
added
the
community-contribution
|
cc @gbalykov this directory doesn't have src/ subpath under it: runtime/src/tests/Common/scripts/bringup_runtest.sh Lines 498 to 501 in 1a944fb is it some kind of a leftover? I have removed that block to run tests locally, can push the change here if someone could confirm. |
am11
added
area-Infrastructure-coreclr
and removed
needs-area-label
@am11 sorry for late response, I think so. Actually, in case of riscv64 cross build |
OK, I've deleted it. Thanks for confirming.
Sorry, I didn't follow. Could you explain / point me to it? With the current state of this PR (after the second commit), this script should just run with tests exclusion effective. I tested with these artifacts: https://github.com/am11/CrossRepoCITesting/releases/tag/linux-riscv64_10439230608 $ cat artifacts_part_aa artifacts_part_aab artifacts_part_ac > artifacts.tar.gz
# now untar artifacts.tar.gz and run testsit was created by this workflow https://github.com/am11/CrossRepoCITesting/actions/runs/10439230608/workflow (I basically used the steps you shared once) |
I mean that example value of |
|
I have a #!/bin/sh
root="$( cd -P "$( dirname "$0" )" && pwd )/runtime"
"$root"/src/tests/Common/scripts/bringup_runtest.sh \
--testRootDir="$root"/artifacts/tests/coreclr/linux.riscv64.Release \
--testNativeBinDir="$root"/artifacts/tests/coreclr/linux.riscv64.Release/bin \
--coreClrBinDir="$root"/artifacts/bin/coreclr/linux.riscv64.ReleaseI agree that the paths in help text are outdated. |
|
@gbalykov, the generated file from the latest main artifacts https://github.com/am11/CrossRepoCITesting/releases/tag/linux-riscv64_10541101133: it lists 76 tests to skip. Does it look correct (based on |
I've briefly looked through it and seems correct in overall. Though, it seems to have some extra unneeded lines, e.g. Both are part of
We've been running clr tests for a long time now on main in default/jitstress/gcstress modes on VisionFive2 and results were pretty much stable. Though, not all fails are added to src/tests/issues.targets, yet all of them should be skipped anyway for one reason or another. Also we run tests built with Please share more details when you are ready. cc @dotnet/samsung |
|
Running tests again. Here is some basic info: It's bianbu OS, debian derivate, so I used Ubuntu 24.10 repo to install lldb-18-dev.
other random info: $ ulimit -a
real-time non-blocking time (microseconds, -R) unlimited
core file size (blocks, -c) unlimited
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 61962
max locked memory (kbytes, -l) 2033068
max memory size (kbytes, -m) unlimited
open files (-n) 14096
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 16384
cpu time (seconds, -t) unlimited
max user processes (-u) 61962
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
$ sysctl vm.overcommit_memory
vm.overcommit_memory = 1
$ sysctl vm.swappiness
vm.swappiness = 60I get failing tests like this: but if I run it manually in the same terminal window, it passes: am11@k1:~/projects/runtime$ pushd artifacts/tests/coreclr/linux.riscv64.Release/GC/Features/KeepAlive/keepaliveother/keepalivedirectedgraph
~/projects/runtime/artifacts/tests/coreclr/linux.riscv64.Release/GC/Features/KeepAlive/keepaliveother/keepalivedirectedgraph ~/projects/runtime
am11@k1:~/projects/runtime/artifacts/tests/coreclr/linux.riscv64.Release/GC/Features/KeepAlive/keepaliveother/keepalivedirectedgraph$ ./keepalivedirectedgraph.sh -coreroot=/home/am11/projects/runtime/artifacts/tests/coreclr/linux.riscv64.Release/Tests/Core_Root
BEGIN EXECUTION
/home/am11/projects/runtime/artifacts/tests/coreclr/linux.riscv64.Release/Tests/Core_Root/corerun -p System.Reflection.Metadata.MetadataUpdater.IsSupported=false -p System.Runtime.Serialization.EnableUnsafeBinaryFormatterSerialization=true keepalivedirectedgraph.dll ''
Test should pass with ExitCode 100
Building Graph with 100 vertices...
Building Vertices...
Building Edges...
Making all vertices reachable...
Deleting all vertices...
Done...
Expected: 100
Actual: 100
END EXECUTION - PASSEDI have tried 5-6 similar sigsegv cases, and all of them pass when I run them manually. It's a testing machine so I am not running much extra stuff. Still it has that GNOME DE running with some services etc. I can switch to text-mode or console mode if that's what might be causing these.. There are other kind of failures as well, e.g. This also passes when I run stackoverflowtester.sh manually. I then passed am11@k1:~/projects/runtime/artifacts/tests/coreclr/linux.riscv64.Release/GC/Coverage/LargeObjectAlloc$ lldb-18 -- /home/am11/projects/runtime/artifacts/tests/coreclr/linux.riscv64.Release/Tests/Core_Root/corerun -p System.Reflection.Metadata.MetadataUpdater.IsSupported=false -p System.Runtime.Serialization.EnableUnsafeBinaryFormatterSerialization=true LargeObjectAlloc.dll '1'
(lldb) target create "/home/am11/projects/runtime/artifacts/tests/coreclr/linux.riscv64.Release/Tests/Core_Root/corerun"
Current executable set to '/home/am11/projects/runtime/artifacts/tests/coreclr/linux.riscv64.Release/Tests/Core_Root/corerun' (riscv64).
(lldb) settings set -- target.run-args "-p" "System.Reflection.Metadata.MetadataUpdater.IsSupported=false" "-p" "System.Runtime.Serialization.EnableUnsafeBinaryFormatterSerialization=true" "LargeObjectAlloc.dll" "1"
(lldb) r
Process 218168 launched: '/home/am11/projects/runtime/artifacts/tests/coreclr/linux.riscv64.Release/Tests/Core_Root/corerun' (riscv64)
LargeObjectAlloc started with 1 threads. Control-C to exit
All threads started
0: Restarting run 0
Process 218168 stopped
* thread #9, name = '0', stop reason = signal SIGSEGV: invalid address (fault address: 0x0)
frame #0: 0x0000003ff7c1b282 libc.so.6`__futex_abstimed_wait_common [inlined] __futex_abstimed_wait_common64(private=<unavailable>, cancel=<unavailable>, abstime=0x0000000000000000, op=<unavailable>, expected=<unavailable>, futex_word=0x0000002aaab40fe8) at futex-internal.c:57:12
(lldb) bt
* thread #9, name = '0', stop reason = signal SIGSEGV: invalid address (fault address: 0x0)
* frame #0: 0x0000003ff7c1b282 libc.so.6`__futex_abstimed_wait_common [inlined] __futex_abstimed_wait_common64(private=<unavailable>, cancel=<unavailable>, abstime=0x0000000000000000, op=<unavailable>, expected=<unavailable>, futex_word=0x0000002aaab40fe8) at futex-internal.c:57:12
frame #1: 0x0000003ff7c1b26a libc.so.6`__futex_abstimed_wait_common(futex_word=0x0000002aaab40fe8, expected=<unavailable>, clockid=<unavailable>, abstime=0x0000000000000000, private=<unavailable>, cancel=<unavailable>) at futex-internal.c:87:9
frame #2: 0x0000003ff7c1d072 libc.so.6`___pthread_cond_wait [inlined] __pthread_cond_wait_common(abstime=0x0000000000000000, clockid=0, mutex=0x0000002aaab40ff0, cond=0x0000002aaab40fc0) at pthread_cond_wait.c:503:10
frame #3: 0x0000003ff7c1d016 libc.so.6`___pthread_cond_wait(cond=0x0000002aaab40fc0, mutex=0x0000002aaab40ff0) at pthread_cond_wait.c:627:10
frame #4: 0x0000003ff7aadd62 libcoreclr.so`GCEvent::Impl::Wait(this=0x0000002aaab40fc0, milliseconds=<unavailable>, alertable=<unavailable>) at events.cpp:149:22 [opt]
frame #5: 0x0000003ff79531d6 libcoreclr.so`WKS::gc_heap::try_allocate_more_space(alloc_context*, unsigned long, unsigned int, int) [inlined] WKS::gc_heap::wait_for_gc_done(timeOut=-1) at gc.cpp:14729:49 [opt]
frame #6: 0x0000003ff79531ac libcoreclr.so`WKS::gc_heap::try_allocate_more_space(acontext=<unavailable>, size=<unavailable>, flags=<unavailable>, gen_number=<unavailable>) at gc.cpp:18939:9 [opt]
frame #7: 0x0000003ff79763f6 libcoreclr.so`WKS::GCHeap::Alloc(gc_alloc_context*, unsigned long, unsigned int) [inlined] WKS::gc_heap::allocate_more_space(acontext=0x0000003f0e22d180, size=6400056, flags=32, alloc_generation_number=3) at gc.cpp:19530:18 [opt]
frame #8: 0x0000003ff79763e8 libcoreclr.so`WKS::GCHeap::Alloc(gc_alloc_context*, unsigned long, unsigned int) [inlined] WKS::gc_heap::allocate_uoh_object(jsize=6400024, flags=32, gen_number=<unavailable>, alloc_bytes=0x0000003f0e22e9d0) at gc.cpp:45049:11 [opt]
frame #9: 0x0000003ff79763d4 libcoreclr.so`WKS::GCHeap::Alloc(this=<unavailable>, context=0x0000003f0e22e9b8, size=6400024, flags=32) at gc.cpp:49563:30 [opt]
frame #10: 0x0000003ff7850f36 libcoreclr.so`Alloc(size=6400024, flags=GC_ALLOC_LARGE_OBJECT_HEAP) at gchelpers.cpp:227:48 [opt]
frame #11: 0x0000003ff7850ce0 libcoreclr.so`AllocateSzArray(pArrayMT=0x0000003f798b8d38, cElements=1600000, flags=<unavailable>) at gchelpers.cpp:0 [opt]
frame #12: 0x0000003ff786422e libcoreclr.so`JIT_NewArr1(arrayMT=0x0000003f798b8d38, size=<unavailable>) at jithelpers.cpp:1571:16 [opt]
frame #13: 0x0000003f798dedb4
|
Also, I've heard that there're some issues with at least Banana Pi Bpi-f3 (e.g. https://forum.banana-pi.org/t/banana-pi-f3-with-16-gb-ram-constantly-freezing-solved/18678, https://www.reddit.com/r/RISCV/comments/1en1eb3/banana_pi_f3_with_16_gb_ram_constantly_freezing/), maybe your issue is smth like it since SpacemiT K1 and M1 are very similar as I understand. So bianbu os update might help. |
|
@jkoritzinsky, feel free to merge this. Our discussion is a bit off-topic. 😅 @gbalykov, I am not sure if that freezing issue is related since this system, with the whole DE, is running for weeks now. However, I will try running priority tests again once Bianbu 2.0 is out of RC series (https://bianbu-linux.spacemit.com/en/release_notes/bl-v2.0.y/). That one has kernel 6.6. They are also upstreaming their kernel patches these days https://google.com/search?q=spacemit+site:lore.kernel.org, which may take some time after which I'd be able to try it on other distros (3 M lines of patches in Bianbu v2, compared to mainline's 6.6, so I'm not going to try to apply it on 6.10 or 11 myself 🙈). |
See #97791 (comment).
TestExclusionList.txtis already written in directory pointed by$CORE_ROOT, lets use that in addition to existing mechanism (which I don't think are required but I haven't cleaned them up in case someone is using them).Tested on riscv64 machine that it does skip the tests pointed by the txt file.