ARAnyM VMs with Debian hanging at 100% CPU usage

[Thorsten Glaser <tg@mirbsd.de>]

Hi everyone,

I *really* need a stand-alone testcase for the GCC __sync_* builtins
or specifically, the cmpxchg syscall. A threded one.

I’ve got ARAnyM VMs hanging at 100% CPU, no network response any more,
during builds of first qt4-x11, and now cwidget. (Although I don’t know
if the former uses those GCC primitives, if available, in their generic
atomics code, or the latter uses atomics at all, this is a first guess.)

Since the VMs hang so that I must kill them, no debugging is possible.

The last lines of the cwidget build log (although eatmydata and the
ext4 journal replay might have cut off more) were:

if g++ -DHAVE_CONFIG_H -I. -I. -I.. -I.. -Wall -Werror -I.. -I../src    -D_FORTIFY_SOURCE=2  -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_REENTRANT -I/usr/include/sigc++-2.0 -I/usr/lib/m68k-linux-gnu/sigc++-2.0/include   -MT test_threads.o -MD -MP -MF ".deps/test_threads.Tpo" -c -o test_threads.o test_threads.cc; \
        then mv -f ".deps/test_threads.Tpo" ".deps/test_threads.Po"; else rm -f ".deps/test_threads.Tpo"; exit 1; fi
/bin/bash ../libtool --tag=CXX --mode=link g++  -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_REENTRANT -I/usr/include/sigc++-2.0 -I/usr/lib/m68k-linux-gnu/sigc++-2.0/include    -Wl,-z,relro -o test  main.o test_eassert.o test_ssprintf.o test_threads.o ../src/cwidget/libcwidget.la -lcppunit   -lncursesw  -lpthread -lsigc-2.0
libtool: link: g++ -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_REENTRANT -I/usr/include/sigc++-2.0 -I/usr/lib/m68k-linux-gnu/sigc++-2.0/include -Wl,-z -Wl,relro -o .libs/test main.o test_eassert.o test_ssprintf.o test_threads.o  ../src/cwidget/.libs/libcwidget.so /usr/lib/libcppunit.so -lncursesw -lpthread /usr/lib/m68k-linux-gnu/libsigc-2.0.so
make[3]: Leaving directory `/tmp/buildd/cwidget-0.5.16/tests'
/usr/bin/make  check-TESTS
make[3]: Entering directory `/tmp/buildd/cwidget-0.5.16/tests'

Furthermore, as already mentioned, when I tried to test whether my
backport of the GCC atomics worked, I made a small test programme
to see whether it linked, but it *also* froze the VM (and I’m of the
opinion that it at most should have made the process inside eat up
almost-all CPU and be still killable/accessible). Parallel programming
is not mine, so I don’t know whether I did anything wrong (it wasn’t
really meant to be executed but to freeze the entire OS *and* virtual
hardware isn’t what I’d expect even in an endless loop).

Host: Kubuntu 8.04 (hardy) i386, Linux 2.6.24-32-server (2.6.24-32.104),
	mpfr4 3.1.0-5~wtf804+1, aranym 0.9.13-3.1~wtf804+2

Guest: Debian sid m68k, Linux 3.2.0-3-atari (3.2.21-3)

Right now I suspect a bug on any layer, including the emulation.
It may or may not happen on my “other” host system:
	Debian sid amd64 Xen domU, Linux 2.6.32-5-xen-amd64 (2.6.32-41),
	mpfr4 3.1.0-5, aranym 0.9.13-3.1

If really needed, I can check that (and crash that VM, too) once the
guest I have on it is done compiling 3.2.23-1, i.e. in about 4-5 days.

Thanks in advance,
//mirabilos
-- 
<Natureshadow> Dann mach ich git annex copy --to shore und fertig ist das
<Natureshadow> das ist ja viel cooler als ownCloud ...
<mirabilos> sag ich doch
<Natureshadow> ja wieso stimmt das denn immer was du sagst ...