Re: [Xen-devel] SIGSEGV linking GNU scientific library (GSL) with Xen

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Thu, 2010-12-23 at 00:55 +0000, Mahendra Kutare wrote:

> ==20934== Conditional jump or move depends on uninitialised value(s)
> ==20934==    at 0x39BB84899D: __printf_fp (in /lib64/libc-2.5.so)
> ==20934==    by 0x39BB844AD5: vfprintf (in /lib64/libc-2.5.so)
> ==20934==    by 0x39BB847F35: buffered_vfprintf
> (in /lib64/libc-2.5.so)
> ==20934==    by 0x39BB842A1B: vfprintf (in /lib64/libc-2.5.so)
> ==20934==    by 0x39BB84D357: fprintf (in /lib64/libc-2.5.so)
> ==20934==    by 0x401BA4: calc_load_vector_stats
> (xenloadbalance.c:227)
> ==20934==    by 0x401F54: main (xenloadbalance.c:307)
> ==20934==  Uninitialised value was created by a stack allocation
> ==20934==    at 0x402682: xenstat_get_node
> (in /var/lib/xen/images/mahendra/
> xen-3.4.3/tools/xenstat/xentop/xenloadbalance)

There is a good chance this is a false positive arising because valgrind
does not understand that the side effects of the hypercall ioctl is to
initialise some memory.

You can work around this by explicitly clearing the relevant data
structures (physinfo and domaininfo in this case) before use.

Or you might like to pull in my valgrind patch [0] which adds basic
understanding of the hypercall ioctl. However the coverage is incomplete
(basically sufficient to valgrind domain creation) so you may need to
extend it to cover other hypercalls which you observe when running your
application.

Once you have resolved/hidden these false positives hopefully the true
issue will be more obvious.

[0]
http://lists.xensource.com/archives/html/xen-devel/2010-08/msg01246.html

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel