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

R: R: Crash when using xencov


  • To: Julien Grall <julien@xxxxxxx>
  • From: Carmine Cesarano <c.cesarano@xxxxxxxxxx>
  • Date: Mon, 27 Jun 2022 13:48:51 +0000
  • Accept-language: it-IT, en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=V3Pi4Az0n2TlXGuj66kDlFkJUYPs5Se0T8d8rwsr+w4=; b=ajfxl0GS3YbWF4NVf9kD3gYl0/dIQ5vn8QuISX9lgudBLlDQhTqNarIecX2KzOW8x4aFHVx0IIEKwzRYwka0Aq32xgpHmziqd9NvSZk3ya3jpvH6wyA6m2olzFPqg97q53AaYNXkBK7JPUgroUioc3ciu+WtDnh9rCTK97AFolNP50Qu47lGaQSbN/jwlNsq5oJWKxTU4TTG5dz0zyjN4XEtnJEyl8QJMorMzElJzBBbHZBjSjZ9tSlIt9wHtCbE75z066yPIKxs6O8LVzQwWDtZYZA4aVUS/HoZisEqT3oioR2lZLpXjLAxoSQDp/6Ez6eCVLD63Eu4Yw6fwosS1A==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aKxXy+paipubk5+YRRWNZYaqJYzy3GGf6Dg7nRXaR+Z3tNio5D7fkjxdVyBlwjVbtDKwfpAOfvSu0bYeykA/7b+EapMuORhAApNnL6JJkh1jsB+wVB/WIDaPQoph9DchDsOrTCt458fWGn+GyekEBXB7wwDtVTX+w9CW6TzgPs8BRphvc57ThZU6DzlfX3ij2sVJecJ462Csd06F399KH2QqAtE1aHWFG2a8+I7x3PtZj8V/IFt46+35nOybil6pHZC6/ASXH+sPFVMfDECKIHygy+qGAHPZHCPnT88Kp3t8hdlh1homIQ+jOSoVYydR919dvgiJ4VEaEqlBTNOQ3A==
  • Cc: "xen-users@xxxxxxxxxxxxxxxxxxxx" <xen-users@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Mon, 27 Jun 2022 13:49:45 +0000
  • List-id: Xen user discussion <xen-users.lists.xenproject.org>
  • Thread-index: AQHYihZvzMoBU/8d5kCvfMcwSUXjJK1jJQIAgAALHhCAAAKEgIAAD46v
  • Thread-topic: R: Crash when using xencov

Hi,

i can’t use addr2line (addr2line: ‘xen-syms: No such file’) but invoking SYSCTL_coverage_op hypercall in a user program I get the following result:

 

 

(gdb) break 22

Breakpoint 1 at 0x1219: file xen_ver.c, line 22.

(gdb) run

Starting program: /home/test/coverage/xen_ver

[Thread debugging using libthread_db enabled]

Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

 

Breakpoint 1, cov_sysctl (op=2, sysctl=0x7fffffffe4f0, buf=0x0, buf_size=0) at xen_ver.c:22

22          set_xen_guest_handle(sysctl->u.coverage_op.buffer, buf);

(gdb) s

24          return xc_sysctl(xch, sysctl);

(gdb) s

0x00007ffff7f9db30 in xc_sysctl () from /lib/libxenctrl.so.4.16

(gdb) s

Single stepping until exit from function xc_sysctl,

which has no line number information.

 

Da: Julien Grall
Inviato: lunedì 27 giugno 2022 14:42
A: Carmine Cesarano
Oggetto: Re: R: Crash when using xencov

 

Hello,

You seemed to have removed xen-users from the CC list. Please keep it in
CC unless the discussion needs to private.

Also, please avoid top-posting.

