This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-bugs] [Bug 1258] New: xen 3.3 unstable: xend segfaults on amd64 whe

To: xen-bugs@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-bugs] [Bug 1258] New: xen 3.3 unstable: xend segfaults on amd64 when starting a hvm domain
From: bugzilla-daemon@xxxxxxxxxxxxxxxxxxx
Date: Wed, 21 May 2008 06:39:53 -0700
Delivery-date: Wed, 21 May 2008 06:40:08 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-bugs-request@lists.xensource.com?subject=help>
List-id: Xen Bugzilla <xen-bugs.lists.xensource.com>
List-post: <mailto:xen-bugs@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-bugs>, <mailto:xen-bugs-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-bugs>, <mailto:xen-bugs-request@lists.xensource.com?subject=unsubscribe>
Reply-to: bugs@xxxxxxxxxxxxxxxxxx
Sender: xen-bugs-bounces@xxxxxxxxxxxxxxxxxxx

           Summary: xen 3.3 unstable: xend segfaults on amd64 when starting
                    a hvm domain
           Product: Xen
           Version: unstable
          Platform: x86-64
        OS/Version: other
            Status: NEW
          Severity: critical
          Priority: P2
         Component: Tools
        AssignedTo: xen-bugs@xxxxxxxxxxxxxxxxxxx
        ReportedBy: jk@xxxxxxxx

I'm trying to start a 32-bit windows hvm domU on a 64-bit opensolaris dom0,
using xen 3.3 unstable bits from the
repository (+ some additional fixes for opensolaris).

changeset 17644: 29dc52031954
date: Thu May 15 09:38:00 2008 +0100 (6 days ago)
description: x86: Fix an S3 bug caused by x_firmware_waking_vector

Problem: when I try to start the windows domain, xend (that is, the python
interpreter) crashes with a segfault.  Like this:

# xm create winxp
Using config file "/etc/xen/winxp".
Xend has probably crashed!  Invalid or missing HTTP status code.

/var/adm/messages contains:

May 17 22:03:16 moritz genunix: [ID 603404 kern.notice] NOTICE: core_log:
[794] core dumped: /cores/python-794

Thread #48 got a SIGSEGV:

# pflags /cores/python-794
core '/cores/python-794' of 794:        python /usr/lib/xend start
        data model = _LP64  flags = ORPHAN|MSACCT|MSFORK
 /1:    flags = STOPPED  pollsys(0x7fffffdfef00,0x0,0x7fffffdfefc0,0x0)
        why = PR_SUSPENDED
 /2:    flags = DETACH|STOPPED  accept(0x4,0x7ffffe5be320,0x7ffffe5be42c,0x1)
        why = PR_SUSPENDED
 /3:    flags = DETACH|STOPPED  accept(0x10,0x7ffffe3bf320,0x7ffffe3bf42c,0x1)
        why = PR_SUSPENDED
 /4:    flags = DETACH|STOPPED  pollsys(0x7ffffe1c0730,0x0,0x7ffffe1c07f0,0x0)
        why = PR_SUSPENDED
 /5:    flags = DETACH|STOPPED  lwp_park(0x0,0x0,0x0)
        why = PR_SUSPENDED
 /6:    flags = STOPPED  read(0x14,0x412f20,0x10)
        why = PR_SUSPENDED
 /7:    flags = DETACH|STOPPED  accept(0x15,0x7ffffdbc3170,0x7ffffdbc327c,0x1)
        why = PR_SUSPENDED
 /8:    flags = DETACH|STOPPED  accept(0x17,0x7ffffd9c3a60,0x7ffffd9c3b6c,0x1)
        why = PR_SUSPENDED
 /48:   flags = DETACH
        sigmask = 0xffffbefc,0x0000ffff  cursig = SIGSEGV

And the stack backtrace for tread #48 looks like this

# pstack /cores/python-794
-----------------  lwp# 48 / thread# 48  --------------------
 00007ffffe9a5b2a cpuid () + 1a
 00007ffffe9f6783 pyxc_dom_set_policy_cpuid () + 33
 00007fffff2adacc PyCFunction_Call () + 17c
 00007fffff2e5ead call_function () + 41d
 00007fffff2e0dfe PyEval_EvalFrameReal () + c6e
 00007fffff2e0180 PyEval_EvalFrame () + 20
 00007fffff2e5fd0 fast_function () + b0

# mdb - /cores/python-794
Loading modules: [ libc.so.1 libuutil.so.1 ld.so.1 ]
> ::regs
%rax = 0x0000000080000018       %r8  = 0x0000000068747541
%rbx = 0x00000000fd56b860       %r9  = 0x0000000000000007
%rcx = 0x00000000444d4163       %r10 = 0x00007ffffd56b608
%rdx = 0x0000000069746e65       %r11 = 0x0000000000000000
%rsi = 0x00000000fd56b860       %r12 = 0x0000000000000007
%rdi = 0x00007ffffd56b858       %r13 = 0x0000000000000001
                                %r14 = 0x0000000000000008
                                %r15 = 0x00007ffffd56b858

%cs = 0x0053    %fs = 0x0000    %gs = 0x0000
%ds = 0x004b    %es = 0x004b    %ss = 0x004b

%rip = 0x00007ffffe9a5b2a libxenguest.so.3.2.0`cpuid+0x1a
%rbp = 0x00007ffffd56b8a0
%rsp = 0x00007ffffd56b848

%rflags = 0x00010213
  id=0 vip=0 vif=0 ac=0 vm=0 rf=1 nt=0 iopl=0x0

%gsbase = 0x0000000000000000
%fsbase = 0x00007ffffee44a00
%trapno = 0xe
   %err = 0x6
> <rip::dis
libxenguest.so.3.2.0`cpuid:     movl   0x4(%rdi),%eax
libxenguest.so.3.2.0`cpuid+3:   xorl   %ecx,%ecx
libxenguest.so.3.2.0`cpuid+5:   cmpl   $-0x1,%eax       <0xffffffff>
libxenguest.so.3.2.0`cpuid+8:   cmovl.ne %eax,%ecx
libxenguest.so.3.2.0`cpuid+0xb: movl   (%rdi),%eax
libxenguest.so.3.2.0`cpuid+0xd: movl   %ebx,-0x4(%rsp)
libxenguest.so.3.2.0`cpuid+0x13:movl   %ebx,%r8d
libxenguest.so.3.2.0`cpuid+0x16:movl   -0x4(%rsp),%ebx
libxenguest.so.3.2.0`cpuid+0x1a:movl   %eax,(%rsi)       <<<<<<<<<<<<<<<<< %rip
libxenguest.so.3.2.0`cpuid+0x1c:movl   %r8d,0x4(%rsi)
libxenguest.so.3.2.0`cpuid+0x20:movl   %ecx,0x8(%rsi)
libxenguest.so.3.2.0`cpuid+0x23:movl   %edx,0xc(%rsi)
0x7ffffe9a5b37:                 nop    
0x7ffffe9a5b3a:                 nop    
0x7ffffe9a5b3d:                 nop    
libxenguest.so.3.2.0`xc_cpuid_policy:   pushq  %rbp
libxenguest.so.3.2.0`xc_cpuid_policy+1: movq   %rsp,%rbp
libxenguest.so.3.2.0`xc_cpuid_policy+4: movq   %r12,-0x20(%rbp)
> 0x00000000fd56b860/X
mdb: failed to read data from target: no mapping for address
> 0x00007ffffd56b860/XXXX
0x7ffffd56b860: 1               68747541        444d4163        69746e65

Apparently the "regs" pointer passed to the function cpuid(), file
tools/libxc/xc_cpuid_x86.c (%rsi on amd64 / x86_64) is bogus, %rsi has
lost the top 32-bits.

This is because the caller of the cpuid() function has the 64-bit pointer in
%rbx, calls cpuid(), which saves/restores the lower 32-bit of %rbx, but
destroys the upper half.

On amd64 / x86_64, the cpuid() function in tools/libxc/xc_cpuid_x86.c
must save/restore full 64bit %rbx register.

Configure bugmail: 
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

Xen-bugs mailing list

<Prev in Thread] Current Thread [Next in Thread>