|
From: | Alex Bennée |
Subject: | Re: [RFC PATCH] tests/tcg: add a multiarch signals test to stress test signal delivery |
Date: | Wed, 21 Apr 2021 17:21:32 +0100 |
User-agent: | mu4e 1.5.11; emacs 28.0.50 |
Alex Bennée <alex.bennee@linaro.org> writes: > This adds a simple signal test that combines the POSIX timer_create > with signal delivery across multiple threads. > > [AJB: So I wrote this in an attempt to flush out issues with the > s390x-linux-user handling. However I suspect I've done something wrong > or opened a can of signal handling worms. > > Nominally this runs fine on real hardware but I variously get failures > when running it under translation and while debugging QEMU running the > test. I've also exposed a shortcomming with the gdb stub when dealing > with guest TLS data so yay ;-). So I post this as an RFC in case > anyone else can offer insight or can verify they are seeing the same > strange behaviour?] To further document my confusion: gdb --args $QEMU ./tests/tcg/$ARCH/signals will SEGV in generated code for every target I've run. This seems to be some sort of change of behaviour by running inside a debug environment. Architectures that fail running normally: ./qemu-alpha tests/tcg/alpha-linux-user/signals fish: “./qemu-alpha tests/tcg/alpha-li…” terminated by signal SIGILL (Illegal instruction) ./qemu-sparc64 tests/tcg/sparc64-linux-user/signals thread0: started thread1: started thread2: started thread3: started thread4: started thread5: started thread6: started thread7: started thread8: started thread9: started thread0: saw 0 alarms from 0 ... (and hangs) ./qemu-s390x ./tests/tcg/s390x-linux-user/signals fish: “./qemu-s390x ./tests/tcg/s390x-…” terminated by signal SIGSEGV (Address boundary error) ./qemu-sh4 ./tests/tcg/sh4-linux-user/signals thread0: saw 87 alarms from 238 thread1: started thread1: saw 0 alarms from 331 thread2: started thread2: saw 0 alarms from 17088 thread3: started thread3: saw 0 alarms from 17093 thread4: started thread4: saw 0 alarms from 17098 thread5: started thread5: saw 2 alarms from 17106 thread6: started thread6: saw 0 alarms from 17108 thread7: started thread7: saw 1 alarms from 17114 thread8: started thread8: saw 0 alarms from 17118 thread9: started thread9: saw 0 alarms from 17122 qemu: uncaught target signal 11 (Segmentation fault) - core dumped fish: “./qemu-sh4 ./tests/tcg/sh4-linu…” terminated by signal SIGSEGV (Address boundary error) And another completely random data point while most arches see most signals delivered to the main thread qemu-i386 actually sees quite a few delivered to the other threads which is weird because I though the signal delivery would be more of a host feature than anything else. ./qemu-i386 ./tests/tcg/i386-linux-user/signals thread0: started thread0: saw 134 alarms from 177 thread1: started thread1: saw 0 alarms from 254 thread2: started thread2: saw 1 alarms from 300 thread3: started thread3: saw 1 alarms from 305 thread4: started thread5: started thread6: started thread7: started thread8: started thread9: started thread4: saw 80 alarms from 423 thread5: saw 7 alarms from 525 thread6: saw 4 alarms from 631 thread7: saw 6 alarms from 758 thread8: saw 4 alarms from 822 thread9: saw 635 alarms from 978 -- Alex Bennée
[Prev in Thread] | Current Thread | [Next in Thread] |