qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Andreas Färber" <afaerber@suse.de>
To: Blue Swirl <blauwirbel@gmail.com>
Cc: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>,
	Alexander Graf <agraf@suse.de>,
	qemu-devel <qemu-devel@nongnu.org>
Subject: [Qemu-devel] sparc-softmmu uninitialized memory read?
Date: Sat, 05 May 2012 17:37:53 +0200	[thread overview]
Message-ID: <4FA54951.90908@suse.de> (raw)

Hello Blue,

Testing a potential AREG0 fix for ppc host by malc I got an error
running `./sparc-softmmu/sparc-softmmu` (same with CD/kernel):

qemu: fatal: Trap 0x07 while interrupts disabled, Error state
pc: 00005e0c  npc: 00005e10
General Registers:
%g0-7: 00000000 00000001 babababa 00000000 00000020 07ffff08 07ffe000
babababa

Current Register Window:
%o0-7: 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000
%l0-7: 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000
%i0-7: 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000

Floating Point Registers:
%f00: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
%f08: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
%f16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
%f24: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
psr: 048000c0 (icc: N--- SPE: SP-) wim: 00000001
fsr: 00000000 y: 00000020
Abgebrochen

The 0xbabababa in %g2 and %g7 is a signature I've seen in uninitialized
memory on openSUSE 12.1 Betas. So I ran valgrind, and the following
caught my eye on both ppc and x86_64:

==18801== Command: ./sparc-softmmu/qemu-system-sparc
==18801==
==18801== Thread 2:
==18801== Conditional jump or move depends on uninitialised value(s)
==18801==    at 0x25C5AF: compute_all_logic (cc_helper.c:37)
==18801==    by 0x25C648: helper_compute_psr (cc_helper.c:470)
==18801==    by 0x8CD0981: ???
==18801==  Uninitialised value was created by a heap allocation
==18801==    at 0x4C27CE8: memalign (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==18801==    by 0x4C27D97: posix_memalign (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==18801==    by 0x1F2101: qemu_memalign (oslib-posix.c:93)
==18801==    by 0x1F21A9: qemu_vmalloc (oslib-posix.c:126)
==18801==    by 0x2665F6: qemu_ram_alloc_from_ptr (exec.c:2647)
==18801==    by 0x286D76: memory_region_init_ram (memory.c:954)
==18801==    by 0x297FFD: ram_init1 (sun4m.c:757)
==18801==    by 0x204DAE: qdev_init (qdev.c:151)
==18801==    by 0x204EEC: qdev_init_nofail (qdev.c:258)
==18801==    by 0x298845: ram_init.constprop.7 (sun4m.c:783)
==18801==    by 0x298980: sun4m_hw_init (sun4m.c:862)
==18801==    by 0x2994A2: ss5_init (sun4m.c:1289)

This is at 8f473dd104f0937ce98523fa6f9de0bd845aebbe, and cc_helper.c:37
is int32_t dst argument of get_NZ_icc(), which is always called with
CC_DST, i.e. env->cc_dst.

This seems to indicate that a read from uninitialized memory occurred,
from which cc_dst is being initialized?

Any idea where that could originate from or how to further debug?
It doesn't seem to be caused by the
7d21dcc84b8c07918124a9c0708694d2fb013f65 OpenBIOS r1056 update.

Regards,

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

             reply	other threads:[~2012-05-05 15:37 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-05 15:37 Andreas Färber [this message]
2012-05-06 11:32 ` [Qemu-devel] sparc-softmmu uninitialized memory read? Blue Swirl
2012-05-06 14:02   ` Andreas Färber
2012-05-06 16:44     ` Blue Swirl
2012-05-06 19:22       ` Andreas Färber
2012-05-06 19:27         ` malc
2012-05-07  0:02           ` Andreas Färber

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4FA54951.90908@suse.de \
    --to=afaerber@suse.de \
    --cc=agraf@suse.de \
    --cc=blauwirbel@gmail.com \
    --cc=mark.cave-ayland@ilande.co.uk \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).