28.04.2013 00:13, Edward J. Shornock wrote: > * Michael Tokarev <m...@tls.msk.ru> [27-04-2013 10:45 EEST]: >> so it looks like the instruction stream being optimized is corrupt somehow. >> So the easier the reproducer is, the more chances we have to track it down. >> Finding corruptions isn't easy usually.
After looking a bit more about this, it might be a trivial bug, -- there are other possible comparison codes in qemu than listed in that function, so it looks like it is actually possible to have that error without corruption. > Unfortunately the failures are not consistent but they occur with java > related things. Oh. Java-related things. This is actually, well, sort of expected. Java is heavily multithreaded, and qemu in TCG mode is not able to run multi-threaded apps. Some of multi-threaded apps work, but this is just due to luck, not by design. There are some areas in the code which just don't assume MT mode at all, so while one thread is modifying some memory area, another may be reading it, or modifying it differently -- there are a few races which sometimes gets resolved by a good luck, and more often fail. > Sometimes the postinst for ca-certificates-java succeeds. Sometimes it fails > with <http://paste.debian.net/hidden/72893826/>. I see you're running something inside sbuild environment, but I've no idea how to do that. I'll try to learn how to set up sbuild, but that'll require some time, and wont be done in the near future. That's why I asked for steps to reproduce -- complete steps, including building the environment, -- just a tiny howto, of a sort. > It may be helpful to try to compile version 3.5.17 of the Java Service > Wrapper which can be downloaded from > <http://wrapper.tanukisoftware.com/download/3.5.17/wrapper_3.5.17_src.tar.gz> > > > I have not been able to compile this with qemu-arm-static in a Wheezy chroot > but I have been able to compile it within the Squeeze images from > <http://people.debian.org/~aurel32/qemu/armel/>. I'll try building a Wheezy > vm and/or updating the Squeeze vm to Wheezy. > > > Here are three compilation attempts. Each one fails with a different error. > > > > #1 [] > [mkdir] Created dir: /home/eshornock/src/wrapper_3.5.17_src/test [echo] Build > native components using 'make' and Makefile: Makefile-linux-armel-32.make > Segmentation fault This is most likely our java multithreaded issue. > #2, yielding the tcg fatal error [] > [echo] Build native components using 'make' and Makefile: > Makefile-linux-armel-32.make > /build/buildd-qemu_1.4.0+dfsg-2exp-amd64-r9ctKZ/qemu-1.4.0+dfsg/tcg/tcg.c:1439: > tcg fatal error This is the error you reported initially. It may be due to bug in code (not handling all conditionals), and may be due to the same multithreaded issue, when the opcode stream gets corrupt due to two or more threads racing for it. With the result being inconsistent, I think it is the latter. > #3 [] > qemu: Unsupported ARM syscall: 0x234628 qemu: Unsupported ARM syscall: > 0x234678 qemu: unhandled CPU exception 0x2 - aborting R00=ffffffda > R01=ce5b72dc R02=00000013 R03=00000000Segmentation fault And this again looks like the same MT race. There are some upstream changes past 1.4 (yes, that's 1.4 not 1.1 as will be in wheezy!) in an attempt to address this, but it's just the beginning, much more work needs to be done in this area. (1.4 is equally broken in this context). So, I'm afraid, that isn't easy and quick to fix... There was a long thread (in a bugreport) on launchpad about all this multithreading issue in qemu-user, but somehow I can't find it now. I'll try to link it to this bugreport. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
