[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] qemu-system-sparc io-thread segfault on win32

From: Bob Breuer
Subject: [Qemu-devel] qemu-system-sparc io-thread segfault on win32
Date: Sun, 16 Oct 2011 23:39:28 -0500
User-agent: Thunderbird (Windows/20100228)

I'm getting a segfault from qemu-system-sparc with the io thread enabled
on win32.  This is with the latest mingw (gcc 4.6.1).  mipsel also
fails, but i386 is ok.  I haven't checked any of the other system
targets, but they might also show this problem.

git bisect points to commit cea5f9a cpu-exec.c: avoid AREG0 use, but
that would seem to only expose the bug instead of creating it.  In
cpu_exec(), assigning any valid pointer to ebp before setjmp will get it
working again.  It looks like a bogus value in ebp at the time of setjmp
will cause longjmp to abort on win32.

Here's some output from gdb for the crash:
  Starting program: d:\qemu\build-mingw\sparc-softmmu\qemu-system-sparc.exe
  -m 64 -L ./qemu-git/pc-bios
  [New Thread 2128.0x664]
  [New Thread 2128.0x5d4]
  [New Thread 2128.0x6dc]
  [Switching to Thread 2128.0x6dc]

  Breakpoint 1, 0x00514a30 in _setjmp ()
  (gdb) info registers
  eax            0x1989b7c        26778492
  ecx            0x1982008        26746888
  edx            0x0      0
  ebx            0x1982008        26746888
  esp            0x378fe00        0x378fe00
  ebp            0xfffffffe       0xfffffffe
  esi            0x0      0
  edi            0x1982008        26746888
  eip            0x514a30 0x514a30 <_setjmp>
  eflags         0x202    [ IF ]
  cs             0x1b     27
  ss             0x23     35
  ds             0x23     35
  es             0x23     35
  fs             0x38     56
  gs             0x0      0
  (gdb) c

  Program received signal SIGSEGV, Segmentation fault.
  0x7800bd65 in abnormal_termination () from C:\WINNT\system32\msvcrt.dll
  (gdb) bt
  #0  0x7800bd65 in abnormal_termination () from
  #1  0x0378ffa4 in ?? ()
  Backtrace stopped: previous frame inner to this frame (corrupt stack?)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]