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

[Mahendra Kutare <mahendra.kutare@xxxxxxxxx>]

Hi Ian,

Thanks for your email.

I am trying to isolate the issue looking at one-off-error and with the patch you mentioned.

One of the things I see is the default Xen build does optimization such as -O2 -fomit-frame-pointer -m64 -fno-strict-aliasing.

I would like to debug without those optimization and options. I tried changing my build file and overwrite -O2 optimization with -O0.
I also changed Config.mk to disable -O2 -fomit-frame-pointer -m64 -fno-strict-aliasing but during make of my code it still shows that its using them. 

Can you help me figure out how to disable this ? 

Example -
gcc -O2 -fomit-frame-pointer -m64 -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wno-unused-value -Wdeclaration-after-statement  -D__XEN_TOOLS__ -MMD -MF .xentop.d  -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE  -O0 -g -DGCC_PRINTF -Wall -Werror -I../../../tools/xenstat/libxenstat/src -DHOST_Linux -O0     -L../../../tools/xenstat/libxenstat/src  xentop.c  -lxenstat -lncurses  -lgsl -lgslcblas -lm -o xentop

Thanks for your help and I am working on debugging this and will update here.

Regards
Mahendra

On Thu, Dec 23, 2010 at 4:59 AM, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:

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