On 27/06/2022 13:36, Carmine Cesarano wrote:
> Yes, i mean stable-4.16. Below the logs after running "xencov reset". The situation for "xencov read" is similar.
>
> (XEN) ----[ Xen-4.16.2-pre  x86_64  debug=y gcov=y  Not tainted ]----
> (XEN) CPU:    0
> (XEN) RIP:    e008:[<ffff82d040257bd2>] gcov_info_reset+0x87/0xa9
> (XEN) RFLAGS: 0000000000010202   CONTEXT: hypervisor (d0v0)
> (XEN) rax: 0000000000000000   rbx: ffff82d04056bdc0   rcx: 00000000000c000b
> (XEN) rdx: 0000000000000000   rsi: 0000000000000001   rdi: ffff82d04056bdc0
> (XEN) rbp: ffff83023a7e7cb0   rsp: ffff83023a7e7c88   r8:  7fffffffffffffff
> (XEN) r9:  deadbeefdeadf00d   r10: 0000000000000000   r11: 0000000000000000
> (XEN) r12: 0000000000000001   r13: ffff82d04056be28   r14: 0000000000000000
> (XEN) r15: ffff82d04056bdc0   cr0: 0000000080050033   cr4: 0000000000172620
> (XEN) cr3: 000000017ea0b000   cr2: 0000000000000000
> (XEN) fsb: 00007fc0fb0ca200   gsb: ffff88807b400000   gss: 0000000000000000
> (XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: e010   cs: e008
> (XEN) Xen code around <ffff82d040257bd2> (gcov_info_reset+0x87/0xa9):
> (XEN)  1d 44 89 f0 49 8b 57 70 <4c> 8b 24 c2 49 83 c4 18 48 83 05 a6 81 4c 00 01
> (XEN) Xen stack trace from rsp=ffff83023a7e7c88:
> (XEN)    ffff82d04056bdc0 0000000000000001 ffff82d04070f180 0000000000000001
> (XEN)    0000000000000000 ffff83023a7e7cc8 ffff82d040257a6a ffff83023a7e7db0
> (XEN)    ffff83023a7e7ce8 ffff82d040257547 ffff83023a7e7fff ffff83023a7e7fff
> (XEN)    ffff83023a7e7e58 ffff82d040255d5f ffff83023a7e7d68 ffff82d0403b5e8b
> (XEN)    000000000017d5b2 0000000000000000 ffff83023a6b5000 0000000000000000
> (XEN)    00007fc0fb348010 800000017ea0e127 0000000000000202 ffff82d040399fd8
> (XEN)    0000000000005a40 ffff83023a7e7d68 0000000000000206 ffff82e002fab640
> (XEN)    ffff83023a7e7e58 ffff82d0403bb29d ffff83023a69f000 000000003a7e7fff
> (XEN)    000000017ea0f067 0000000000000000 000000000017d5b2 000000000017d5b2
> (XEN)    0000001400000014 0000000000000002 ffffffffffffffff 0000000000000000
> (XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
> (XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
> (XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
> (XEN)    0000000000000000 ffff83023a7e7ef8 0000000000000001 ffff83023a69f000
> (XEN)    deadbeefdeadf00d ffff82d04025579d ffff83023a7e7ee8 ffff82d040387f62
> (XEN)    00007fc0fb348010 deadbeefdeadf00d deadbeefdeadf00d deadbeefdeadf00d
> (XEN)    deadbeefdeadf00d ffff83023a7e7fff ffff82d0403b2c99 ffff83023a7e7eb8
> (XEN)    ffff82d04038214c ffff83023a69f000 ffff83023a7e7ed8 ffff83023a69f000
> (XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
> (XEN)    00007cfdc58180e7 ffff82d0404392ae 0000000000000000 ffff88800f484c00
> (XEN) Xen call trace:
> (XEN)    [<ffff82d040257bd2>] R gcov_info_reset+0x87/0xa9

Thanks! There are multiple versions of gcov_info_reset() in the tree.
The one used will depend on the compiler you are using.

Can you use addr2line (or gdb) to find out the file and line of code
associated with the crash?

For addr2line you could do:

   addr2line -e xen-syms 0xffff82d040257bd2

Cheers,

--
Julien Grall

 


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.