Re: [Xen-devel] [xen-4.5-testing test] 103161: regressions - FAIL

[Ian Jackson <ian.jackson@xxxxxxxxxxxxx>]

Ian Jackson writes ("Re: [xen-4.5-testing test] 103161: regressions - FAIL"):
> As we discussed yesterday, while this may be a real bug, I think it is
> not really a _regression_ in the sense that the osstest baseline
> version has the same bug.
> 
> I therefore propose to do a force push of 4.4 too.

I dug the coredump and built binaries out of 103161 and

(gdb) bt
#0  0x00007fd84de5a20d in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007fd8519900d4 in address_space_rw ()
#2  0x00007fd8519901bd in cpu_physical_memory_rw ()
#3  0x00007fd851a6df4b in rw_phys_req_item ()
#4  0x00007fd851a6df81 in read_phys_req_item ()
#5  0x00007fd851a6e1dc in cpu_ioreq_move ()
#6  0x00007fd851a6e3b6 in handle_ioreq ()
#7  0x00007fd851a6e6d9 in cpu_handle_ioreq ()
#8  0x00007fd8518e13fc in qemu_iohandler_poll ()
#9  0x00007fd8518e238a in main_loop_wait ()
#10 0x00007fd851973aa1 in main_loop ()
#11 0x00007fd85197b049 in main ()
(gdb)

And the kernel said:

qemu-system-i38[3905]: segfault at 0 ip 00007fd84de5a20d sp
00007ffc38857878 error 4 in libc-2.19.so[7fd84ddc8000+1a1000]

The top ?? is probably because my gdb didn't find the corresponding
correct libc.so.  Looking at the source for address_space_rw I wonder
if it is trying to use one of the `memcpy' calls on the
`memory_access_is_direct' branches, which would be a serious mistake.

Sadly there is no debug information.  qemu seems to have crashed
without producing any output of any knd.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel