From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50251) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eS0IM-0008TR-OG for qemu-devel@nongnu.org; Thu, 21 Dec 2017 07:49:55 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eS0II-00038d-KS for qemu-devel@nongnu.org; Thu, 21 Dec 2017 07:49:54 -0500 Received: from mx1.redhat.com ([209.132.183.28]:35554) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eS0II-000372-ET for qemu-devel@nongnu.org; Thu, 21 Dec 2017 07:49:50 -0500 References: <1513790098-9815-1-git-send-email-pbonzini@redhat.com> <51174e3a-12d3-f3e0-2d76-b776e0fe62b6@redhat.com> From: Thomas Huth Message-ID: Date: Thu, 21 Dec 2017 13:49:44 +0100 MIME-Version: 1.0 In-Reply-To: <51174e3a-12d3-f3e0-2d76-b776e0fe62b6@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] out of bounds in set_cc_op() (was: [PULL 00/46] First batch of misc patches for QEMU 2.12) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini , Laurent Vivier , Richard Henderson Cc: Peter Maydell , QEMU Developers On 20.12.2017 22:56, Paolo Bonzini wrote: > On 20/12/2017 20:20, Peter Maydell wrote: >> On the x86/sanitizer build, new runtime errors: >> GTESTER check-qtest-m68k >> /home/petmay01/linaro/qemu-for-merges/target/m68k/translate.c:230:12: >> runtime error: index -1 out of bounds for type 'const uint8_t [11]' >> >> ...and similar fails on one or two boards on most of the other >> guest architectures. >=20 > These are preexisting bugs, now exposed by the boot-serial-test. > Thomas, can you identify the architectures that have a problem and > notify the maintainers? In the meanwhile I'll keep the boot-serial-tes= t > enhancements queued locally, and remove them from the pull request. Laurent, Richard, looks like old_op is -1 when set_cc_op() is called here for the first time. The problem can be reproduced by running the mini-kernel directly. Just get http://people.redhat.com/~thuth/m68k-uart.bin and run QEMU like this: qemu-system-m68k -nographic -kernel ~/tmp/m68k-uart.bin -serial none That kernel only contains these few instructions: 0x41, 0xf9, 0xfc, 0x06, 0x00, 0x00, /* lea 0xfc060000,%a0 */ 0x10, 0x3c, 0x00, 0x54, /* move.b #'T',%d0 */ 0x11, 0x7c, 0x00, 0x04, 0x00, 0x08, /* move.b #4,8(%a0) */ 0x11, 0x40, 0x00, 0x0c, /* move.b %d0,12(%a0) */ 0x60, 0xfa /* bra.s loop */ The problem occurs during the second instruction (i.e. the first move.b). Do you have any ideas where this -1 in s->cc_op could come from? Thomas