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

Re: [Xen-devel] xenstored crashes with SIGSEGV

2014-12-16 16:44 GMT+00:00 Frediano Ziglio <freddy77@xxxxxxxxx>:
> 2014-12-16 16:23 GMT+00:00 Ian Campbell <Ian.Campbell@xxxxxxxxxx>:
>> On Tue, 2014-12-16 at 16:13 +0000, Frediano Ziglio wrote:
>>> What does "info all-registers" gdb command say about SSE registers?
>> All zeroes. No ffs anywhere.
> Could be that core does not dump these registers for some reasons? On
> my machine I got some FFs even just before the main is reached.
>>> Do we have a bug in Xen that affect SSE instructions (possibly already
>>> fixed after Philipp version) ?
>> Possibly. When this was thought to be xenstored (which doesn't change
>> all that much) debugging 4.1 seemed plausible, but since it could be
>> anywhere else I think we either need a plausible reproduction, or a
>> repro on a newer hypervisor (or possibly kernel) I'm afraid.
>> Ian.
> I found these
> 1) https://www.kernel.org/pub/linux/kernel/v3.0/ChangeLog-3.2.8
> 2) https://sourceware.org/bugzilla/show_bug.cgi?id=16064
> 1 seems to indicate a problem with kernel 3.2. Second with glibc 2.18.
> First we (I'll try when I reach home) can check if memset in glibc (or
> the version called from talloc_zero) can use SSE. A possible dmesg
> output and /proc/cpuinfo content could help too but I think SSE are
> now quite common.

I have access to some core dumps. glibc memset is using SSE,
specifically xmm0 register.

Unfortunately is seems that core dumps contains only standard
registers, so all register appears zeroed. If you try with a newer gdb
version is shows that registers are not available.

> For the reproduction could be that a program doing some memset(0)
> continuously while another fill SSE register with garbage could
> help... at least if they execute on the same CPU (so could be limiting
> Xen to one CPU). Also doing some FPU operation which could lead to
> exception could help too.


Xen-devel mailing list



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