Nabble - Valgrind - Users

Re: Unable to install valkyrie-1.4.0 on Ubuntu

2009-12-07T02:37:52Z

Hi Suresh,

Valkyrie currently only supports Qt3. I'm working on the port to Qt4,
but it's taking a while. Realistically, I don't expect to be ready
before feb. In the meantime, i'd advise a local install of qt3 (v3.3.6
was a good one) - it's fairly simple.

Regards,
Cerion

Suresh Venkata wrote:

> Hi,
>
> Configure command of valkyrie fails with Qt related error.It seems
> configure command unable to detect the Qt sdk installed on my machine.
>
> Qt 4.5.3 sdk installed in /opt/qtsdk-2009.04/qt and
> valgrind-3.4.1-Debian installed on the Ubuntu machine.Is it required
> to define Qt environment variables so that valkyrie identifies the
> installed Qt.?
>
> configure.log is attached.
>
> -Suresh.
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Join us December 9, 2009 for the Red Hat Virtual Experience,
> a free event focused on virtualization and cloud computing.
> Attend in-depth sessions from your desk. Your couch. Anywhere.
> http://p.sf.net/sfu/redhat-sfdev2dev
> ------------------------------------------------------------------------
>
> _______________________________________________
> Valgrind-users mailing list
> Valgrind-users@...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Valgrind-users mailing list
Valgrind-users@...
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: Unable to install valkyrie-1.4.0 on Ubuntu

2009-12-07T01:48:45Z

afair, Valkyrie is a Qt 3 application.
It isn't ported to Qt 4.

On Sun, Dec 6, 2009 at 1:54 AM, Suresh Venkata
<suresh.venkata123@...> wrote:
> Qt 4.5.3 sdk installed in /opt/qtsdk-2009.04/qt and valgrind-3.4.1-Debian
> installed on the Ubuntu machine.Is it required to define Qt environment
> variables so that valkyrie identifies the installed Qt.?

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Valgrind-users mailing list
Valgrind-users@...
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Looking up and calling functions in the target executable from an interception?

2009-12-06T09:45:01Z

Hi,
I'm starting to look at https://bugs.kde.org/show_bug.cgi?id=217615
(new/new[]/malloc mismatch detection when valgrinding win32 apps with wine).

Rather than replace the whole heap, I'd like to stick
with the wine system heap (which already is pretty
valgrind-friendly, and getting more so), and just override msvcrt's
implementations of new, new[], malloc, etc. with thin
shims that allocate a slightly larger block using
the win32 system heap (the one in kernel32,
which is below the one in msvcrt) and saves the
type of allocation in the extra space.

I have successfully intercepted msvcrt's malloc
in valgrind, but then I don't know how to look up
and call target functions inside the interceptor.
The functions I want to call ought to be easy to
look up from the loaded debug info, but I'm not
familiar enough with valgrind's symbol table stuff
to be able to do that straight off.

If anyone can supply a hint, that'd be welcome. In
the meantime I'll try to lurch along by linking replacement
functions into the target app instead of doing a shiny
interceptor in valgrind.
- Dan

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Valgrind-users mailing list
Valgrind-users@...
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Unable to install valkyrie-1.4.0 on Ubuntu

2009-12-05T16:54:55Z

Hi,

Configure command of valkyrie fails with Qt related error.It seems configure command unable to detect the Qt sdk installed on my machine.

Qt 4.5.3 sdk installed in /opt/qtsdk-2009.04/qt and valgrind-3.4.1-Debian installed on the Ubuntu machine.Is it required to define Qt environment variables so that valkyrie identifies the installed Qt.?

configure.log is attached.

-Suresh.

[config.log]

This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. It was created by Valkyrie configure 1.4.0, which was generated by GNU Autoconf 2.61. Invocation command line was $ ./configure ## --------- ## ## Platform. ## ## --------- ## hostname = jackalope uname -m = i686 uname -r = 2.6.28-16-generic uname -s = Linux uname -v = #55-Ubuntu SMP Tue Oct 20 19:48:24 UTC 2009 /usr/bin/uname -p = unknown /bin/uname -X = unknown /bin/arch = unknown /usr/bin/arch -k = unknown /usr/convex/getsysinfo = unknown /usr/bin/hostinfo = unknown /bin/machine = unknown /usr/bin/oslevel = unknown /bin/universe = unknown PATH: /usr/local/sbin PATH: /usr/local/bin PATH: /usr/sbin PATH: /usr/bin PATH: /sbin PATH: /bin PATH: /usr/games ## ----------- ## ## Core tests. ## ## ----------- ## configure:1827: checking for a BSD-compatible install configure:1883: result: /usr/bin/install -c configure:1894: checking whether build environment is sane configure:1937: result: yes configure:1965: checking for a thread-safe mkdir -p configure:2004: result: /bin/mkdir -p configure:2017: checking for gawk configure:2047: result: no configure:2017: checking for mawk configure:2033: found /usr/bin/mawk configure:2044: result: mawk configure:2055: checking whether make sets $(MAKE) configure:2076: result: yes configure:2284: checking for style of include used by make configure:2312: result: GNU configure:2392: checking for g++ configure:2408: found /usr/bin/g++ configure:2419: result: g++ configure:2450: checking for C++ compiler version configure:2457: g++ --version >&5 g++ (Ubuntu 4.3.3-5ubuntu4) 4.3.3 Copyright (C) 2008 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. configure:2460: $? = 0 configure:2467: g++ -v >&5 Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.3.3-5ubuntu4' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-targets=all --with-tune=generic --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu Thread model: posix gcc version 4.3.3 (Ubuntu 4.3.3-5ubuntu4) configure:2470: $? = 0 configure:2477: g++ -V >&5 g++: '-V' option must have argument configure:2480: $? = 1 configure:2503: checking for C++ compiler default output file name configure:2530: g++ conftest.cpp >&5 configure:2533: $? = 0 configure:2571: result: a.out configure:2588: checking whether the C++ compiler works configure:2598: ./a.out configure:2601: $? = 0 configure:2618: result: yes configure:2625: checking whether we are cross compiling configure:2627: result: no configure:2630: checking for suffix of executables configure:2637: g++ -o conftest conftest.cpp >&5 configure:2640: $? = 0 configure:2664: result: configure:2670: checking for suffix of object files configure:2696: g++ -c conftest.cpp >&5 configure:2699: $? = 0 configure:2722: result: o configure:2726: checking whether we are using the GNU C++ compiler configure:2755: g++ -c conftest.cpp >&5 configure:2761: $? = 0 configure:2778: result: yes configure:2783: checking whether g++ accepts -g configure:2813: g++ -c -g conftest.cpp >&5 configure:2819: $? = 0 configure:2918: result: yes configure:2943: checking dependency style of g++ configure:3034: result: gcc3 configure:3097: checking for gcc configure:3113: found /usr/bin/gcc configure:3124: result: gcc configure:3362: checking for C compiler version configure:3369: gcc --version >&5 gcc (Ubuntu 4.3.3-5ubuntu4) 4.3.3 Copyright (C) 2008 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. configure:3372: $? = 0 configure:3379: gcc -v >&5 Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.3.3-5ubuntu4' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-targets=all --with-tune=generic --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu Thread model: posix gcc version 4.3.3 (Ubuntu 4.3.3-5ubuntu4) configure:3382: $? = 0 configure:3389: gcc -V >&5 gcc: '-V' option must have argument configure:3392: $? = 1 configure:3395: checking whether we are using the GNU C compiler configure:3424: gcc -c conftest.c >&5 configure:3430: $? = 0 configure:3447: result: yes configure:3452: checking whether gcc accepts -g configure:3482: gcc -c -g conftest.c >&5 configure:3488: $? = 0 configure:3587: result: yes configure:3604: checking for gcc option to accept ISO C89 configure:3678: gcc -c -g -O2 conftest.c >&5 configure:3684: $? = 0 configure:3707: result: none needed configure:3727: checking dependency style of gcc configure:3818: result: gcc3 configure:3839: checking how to run the C preprocessor configure:3879: gcc -E conftest.c configure:3885: $? = 0 configure:3916: gcc -E conftest.c conftest.c:10:28: error: ac_nonexistent.h: No such file or directory configure:3922: $? = 1 configure: failed program was: | /* confdefs.h. */ | #define PACKAGE_NAME "Valkyrie" | #define PACKAGE_TARNAME "valkyrie" | #define PACKAGE_VERSION "1.4.0" | #define PACKAGE_STRING "Valkyrie 1.4.0" | #define PACKAGE_BUGREPORT "info@..." | #define PACKAGE "valkyrie" | #define VERSION "1.4.0" | /* end confdefs.h. */ | #include <ac_nonexistent.h> configure:3955: result: gcc -E configure:3984: gcc -E conftest.c configure:3990: $? = 0 configure:4021: gcc -E conftest.c conftest.c:10:28: error: ac_nonexistent.h: No such file or directory configure:4027: $? = 1 configure: failed program was: | /* confdefs.h. */ | #define PACKAGE_NAME "Valkyrie" | #define PACKAGE_TARNAME "valkyrie" | #define PACKAGE_VERSION "1.4.0" | #define PACKAGE_STRING "Valkyrie 1.4.0" | #define PACKAGE_BUGREPORT "info@..." | #define PACKAGE "valkyrie" | #define VERSION "1.4.0" | /* end confdefs.h. */ | #include <ac_nonexistent.h> configure:4065: checking for X configure:4180: gcc -E conftest.c configure:4186: $? = 0 configure:4235: gcc -o conftest -g -O2 conftest.c -lX11 >&5 configure:4241: $? = 0 configure:4300: result: libraries , headers configure:4461: gcc -o conftest -g -O2 conftest.c -lX11 >&5 configure:4467: $? = 0 configure:4624: checking for gethostbyname configure:4680: gcc -o conftest -g -O2 conftest.c >&5 configure:4686: $? = 0 configure:4703: result: yes configure:4848: checking for connect configure:4904: gcc -o conftest -g -O2 conftest.c >&5 configure:4910: $? = 0 configure:4927: result: yes configure:4999: checking for remove configure:5055: gcc -o conftest -g -O2 conftest.c >&5 configure:5061: $? = 0 configure:5078: result: yes configure:5150: checking for shmat configure:5206: gcc -o conftest -g -O2 conftest.c >&5 configure:5212: $? = 0 configure:5229: result: yes configure:5310: checking for IceConnectionNumber in -lICE configure:5345: gcc -o conftest -g -O2 conftest.c -lICE >&5 configure:5351: $? = 0 configure:5369: result: yes configure:5384: checking for Qt configure:5588: gcc -o conftest -g -O2 conftest.c -lqt -lSM -lICE -lX11 -lXext -lXmu -lXt -lXi >&5 conftest.c:10:26: error: qapplication.h: No such file or directory conftest.c: In function 'main': conftest.c:17: error: 'QApplication' undeclared (first use in this function) conftest.c:17: error: (Each undeclared identifier is reported only once conftest.c:17: error: for each function it appears in.) conftest.c:17: error: expected ';' before 'app' configure:5594: $? = 1 configure: failed program was: | /* confdefs.h. */ | #define PACKAGE_NAME "Valkyrie" | #define PACKAGE_TARNAME "valkyrie" | #define PACKAGE_VERSION "1.4.0" | #define PACKAGE_STRING "Valkyrie 1.4.0" | #define PACKAGE_BUGREPORT "info@..." | #define PACKAGE "valkyrie" | #define VERSION "1.4.0" | /* end confdefs.h. */ | #include <qapplication.h> | int | main () | { | | int argc; | char ** argv; | QApplication app(argc,argv); | | ; | return 0; | } Non-critical error, please neglect the above. configure:5635: gcc -o conftest -g -O2 conftest.c -lqt-mt -lSM -lICE -lX11 -lXext -lXmu -lXt -lXi >&5 conftest.c:10:26: error: qapplication.h: No such file or directory conftest.c: In function 'main': conftest.c:17: error: 'QApplication' undeclared (first use in this function) conftest.c:17: error: (Each undeclared identifier is reported only once conftest.c:17: error: for each function it appears in.) conftest.c:17: error: expected ';' before 'app' configure:5641: $? = 1 configure: failed program was: | /* confdefs.h. */ | #define PACKAGE_NAME "Valkyrie" | #define PACKAGE_TARNAME "valkyrie" | #define PACKAGE_VERSION "1.4.0" | #define PACKAGE_STRING "Valkyrie 1.4.0" | #define PACKAGE_BUGREPORT "info@..." | #define PACKAGE "valkyrie" | #define VERSION "1.4.0" | /* end confdefs.h. */ | #include <qapplication.h> | int | main () | { | | int argc; | char ** argv; | QApplication app(argc,argv); | | ; | return 0; | } Non-critical error, please neglect the above. configure:5682: gcc -o conftest -g -O2 conftest.c -lqt-gl -lSM -lICE -lX11 -lXext -lXmu -lXt -lXi >&5 conftest.c:10:26: error: qapplication.h: No such file or directory conftest.c: In function 'main': conftest.c:17: error: 'QApplication' undeclared (first use in this function) conftest.c:17: error: (Each undeclared identifier is reported only once conftest.c:17: error: for each function it appears in.) conftest.c:17: error: expected ';' before 'app' configure:5688: $? = 1 configure: failed program was: | /* confdefs.h. */ | #define PACKAGE_NAME "Valkyrie" | #define PACKAGE_TARNAME "valkyrie" | #define PACKAGE_VERSION "1.4.0" | #define PACKAGE_STRING "Valkyrie 1.4.0" | #define PACKAGE_BUGREPORT "info@..." | #define PACKAGE "valkyrie" | #define VERSION "1.4.0" | /* end confdefs.h. */ | #include <qapplication.h> | int | main () | { | | int argc; | char ** argv; | QApplication app(argc,argv); | | ; | return 0; | } Non-critical error, please neglect the above. configure:5754: gcc -o conftest -g -O2 conftest.c -lqt-mt -lSM -lICE -lX11 -lXext -lXmu -lXt -lXi >&5 conftest.c:10:26: error: qapplication.h: No such file or directory conftest.c: In function 'main': conftest.c:17: error: 'QApplication' undeclared (first use in this function) conftest.c:17: error: (Each undeclared identifier is reported only once conftest.c:17: error: for each function it appears in.) conftest.c:17: error: expected ';' before 'app' configure:5760: $? = 1 configure: failed program was: | /* confdefs.h. */ | #define PACKAGE_NAME "Valkyrie" | #define PACKAGE_TARNAME "valkyrie" | #define PACKAGE_VERSION "1.4.0" | #define PACKAGE_STRING "Valkyrie 1.4.0" | #define PACKAGE_BUGREPORT "info@..." | #define PACKAGE "valkyrie" | #define VERSION "1.4.0" | /* end confdefs.h. */ | #include <qapplication.h> | int | main () | { | | int argc; | char ** argv; | QApplication app(argc,argv); | | ; | return 0; | } configure:5877: result: no configure:5988: error: Cannot build without QT. ## ---------------- ## ## Cache variables. ## ## ---------------- ## ac_cv_c_compiler_gnu=yes ac_cv_cxx_compiler_gnu=yes ac_cv_env_CCC_set= ac_cv_env_CCC_value= ac_cv_env_CC_set= ac_cv_env_CC_value= ac_cv_env_CFLAGS_set= ac_cv_env_CFLAGS_value= ac_cv_env_CPPFLAGS_set= ac_cv_env_CPPFLAGS_value= ac_cv_env_CPP_set= ac_cv_env_CPP_value= ac_cv_env_CXXFLAGS_set= ac_cv_env_CXXFLAGS_value= ac_cv_env_CXX_set= ac_cv_env_CXX_value= ac_cv_env_LDFLAGS_set= ac_cv_env_LDFLAGS_value= ac_cv_env_LIBS_set= ac_cv_env_LIBS_value= ac_cv_env_XMKMF_set= ac_cv_env_XMKMF_value= ac_cv_env_build_alias_set= ac_cv_env_build_alias_value= ac_cv_env_host_alias_set= ac_cv_env_host_alias_value= ac_cv_env_target_alias_set= ac_cv_env_target_alias_value= ac_cv_func_connect=yes ac_cv_func_gethostbyname=yes ac_cv_func_remove=yes ac_cv_func_shmat=yes ac_cv_have_x='have_x=yes ac_x_includes='\'''\'' ac_x_libraries='\'''\''' ac_cv_lib_ICE_IceConnectionNumber=yes ac_cv_objext=o ac_cv_path_install='/usr/bin/install -c' ac_cv_path_mkdir=/bin/mkdir ac_cv_prog_AWK=mawk ac_cv_prog_CPP='gcc -E' ac_cv_prog_ac_ct_CC=gcc ac_cv_prog_ac_ct_CXX=g++ ac_cv_prog_cc_c89= ac_cv_prog_cc_g=yes ac_cv_prog_cxx_g=yes ac_cv_prog_make_make_set=yes am_cv_CC_dependencies_compiler_type=gcc3 am_cv_CXX_dependencies_compiler_type=gcc3 bnv_cv_have_qt=have_qt=no ## ----------------- ## ## Output variables. ## ## ----------------- ## ACLOCAL='${SHELL} /home/manchi/CppProjects/valgrind/valkyrie-1.4.0/missing --run aclocal-1.10' ALLOCA='' AMDEPBACKSLASH='\' AMDEP_FALSE='#' AMDEP_TRUE='' AMTAR='${SHELL} /home/manchi/CppProjects/valgrind/valkyrie-1.4.0/missing --run tar' AUTOCONF='${SHELL} /home/manchi/CppProjects/valgrind/valkyrie-1.4.0/missing --run autoconf' AUTOHEADER='${SHELL} /home/manchi/CppProjects/valgrind/valkyrie-1.4.0/missing --run autoheader' AUTOMAKE='${SHELL} /home/manchi/CppProjects/valgrind/valkyrie-1.4.0/missing --run automake-1.10' AWK='mawk' CC='gcc' CCDEPMODE='depmode=gcc3' CFLAGS='-g -O2' CPP='gcc -E' CPPFLAGS='' CXX='g++' CXXDEPMODE='depmode=gcc3' CXXFLAGS='-g -O2' CYGPATH_W='echo' DEFS='' DEPDIR='.deps' ECHO_C='' ECHO_N='-n' ECHO_T='' EGREP='' EXEEXT='' GREP='' INSTALL_DATA='${INSTALL} -m 644' INSTALL_PROGRAM='${INSTALL}' INSTALL_SCRIPT='${INSTALL}' INSTALL_STRIP_PROGRAM='$(install_sh) -c -s' LDFLAGS='' LIBOBJS='' LIBS='' LN_S='' LTLIBOBJS='' MAKEINFO='${SHELL} /home/manchi/CppProjects/valgrind/valkyrie-1.4.0/missing --run makeinfo' OBJEXT='o' PACKAGE='valkyrie' PACKAGE_BUGREPORT='info@...' PACKAGE_NAME='Valkyrie' PACKAGE_STRING='Valkyrie 1.4.0' PACKAGE_TARNAME='valkyrie' PACKAGE_VERSION='1.4.0' PATH_SEPARATOR=':' PERL='' QT_CXXFLAGS='' QT_DIR='' QT_LIBS='' QT_MOC='' QT_UIC='' RANLIB='' SET_MAKE='' SHELL='/bin/bash' STRIP='' VALGRIND='' VERSION='1.4.0' VK_EDITOR='' XMKMF='' X_CFLAGS='' X_EXTRA_LIBS='' X_LIBS='' X_PRE_LIBS=' -lSM -lICE' ac_ct_CC='gcc' ac_ct_CXX='g++' am__fastdepCC_FALSE='#' am__fastdepCC_TRUE='' am__fastdepCXX_FALSE='#' am__fastdepCXX_TRUE='' am__include='include' am__isrc='' am__leading_dot='.' am__quote='' am__tar='${AMTAR} chof - "$$tardir"' am__untar='${AMTAR} xf -' bindir='${exec_prefix}/bin' build_alias='' datadir='${datarootdir}' datarootdir='${prefix}/share' docdir='${datarootdir}/doc/${PACKAGE_TARNAME}' dvidir='${docdir}' exec_prefix='NONE' host_alias='' htmldir='${docdir}' includedir='${prefix}/include' infodir='${datarootdir}/info' install_sh='$(SHELL) /home/manchi/CppProjects/valgrind/valkyrie-1.4.0/install-sh' libdir='${exec_prefix}/lib' libexecdir='${exec_prefix}/libexec' localedir='${datarootdir}/locale' localstatedir='${prefix}/var' mandir='${datarootdir}/man' mkdir_p='/bin/mkdir -p' oldincludedir='/usr/include' pdfdir='${docdir}' prefix='NONE' program_transform_name='s,x,x,' psdir='${docdir}' sbindir='${exec_prefix}/sbin' sharedstatedir='${prefix}/com' sysconfdir='${prefix}/etc' target_alias='' ## ----------- ## ## confdefs.h. ## ## ----------- ## #define PACKAGE_NAME "Valkyrie" #define PACKAGE_TARNAME "valkyrie" #define PACKAGE_VERSION "1.4.0" #define PACKAGE_STRING "Valkyrie 1.4.0" #define PACKAGE_BUGREPORT "info@..." #define PACKAGE "valkyrie" #define VERSION "1.4.0" configure: exit 1

Re: "fatal error: unsupported CPU" on Via C7 Esther processor

2009-12-05T02:55:14Z

Julian Seward wrote:

>> Trying to avoid doing real work, I searched for "unsupported CPU" and
>> found it in coregrind/m_main.c. I then found VG_(machine_get_hwcaps)() in
>> m_machine.c. Putting a few VG_(printf)() calls into this routine, I found
>> that it fails this test:
>>
>> /* cmpxchg8b is a minimum requirement now; if we don't have it we
>> must simply give up. But all CPUs since Pentium-I have it, so
>> that doesn't seem like much of a restriction. */
>> have_cx8 = (edx & (1<<8)) != 0; /* True => have cmpxchg8b */
>> if (!have_cx8)
>> return False;
>>
>> Interestingly, /proc/cpuinfo does not show "cx8" on my machines, while it
>> does on yours. I didn't think my CPU was that old, since it runs at 1.2
>> GHz (I bought the machines in late 2006). Looks like I am out of luck on
>> these two machines. Given the comment in the source code here, I doubt
>> very much that provisions would be made to support this CPU. :-)
>>
>
> It may be that the CPU does support cmpxchg8b but doesn't say it does.
> Try compiling and running the program none/tests/x86/cmpxchg8b.c in the
> 3.5.0 tree, and see if it runs natively OK (without SIGILL). If yes
> then comment out the relevant test in VG_(machine_get_hwcaps)().
>
> J
>
>

I got the following output from the program, which looks correct if my
understanding of CMPXCHG8B is correct (last time I wrote ASM, the 386
was still very new!):

0x22222222 0x44444444 0x33333333 0x11111111 0x246 0x3333333344444444
0x22222223 0x44444444 0x33333333 0x11111111 0x206 0x1111111122222223
0x22222222 0x44444444 0x33333333 0x11111112 0x206 0x1111111222222222
0x77777777 0x44444444 0x33333333 0x66666666 0x206 0x6666666677777777

It didn't core dump, anyway, and "./vg-in-place date" runs to completion
after I comment out those lines in VG_(machine_get_hwcaps)(). So I
guess that's a good thing. But it's nearly 3 A.M. here in California
and I could be wrong. ;-)

It is a little surprising that the C7 Esther core doesn't report that
instruction, but the Linux kernel has special compilation flags for this
CPU because it claims to be a 686 compatible processor yet doesn't
implement all of the instructions of a real Pentium II. Maybe this is a
similar issue (though harmless for most software packages because they
work around it).

Thanks for your help.

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Valgrind-users mailing list
Valgrind-users@...
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: "fatal error: unsupported CPU" on Via C7 Esther processor

2009-12-05T01:43:47Z

> Trying to avoid doing real work, I searched for "unsupported CPU" and
> found it in coregrind/m_main.c. I then found VG_(machine_get_hwcaps)() in
> m_machine.c. Putting a few VG_(printf)() calls into this routine, I found
> that it fails this test:
>
>       /* cmpxchg8b is a minimum requirement now; if we don't have it we
>          must simply give up. But all CPUs since Pentium-I have it, so
>          that doesn't seem like much of a restriction. */
>       have_cx8 = (edx & (1<<8)) != 0; /* True => have cmpxchg8b */
>       if (!have_cx8)
>          return False;
>
> Interestingly, /proc/cpuinfo does not show "cx8" on my machines, while it
> does on yours. I didn't think my CPU was that old, since it runs at 1.2
> GHz (I bought the machines in late 2006). Looks like I am out of luck on
> these two machines. Given the comment in the source code here, I doubt
> very much that provisions would be made to support this CPU. :-)

It may be that the CPU does support cmpxchg8b but doesn't say it does.
Try compiling and running the program none/tests/x86/cmpxchg8b.c in the
3.5.0 tree, and see if it runs natively OK (without SIGILL). If yes
then comment out the relevant test in VG_(machine_get_hwcaps)().

J

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Valgrind-users mailing list
Valgrind-users@...
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: "fatal error: unsupported CPU" on Via C7 Esther processor

2009-12-04T17:53:19Z

David Chapman wrote:

Julian Seward wrote:

I'm getting a "fatal error: unsupported CPU" on my Via C7 Esther
processor-based machine running a brand new installation of Slackware
13.0.  valgrind-3.1.0 ran just fine on the machine before the upgrade.

Really?  The minimum requirements haven't changed.  I have a very
ancient VIA cpu here which it runs fine on:

$ cat /proc/cpuinfo
processor       : 0
vendor_id       : CentaurHauls
cpu family      : 6
model           : 7
model name      : VIA Samuel 2
stepping        : 3
cpu MHz         : 533.349
cache size      : 64 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu de tsc msr cx8 mtrr pge mmx 3dnow up
bogomips        : 1066.69
clflush size    : 32
power management:

installing but can't get ./coregrind/valgrind to tell me anything - it
can't find memcheck.)

Sounds like your build is broken.  Anyway, you shouldn't be running
random bits of the build.  Either run vg-in-place or do make install
and run $prefix/bin/valgrind.

On the above machine, a run "valgrind -d date" produces lots of
debug output, including

--15887:1:main     Get hardware capabilities ...
--15887:1:main     ... arch = X86, hwcaps = x86-sse0

What happens on your machine?

J


Last time I built valgrind, it worked just fine "out of the box", so I 
didn't need to learn how to debug it (and I see now that "vg-in-place" 
didn't exist).  Thanks for the information.  That's very useful.

Under Slackware 11.0, using the machine that still runs valgrind 3.1.0, 
I get the following with valgrind 3.5.0:

# ./vg-in-place -d date
--2299:1:debuglog DebugLog system started by Stage 1, level 1 logging 
requested
--2299:1:launcher no tool requested, defaulting to 'memcheck'
--2299:1:launcher selected platform 'x86-linux'
--2299:1:launcher launching 
/usr/local/src/valgrind/valgrind-3.5.0/./.in_place/memcheck-x86-linux
--2299:1:debuglog DebugLog system started by Stage 2 (main), level 1 
logging requested
--2299:1:main     Welcome to Valgrind version 3.5.0 debug logging
--2299:1:main     Checking current stack is plausible
--2299:1:main     Checking initial stack was noted
--2299:1:main     Starting the address space manager
--2299:1:main     Address space manager is running
--2299:1:main     Starting the dynamic memory manager
--2299:1:mallocfr newSuperblock at 0x61DC0000 (pszB 4194288) owner 
VALGRIND/tool
--2299:1:main     Dynamic memory manager is running
--2299:1:main     Initialise m_debuginfo
--2299:1:main     VG_(libdir) = 
/usr/local/src/valgrind/valgrind-3.5.0/./.in_place
--2299:1:main     Getting launcher's name ...
--2299:1:main     ... 
/usr/local/src/valgrind/valgrind-3.5.0/coregrind/valgrind
--2299:1:main     Get hardware capabilities ...

valgrind: fatal error: unsupported CPU.
   Supported CPUs are:
   * x86 (practically any; Pentium-I or above), AMD Athlon or above)
   * AMD Athlon64/Opteron
   * PowerPC (most; ppc405 and above)

/proc/cpuinfo on this machine yields:

# cat /proc/cpuinfo
processor       : 0
vendor_id       : CentaurHauls
cpu family      : 6
model           : 10
model name      : VIA Esther processor 1200MHz
stepping        : 9
cpu MHz         : 1201.143
cache size      : 128 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce apic sep mtrr pge cmov 
pat clflush acpi mmx fxsr sse sse2 tm nx up pni est tm2 rng rng_en ace 
ace_en
bogomips        : 2408.44

The /proc/cpuinfo output on the Slackware 13.0 machine differs slightly, 
in particular the flags:

flags           : fpu vme de pse tsc msr pae mce apic sep mtrr pge cmov 
pat clflush acpi mmx fxsr sse sse2 tm nx up pni est tm2 rng rng_en ace 
ace_en ace2 ace2_en phe phe_en pmm pmm_en

Finally, a snippet from a 3.1.0 "valgrind -d date" run on the Slackware 
11.0 machine:

--2301:1:main     Get hardware capabilities ...
--2301:1:main     ... arch = X86, subarch = x86-sse2

Oddly, this does *not* appear when I installed valgrind 3.1.0 on the 
Slackware 13.0 machine (even after "make uninstall" in the 3.5.0 
installation).  Instead I get some hundreds of:

--5811-- DWARF2 CFI reader: unhandled CFI instruction 0:22

But version 3.1.0 "valgrind -d date" does run on the Slackware 13.0 box.

So something has clearly changed in the way that hardware capabilities 
are retrieved in valgrind, such that Slackware builds on Via CPUs don't 
return the proper information.

I can apply patches or insert debug printf() statements if someone can 
tell me where to look.  I'm swamped right now, so I don't have time to 
learn a whole lot about the source code.  :-(

Trying to avoid doing real work, I searched for "unsupported CPU" and found it in coregrind/m_main.c. I then found VG_(machine_get_hwcaps)() in m_machine.c. Putting a few VG_(printf)() calls into this routine, I found that it fails this test:

     /* cmpxchg8b is a minimum requirement now; if we don't have it we
        must simply give up. But all CPUs since Pentium-I have it, so
        that doesn't seem like much of a restriction. */
     have_cx8 = (edx & (1<<8)) != 0; /* True => have cmpxchg8b */
     if (!have_cx8)
        return False;

Interestingly, /proc/cpuinfo does not show "cx8" on my machines, while it does on yours. I didn't think my CPU was that old, since it runs at 1.2 GHz (I bought the machines in late 2006). Looks like I am out of luck on these two machines. Given the comment in the source code here, I doubt very much that provisions would be made to support this CPU. :-)

At least I have dual-core and quad-core Athlons that I can also do development on...

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Valgrind-users mailing list
Valgrind-users@...
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: "fatal error: unsupported CPU" on Via C7 Esther processor

2009-12-03T10:59:34Z

Julian Seward wrote:

>> I'm getting a "fatal error: unsupported CPU" on my Via C7 Esther
>> processor-based machine running a brand new installation of Slackware
>> 13.0. valgrind-3.1.0 ran just fine on the machine before the upgrade.
>>
>
> Really? The minimum requirements haven't changed. I have a very
> ancient VIA cpu here which it runs fine on:
>
> $ cat /proc/cpuinfo
> processor : 0
> vendor_id : CentaurHauls
> cpu family : 6
> model : 7
> model name : VIA Samuel 2
> stepping : 3
> cpu MHz : 533.349
> cache size : 64 KB
> fdiv_bug : no
> hlt_bug : no
> f00f_bug : no
> coma_bug : no
> fpu : yes
> fpu_exception : yes
> cpuid level : 1
> wp : yes
> flags : fpu de tsc msr cx8 mtrr pge mmx 3dnow up
> bogomips : 1066.69
> clflush size : 32
> power management:
>
>
>> installing but can't get ./coregrind/valgrind to tell me anything - it
>> can't find memcheck.)
>>
>
> Sounds like your build is broken. Anyway, you shouldn't be running
> random bits of the build. Either run vg-in-place or do make install
> and run $prefix/bin/valgrind.
>
> On the above machine, a run "valgrind -d date" produces lots of
> debug output, including
>
> --15887:1:main Get hardware capabilities ...
> --15887:1:main ... arch = X86, hwcaps = x86-sse0
>
> What happens on your machine?
>
> J
>
>

Last time I built valgrind, it worked just fine "out of the box", so I
didn't need to learn how to debug it (and I see now that "vg-in-place"
didn't exist). Thanks for the information. That's very useful.

Under Slackware 11.0, using the machine that still runs valgrind 3.1.0,
I get the following with valgrind 3.5.0:

# ./vg-in-place -d date
--2299:1:debuglog DebugLog system started by Stage 1, level 1 logging
requested
--2299:1:launcher no tool requested, defaulting to 'memcheck'
--2299:1:launcher selected platform 'x86-linux'
--2299:1:launcher launching
/usr/local/src/valgrind/valgrind-3.5.0/./.in_place/memcheck-x86-linux
--2299:1:debuglog DebugLog system started by Stage 2 (main), level 1
logging requested
--2299:1:main Welcome to Valgrind version 3.5.0 debug logging
--2299:1:main Checking current stack is plausible
--2299:1:main Checking initial stack was noted
--2299:1:main Starting the address space manager
--2299:1:main Address space manager is running
--2299:1:main Starting the dynamic memory manager
--2299:1:mallocfr newSuperblock at 0x61DC0000 (pszB 4194288) owner
VALGRIND/tool
--2299:1:main Dynamic memory manager is running
--2299:1:main Initialise m_debuginfo
--2299:1:main VG_(libdir) =
/usr/local/src/valgrind/valgrind-3.5.0/./.in_place
--2299:1:main Getting launcher's name ...
--2299:1:main ...
/usr/local/src/valgrind/valgrind-3.5.0/coregrind/valgrind
--2299:1:main Get hardware capabilities ...

valgrind: fatal error: unsupported CPU.
Supported CPUs are:
* x86 (practically any; Pentium-I or above), AMD Athlon or above)
* AMD Athlon64/Opteron
* PowerPC (most; ppc405 and above)

/proc/cpuinfo on this machine yields:

# cat /proc/cpuinfo
processor : 0
vendor_id : CentaurHauls
cpu family : 6
model : 10
model name : VIA Esther processor 1200MHz
stepping : 9
cpu MHz : 1201.143
cache size : 128 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce apic sep mtrr pge cmov
pat clflush acpi mmx fxsr sse sse2 tm nx up pni est tm2 rng rng_en ace
ace_en
bogomips : 2408.44

The /proc/cpuinfo output on the Slackware 13.0 machine differs slightly,
in particular the flags:

flags : fpu vme de pse tsc msr pae mce apic sep mtrr pge cmov
pat clflush acpi mmx fxsr sse sse2 tm nx up pni est tm2 rng rng_en ace
ace_en ace2 ace2_en phe phe_en pmm pmm_en

Finally, a snippet from a 3.1.0 "valgrind -d date" run on the Slackware
11.0 machine:

--2301:1:main Get hardware capabilities ...
--2301:1:main ... arch = X86, subarch = x86-sse2

Oddly, this does *not* appear when I installed valgrind 3.1.0 on the
Slackware 13.0 machine (even after "make uninstall" in the 3.5.0
installation). Instead I get some hundreds of:

--5811-- DWARF2 CFI reader: unhandled CFI instruction 0:22

But version 3.1.0 "valgrind -d date" does run on the Slackware 13.0 box.

So something has clearly changed in the way that hardware capabilities
are retrieved in valgrind, such that Slackware builds on Via CPUs don't
return the proper information.

I can apply patches or insert debug printf() statements if someone can
tell me where to look. I'm swamped right now, so I don't have time to
learn a whole lot about the source code. :-(

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Valgrind-users mailing list
Valgrind-users@...
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: "fatal error: unsupported CPU" on Via C7 Esther processor

2009-12-03T01:32:43Z

> I'm getting a "fatal error: unsupported CPU" on my Via C7 Esther
> processor-based machine running a brand new installation of Slackware
> 13.0. valgrind-3.1.0 ran just fine on the machine before the upgrade.

Really? The minimum requirements haven't changed. I have a very
ancient VIA cpu here which it runs fine on:

$ cat /proc/cpuinfo
processor : 0
vendor_id : CentaurHauls
cpu family : 6
model : 7
model name : VIA Samuel 2
stepping : 3
cpu MHz : 533.349
cache size : 64 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu de tsc msr cx8 mtrr pge mmx 3dnow up
bogomips : 1066.69
clflush size : 32
power management:

> installing but can't get ./coregrind/valgrind to tell me anything - it
> can't find memcheck.)

Sounds like your build is broken. Anyway, you shouldn't be running
random bits of the build. Either run vg-in-place or do make install
and run $prefix/bin/valgrind.

On the above machine, a run "valgrind -d date" produces lots of
debug output, including

--15887:1:main Get hardware capabilities ...
--15887:1:main ... arch = X86, hwcaps = x86-sse0

What happens on your machine?

J

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Valgrind-users mailing list
Valgrind-users@...
https://lists.sourceforge.net/lists/listinfo/valgrind-users

"fatal error: unsupported CPU" on Via C7 Esther processor

2009-12-02T17:35:43Z

I'm getting a "fatal error: unsupported CPU" on my Via C7 Esther
processor-based machine running a brand new installation of Slackware
13.0. valgrind-3.1.0 ran just fine on the machine before the upgrade.

This is a fresh installation; I wiped the hard disk prior to the
upgrade. I have not yet rebuilt the kernel - I'm using the default SMP
kernel from the Slackware 13.0 installation DVD. I could build a custom
kernel for the Via CPU if that would help, but I'm guessing that the
problem comes from uname.

Snippets from the two config.log files follow.

Under Slackware 13.0:

## --------- ##
## Platform. ##
## --------- ##

hostname = sojourner
uname -m = i686
uname -r = 2.6.29.6-smp
uname -s = Linux
uname -v = #2 SMP Mon Aug 17 00:52:54 CDT 2009

/usr/bin/uname -p = VIA Esther processor 1200MHz
/bin/uname -X = unknown

/bin/arch = i686

Under Slackware 11.0:

## --------- ##
## Platform. ##
## --------- ##

hostname = sojourner
uname -m = i686
uname -r = 2.6.17.13
uname -s = Linux
uname -v = #1 Thu Feb 1 10:50:30 PST 2007

/usr/bin/uname -p = i686
/bin/uname -X = unknown

/bin/arch = i686

(end of snippets)

"uname --all" under Slackware 11.0 returns:

Linux mariner 2.6.17.13 #5 Fri Dec 29 19:31:36 PST 2006 i686 i686 i386
GNU/Linux

"uname --all" under Slackware 13.0 returns this mouthful:

Linux sojourner 2.6.29.6-smp #2 SMP Mon Aug 17 00:52:54 CDT 2009 i686
VIA Esther processor 1200MHz CentaurHauls GNU/Linux

sojourner is the guinea pig for the production machine (mariner), which
is still running Slackware 11.0 and valgrind 3.1.0. I could try
installing 3.5.0 on the production machine (which doesn't see all that
much development work anyway), but I'd like to see if anyone has any
ideas first. (FWIW, I built 3.5.0 under Slackware 11.0 without
installing but can't get ./coregrind/valgrind to tell me anything - it
can't find memcheck.)

I'm a new subscriber, so initially it might be best to reply both to my
E-mail address and the list.

Thanks in advance.

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Valgrind-users mailing list
Valgrind-users@...
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: memcheck behaviour in random failure of an open mpi based code.

2009-12-02T04:19:26Z

On Tue, 2009-12-01 at 22:49 +0000, Indi Tristanto wrote:

> Ashley, Tom
>
> Thank you for your reply.
>
> I add --mca btl tcp, self as mpirun argument following Julian
> suggestion on Tom's posting. Indeed this managed to supress open mpi
> errors to the extend that the valgrind log file is actually reduced
> from 20Mb to only a few kb. However I found the discussion through a
> google search, hence I'd appreciate if you could point me to the
> tittle of the FAQ so that I can follow the complete discussion.

The "--mca btl tcp,self" option tells OpenMPI to communicate only via
tcp and loopback. Of note here is that "sm" or shared memory is
missing, it's the shared memory fifo's that confuse valgrind and cause
the 20Mb of errors you'd have seen. These would most likely all be
false positives.

> Valgrind never print out any error until the program crash with
> messages I've wrote in my original posting. Since it happens in the
> middle of an iterative process, the line where the program crashes has
> been passed during the previous iterations without problem. As far as
> I can see the program is trying to call mpi_reduce when it crashed.
> Looking at valgrind behaviour, I have impression that the problem lies
> on open-mpi 1.2.6. rather than on my program. (Valgrind did not report
> anything when I checked the same program in sequential environment as
> well as under mpich environment with gnu compilation) However, I was
> expecting valgrind to report the problem earlier, i.e. when
> mpi_allreduce is called by the same program line at the very first
> iteration.

If you look at your stack trace closer it claims to be in malloc which
is itself in libopen-pal. Normally malloc is in libc and valgrind
intercepts it as such, OpenMPI by default replaces the libc malloc with
it's own version in libopen-pal which valgrind won't have intercepted.
What this means is that you aren't getting the full value of memcheck as
buffer over-runs and under-runs aren't being caught (as Valgrind doesn't
know what has been malloced and what hasn't). Internally mpi_reduce is
calling malloc which is then crashing, most likely because it's private
data structures have been over-written by a buffer over-run.

If you re-link your program without libopen-pal and re-run you will be
using the libc malloc and valgrind will be able to do a lot more checks,
hopefully including the buffer over-run which went on to cause the
problem you are seeing.

> Also have I been naive in expecting this sort of error to be reported
> cleanly?

No that's not naive.

> My problem is that I have more than one call to mpi_allreduce and the
> failure seems to happen randomly at any of the calls as well as the
> number of iteration. So my valgrind error log changes from each run,
> thus what I quoted on my posting is the "typical" error that I have
> seen.

I hope the above explains this, there will be many calls to malloc
throughout the code and once you've over-written the meta-data it's
essentially pot luck which one goes on to crash.

> By the way thank you for the suggestion on upgrading the open mpi.

I believe the latest OpenMPI doesn't replace malloc by default, I'm not
entirely sure on this however. Certainly you can configure it not to.

Ashley.

--

Ashley Pittman, Bath, UK.

Padb - A parallel job inspection tool for cluster computing
http://padb.pittman.org.uk

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Valgrind-users mailing list
Valgrind-users@...
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: memcheck behaviour in random failure of an open mpi based code.

2009-12-01T14:49:08Z

Ashley, Tom

Thank you for your reply.

I add --mca btl tcp, self as mpirun argument following Julian suggestion on Tom's posting. Indeed this managed to supress open mpi errors to the extend that the valgrind log file is actually reduced from 20Mb to only a few kb. However I found the discussion through a google search, hence I'd appreciate if you could point me to the tittle of the FAQ so that I can follow the complete discussion.

As of my problem, the program did crash, presumably with a segfault. I put 'presumably' since valgrind simply hang the whole parallel computation after printing out the last error message.

Valgrind never print out any error until the program crash with messages I've wrote in my original posting. Since it happens in the middle of an iterative process, the line where the program crashes has been passed during the previous iterations without problem. As far as I can see the program is trying to call mpi_reduce when it crashed. Looking at valgrind behaviour, I have impression that the problem lies on open-mpi 1.2.6. rather than on my program. (Valgrind did not report anything when I checked the same program in sequential environment as well as under mpich environment with gnu compilation) However, I was expecting valgrind to report the problem earlier, i.e. when mpi_allreduce is called by the same program line at the very first iteration.

What I am wondering at the moment is whether the problem is hidden within the ompi-suppressed errors ?
Also have I been naive in expecting this sort of error to be reported cleanly?
My problem is that I have more than one call to mpi_allreduce and the failure seems to happen randomly at any of the calls as well as the number of iteration. So my valgrind error log changes from each run, thus what I quoted on my posting is the "typical" error that I have seen.

By the way thank you for the suggestion on upgrading the open mpi.

Regards

Indi

> Subject: Re: [Valgrind-users] memcheck behaviour in random failure of an open mpi based code.
> From: ashley@...
> To: tfogal@...
> CC: ihtristanto@...
> Date: Mon, 30 Nov 2009 18:50:00 +0000
>
> On Mon, 2009-11-30 at 10:20 -0700, tom fogal wrote:
> > Ashley Pittman <ashley@...> writes:
> > > On Sun, 2009-11-29 at 19:34 -0700, tom fogal wrote:
> > > > Indi Tristanto <ihtristanto@...> writes:
> > > > > I am trying to debug a large iterative solver that has been compiled usin
> > > g =
> > > > > intel fortran 10 and open mpi 1.2.6.
> > > > >
> > > > This looks (very) familiar to an issue I brought up with the OpenMPI
> > > > folks earlier this year. See ticket 1942:
> > > >
> > > > https://svn.open-mpi.org/trac/ompi/ticket/1942
> > >
> > > The error in that ticket is about uninitialised reads which do happen
> > > and are semi-expected with socket programming.
> >
> > No, it is not. It is about valgrinding OpenMPI programs. It links to
> > a thread which originally started with uninitialized reads, but if you
> > follow the thread you'll note that the discussion became much wider
> > than the original posting.
> >
> > > The error in this email is about a crash (segfault) in the open mpi
> > > library, I doubt the two are related.
> >
> > At no point in Indi's email did he mention the application segfault or
> > crashed.
>
> I was thinking about the "Adress 0x10 is not stack'd, malloc'd or
> (recently) free'd" message. Actually there's a spelling mistake in that
> error message, I assume this is from transmission somewhere rather than
> in the actual valgrind output.
>
> Given that OpenMPI has it's own malloc implementation it's likely that
> allocations aren't being intercepted and buffer over-runs aren't being
> intercepted and quite possible the error is being caused by an invalid
> write that valgrind isn't catching.
>
> Ashley,
>
> --
>
> Ashley Pittman, Bath, UK.
>
> Padb - A parallel job inspection tool for cluster computing
> http://padb.pittman.org.uk
>

View your other email accounts from your Hotmail inbox. Add them now.
------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Valgrind-users mailing list
Valgrind-users@...
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: memcheck behaviour in random failure of an open mpi based code.

2009-11-30T04:07:15Z

On Sun, 2009-11-29 at 19:34 -0700, tom fogal wrote:
> Indi Tristanto <ihtristanto@...> writes:
> > I am trying to debug a large iterative solver that has been compiled using =
> > intel fortran 10 and open mpi 1.2.6.
> >
> This looks (very) familiar to an issue I brought up with the OpenMPI
> folks earlier this year. See ticket 1942:
>
> https://svn.open-mpi.org/trac/ompi/ticket/1942

The error in that ticket is about uninitialised reads which do happen
and are semi-expected with socket programming. The error in this email
is about a crash (segfault) in the open mpi library, I doubt the two are
related.

> As a 5 second summary, the ticket is closed, there is a FAQ for this,
> and at least the trunk versions of OpenMPI have a valgrind suppression
> file that you'll want to use.

I wasn't aware that OpenMPI now ships with a suppression file, if it
does I'd suggest using it, it'll help separate out the errors from the
noise.

Ashley,

--

Ashley Pittman, Bath, UK.

Padb - A parallel job inspection tool for cluster computing
http://padb.pittman.org.uk

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Valgrind-users mailing list
Valgrind-users@...
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: memcheck behaviour in random failure of an open mpi based code.

2009-11-29T18:34:28Z

Indi Tristanto <ihtristanto@...> writes:

> I am trying to debug a large iterative solver that has been compiled using =
> intel fortran 10 and open mpi 1.2.6.
>
> Invalid write of size 8
> at 0x511BF6B: _int_malloc (in /opt/openmpi-1.2.6/intel/lib/libopen-pal.so=
> .0.0.0) =20
> by 0x511B710: malloc (in /opt/openmpi-1.2.6/intel/lib/libopen-pal.so.0.0.=
> 0)
> by 0x907161A: ompi_coll_tuned_allreduce_intra_recursivedoubling (in /opt/=
> openmpi-1.2.6/intel/lib/mca_coll_tuned.so)
> by 0x906FFED: ompi_coll_tuned_allreduce_intra_dec_fixed (in /opt/openmpi-=
> 1.2.6/intel/lib/mca_coll_tuned.so)
>
> by 0x4DFFEF7: PMPI_Allreduce (in /opt/openmpi-1.2.6/intel/lib/libmpi.so.0=
> .0.0)
>
> by 0x4C9C612: PMPI_ALLREDUCE (in /opt/openmpi-1.2.6/intel/lib/libmpi_f77.=
> so.0.0.0)
> by 0x6E006E: my_mpireduce_call (my_routine.F)

This looks (very) familiar to an issue I brought up with the OpenMPI
folks earlier this year. See ticket 1942:

https://svn.open-mpi.org/trac/ompi/ticket/1942

As a 5 second summary, the ticket is closed, there is a FAQ for this,
and at least the trunk versions of OpenMPI have a valgrind suppression
file that you'll want to use.

-tom

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Valgrind-users mailing list
Valgrind-users@...
https://lists.sourceforge.net/lists/listinfo/valgrind-users

exp-bbv module clarification

2009-11-28T15:42:27Z

Hi,

I am trying to use the bbv tool in Valgrind to look at block level similarity between threads.
I am testing this with Valgrind 3.6.0 SVN together with Apache 2.2.14 with mpm_worker thread model.

Although I use %p to tag the output files, something seems unusual. I get pc files which seem to have no corresponding bb files.

To make this more clear the output looks like:
apache_bb.out.11325
apache_bb.out.11325.2
apache_bb.out.11325.3
apache_bb.out.11325.4
apache_bb.out.11325.5
apache_bb.out.11325.6
[...]
apache_pc.out.11325
apache_pc.out.11328
apache_pc.out.11329
apache_pc.out.11330
apache_pc.out.11331
apache_pc.out.11495
apache_pc.out.11630
apache_pc.out.11631
apache_pc.out.11828
apache_pc.out.11832
apache_pc.out.11839
apache_pc.out.11845
apache_pc.out.12089
[...]

So apache_bb.out.11325.2 I would assume is the 2nd thread in 11325 pid. If they share the same code segment (apache_pc.out.11325), then what are the other pc files for?
Could the pc files be for each thread and %p prints the thread pid omitting the parent pid (11325)

Here's a part of my bash script:

VALGRIND_TARGET="$APACHE/bin/httpd"
INTERVAL_SIZE=100000

VALGRIND_CMD="$VALGRIND --tool=exp-bbv --bb-out-file=$RESULTS/%q{BENCH}_bb.out.%p --pc-out-file=$RESULTS/%q{BENCH}_pc.out.%p --interval-size=$INTERVAL_SIZE --time-stamp=yes --num-callers=30 --track-fds=yes --trace-children=no $VALGRIND_TARGET"

Could someone offer a few pointers please?

Thank you,
V

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Valgrind-users mailing list
Valgrind-users@...
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: Help required

2009-11-27T14:49:25Z

Valgrind does not yet support arm. Can you also do an x86 build and valgrind that?

On Nov 27, 2009 2:24 AM, "Jogeshwar Ashish (RBEI/ECV1 CM-PS/ETC1)" <Ashish.Jogeshwar2@...> wrote:

Hello,

To start with i will say that i am novice with Linux.

We are developing an application in C++ for the given platform : Ubuntu 9.04 + ARM 9 iMX25 series processor.

We are usinng Vmware on Windows for our development.

We would like to use Valgrind as a profiling tool for our system.

What i want to know is does Valgrind support this platform.

Ofcourse i have seen that you do support porting for ARM platforms on Linux but i just wanted your opinion on this.

Any other comments are welcome

Mit freundlichen Grüßen / Best regards

Ashish Jogeshwar

Robert Bosch Car Multimedia GmbH

Bosch Electronic Service

Robert-Bosch-Straße 200

31139 Hildesheim

GERMANY

www.bosch.com

ashish.jogeshwar2@...

Sitz: Hildesheim, Registergericht: Amtsgericht Hildesheim HRB 201334

Geschäftsführung: Uwe Thomas, Robby Drave, Egbert Hellwig, Dirk Hoheisel

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Valgrind-users mailing list
Valgrind-users@...
https://lists.sourceforge.net/lists/listinfo/valgrind-users

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Valgrind-users mailing list
Valgrind-users@...
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: memcheck behaviour in random failure of an open mpi based code.

2009-11-27T04:39:28Z

On Fri, 2009-11-27 at 10:26 +0000, Indi Tristanto wrote:
> I am trying to debug a large iterative solver that has been compiled
> using intel fortran 10 and open mpi 1.2.6. that is run in a SLES10
> based PC cluster using valgrind 3.5.0. To supress the openmpi error
> messages I've put mpi argument "--mca btl tcp, self", otherwise the
> log file is simply filled by open mpi messages, which may amount to
> 20Mb. Here, I am not trying to debug the open mpi.

Open MPI 1.2.6 is fairly old now, there have been some major
improvements in the 1.3 series.

> The problem appears at random in after several iterations which
> suggest a memory related problem. I expect Memcheck to report an error
> when the offending lines is executed for the first time.

Like threaded applications parallel applications can suffer from race
conditions that only occur periodically or when a certain set of timing
conditions exist.

> Does that error message suggest the dynamic memory allocation within
> open-mpi allreduce operation is at fault? If this is the case, could I
> capture the problem earlier by removing the mpi suppression ?

I thought you said the program was clean up until that point?

One thing you should know is that open-mpi has at times in the past
replaced the libc malloc with it's own verion, if it's done this then
memcheck will be able to do considerably fewer checks as it will
probably not know about these allocations. I'd recommend downloading
the latest Open-MPI release (I believe 1.3.3 is still the latest, 1.3.4
is due real-soon now, probably when folks get back after thanks giving)
and compile it without the malloc hooks.

Ashley,

--

Ashley Pittman, Bath, UK.

Padb - A parallel job inspection tool for cluster computing
http://padb.pittman.org.uk

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Valgrind-users mailing list
Valgrind-users@...
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: Help required

2009-11-27T04:10:42Z

On Fri, 2009-11-27 at 11:22 +0100, Jogeshwar Ashish (RBEI/ECV1
CM-PS/ETC1) wrote:
> Hello,
>
> To start with i will say that i am novice with Linux.
> We are developing an application in C++ for the given platform :
> Ubuntu 9.04 + ARM 9 iMX25 series processor.
> We are usinng Vmware on Windows for our development.
> We would like to use Valgrind as a profiling tool for our system.

The only problem I have ever encountered is when trying to progmatically
determine if, indeed the environment is virtual from within a program
(UD2 instruction) however this was using Xen. Additionally, it wasn't
hard to work around the SIGILL subsequently raised.

A little more detail is here:

https://bugs.kde.org/show_bug.cgi?id=191062

Beyond that, I have yet to have problems using Valgrind on any decent
emulator or virtualization platform. I've never used VMWare on a Windows
host, but I can't imagine that the guest would be any different. ICBW.

Cheers,
--Tim

--
Monkey + Typewriter = Echoreply ( http://echoreply.us )

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Valgrind-users mailing list
Valgrind-users@...
https://lists.sourceforge.net/lists/listinfo/valgrind-users

memcheck behaviour in random failure of an open mpi based code.

2009-11-27T02:17:42Z

Hi,

I am trying to debug a large iterative solver that has been compiled using intel fortran 10 and open mpi 1.2.6. that is run in a SLES10 based PC cluster using valgrind 3.5.0. To supress the openmpi error messages I've put mpi argument "--mca btl tcp, self", otherwise the log file is simply filled by open mpi messages, which may amount to 20Mb. Here, I am not trying to debug the open mpi.

The problem appears at random in after several iterations which suggest a memory related problem. I expect Memcheck to report an error when the offending lines is executed for the first time. However, Memcheck does not report up any problem prior to the point of failure, i.e. the part of the code that fail has been passed by Memcheck as problem free in previous iterations. At the point of failure, typically the following error is logged by memcheck

Invalid write of size 8
at 0x511BF6B: _int_malloc (in /opt/openmpi-1.2.6/intel/lib/libopen-pal.so.0.0.0)
by 0x511B710: malloc (in /opt/openmpi-1.2.6/intel/lib/libopen-pal.so.0.0.0)
by 0x907161A: ompi_coll_tuned_allreduce_intra_recursivedoubling (in /opt/openmpi-1.2.6/intel/lib/mca_coll_tuned.so)
by 0x906FFED: ompi_coll_tuned_allreduce_intra_dec_fixed (in /opt/openmpi-1.2.6/intel/lib/mca_coll_tuned.so)
by 0x4DFFEF7: PMPI_Allreduce (in /opt/openmpi-1.2.6/intel/lib/libmpi.so.0.0.0)
by 0x4C9C612: PMPI_ALLREDUCE (in /opt/openmpi-1.2.6/intel/lib/libmpi_f77.so.0.0.0)
by 0x6E006E: my_mpireduce_call (my_routine.F)
.
.
.
Adress 0x10 is not stack'd, malloc'd or (recently) free'd

Since memcheck does not detect any problem earlier when the point of failure is executed, does it mean the program is fairly sound? I could not see any bug at the program line that call the mpi reduce.

Does that error message suggest the dynamic memory allocation within open-mpi allreduce operation is at fault? If this is the case, could I capture the problem earlier by removing the mpi suppression ?

Regards

View your other email accounts from your Hotmail inbox. Add them now.
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Valgrind-users mailing list
Valgrind-users@...
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Help required

2009-11-27T02:22:41Z

Hello,

To start with i will say that i am novice with Linux.

We are developing an application in C++ for the given platform : Ubuntu 9.04 + ARM 9 iMX25 series processor.

We are usinng Vmware on Windows for our development.

We would like to use Valgrind as a profiling tool for our system.

What i want to know is does Valgrind support this platform.

Ofcourse i have seen that you do support porting for ARM platforms on Linux but i just wanted your opinion on this.

Any other comments are welcome

Mit freundlichen Grüßen / Best regards

Ashish Jogeshwar

Robert Bosch Car Multimedia GmbH

Bosch Electronic Service

Robert-Bosch-Straße 200

31139 Hildesheim

GERMANY

www.bosch.com

ashish.jogeshwar2@...

Sitz: Hildesheim, Registergericht: Amtsgericht Hildesheim HRB 201334

Geschäftsführung: Uwe Thomas, Robby Drave, Egbert Hellwig, Dirk Hoheisel

Re: Possible false positive/bug in memcheck

2009-11-26T21:32:17Z

On Thu, Nov 26, 2009 at 8:24 PM, Stewart Smith <stewart@...> wrote:
> The second and third printf calls here get a valgrind warning.
>
> First printf:
> ==18960== Use of uninitialised value of size 8

> ==18960== Conditional jump or move depends on uninitialised value(s)

Valgrind diagnoses places where uninitialized data is used in some way
that could have a side effect or alter the control flow.

Newer versions of Valgrind have an option that you should use:

--track-origins

Just like Valgrind tracks the origins of which call stack allocated
some misused memory, it also tracks the origin of some uninitialized
value. This could help you quickly find the answer.

It's possible that the uninitialized value originated quite far away
from where it is manifested.

Valgrind doesn't show uninitialized uses right at the origin because
that would lead to false
positives. For instance, structures have gaps in them which are left
uninitialized sometimes.
Or what if you are using unions?

union u { char big_array[256]; short little_int; }

If you make an instance of u, and initialize the ``little_int''
member, that leaves most of the big_array space uninitialized (perhaps
254 bytes out of 256). You can assign one such union to another; that
is well-defined C code:

union u a, b;
a.little_int = 42;

b = a; /* b.little_int is 42 now, perfectly valid */

So at this line b = a, a whole lot of uninitialized bits get copied.
We don't want valgrind to be bothering us with that. But the
``undefinedness'' of those bits gets copied along with them.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Valgrind-users mailing list
Valgrind-users@...
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: Possible false positive/bug in memcheck

2009-11-26T21:08:18Z

On Thu, Nov 26, 2009 at 8:24 PM, Stewart Smith <stewart@...> wrote:

> I have the following code snippet
>
> char nf= *null_flags;
> char r1nf= *(null_flags + s->rec_buff_length);
> int eq= nf==r1nf;
> fprintf(stderr, "man compare: %x\n", eq);
>
> fprintf(stderr, "byte compare: %d\n",
> (char)((char)*(char*)(null_flags)) == (char)(*(char*)(null_flags +
> s->rec_buff_length)));

...

Please post a compilable minimal test case, it's hard to
guess without seeing that.
- Dan

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Valgrind-users mailing list
Valgrind-users@...
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Possible false positive/bug in memcheck

2009-11-26T20:24:57Z

Hi!

I have the following code snippet

char nf= *null_flags;
char r1nf= *(null_flags + s->rec_buff_length);
int eq= nf==r1nf;
fprintf(stderr, "man compare: %x\n", eq);

fprintf(stderr, "byte compare: %d\n",
(char)((char)*(char*)(null_flags)) == (char)(*(char*)(null_flags +
s->rec_buff_length)));
fprintf(stderr, "memcmp compare: %d\n", memcmp(null_flags ,
null_flags + s->rec_buff_length, 1));

Where the first printf (and the code leading to it) runs fine. No
problem at all.

The second and third printf calls here get a valgrind warning.

First printf:
==18960== Use of uninitialised value of size 8
==18960== at 0x792485B: _itoa_word (_itoa.c:195)
==18960== by 0x7926474: vfprintf (vfprintf.c:1600)
==18960== by 0x792A19F: buffered_vfprintf (vfprintf.c:2241)
==18960== by 0x7924FAD: vfprintf (vfprintf.c:1306)
==18960== by 0x792FB47: fprintf (fprintf.c:33)
==18960== by 0x5C3953: Table::compare_record() (table.cc:3522)
==18960== by 0x55CAFC: write_record(Session*, Table*,
st_copy_info*) (sql_insert.cc:846)

==18960== Conditional jump or move depends on uninitialised value(s)
==18960== at 0x7924865: _itoa_word (_itoa.c:195)
==18960== by 0x7926474: vfprintf (vfprintf.c:1600)
==18960== by 0x792A19F: buffered_vfprintf (vfprintf.c:2241)
==18960== by 0x7924FAD: vfprintf (vfprintf.c:1306)
==18960== by 0x792FB47: fprintf (fprintf.c:33)
==18960== by 0x5C3953: Table::compare_record() (table.cc:3522)

And the second in the memcmp() call (which if i copy the valgrind
implementation in, it gets the warning on the if(res) line of it:

res = ((int)a0) - ((int)b0); \
-->> if (res != 0) \
return res; \

I've disassembled both parts, and it looks correct (although perhaps
I'm wrong, help welcome)

leading up to first printf:

90 nop
48 8b 45 d8 mov -0x28(%rbp),%rax
48 8b 80 e0 00 00 00 mov 0xe0(%rax),%rax
0f b6 00 movzbl (%rax),%eax
88 45 ff mov %al,-0x1(%rbp)
48 8b 45 d8 mov -0x28(%rbp),%rax
48 8b 90 e0 00 00 00 mov 0xe0(%rax),%rdx
48 8b 45 d8 mov -0x28(%rbp),%rax
48 8b 00 mov (%rax),%rax
8b 80 24 02 00 00 mov 0x224(%rax),%eax
89 c0 mov %eax,%eax
48 8d 04 02 lea (%rdx,%rax,1),%rax
0f b6 00 movzbl (%rax),%eax
88 45 fe mov %al,-0x2(%rbp)
0f b6 45 ff movzbl -0x1(%rbp),%eax
3a 45 fe cmp -0x2(%rbp),%al
0f 94 c0 sete %al
0f b6 c0 movzbl %al,%eax
89 45 f0 mov %eax,-0x10(%rbp)
48 8b 05 ef 6b 62 00 mov 0x626bef(%rip),%rax # bf86f8 <stderr>
8b 55 f0 mov -0x10(%rbp),%edx
be d5 d1 8b 00 mov $0x8bd1d5,%esi
48 89 c7 mov %rax,%rdi
b8 00 00 00 00 mov $0x0,%eax
e8 12 10 42 00 callq 9f2b30 <fprintf@plt>

for the 2nd:
48 8b 45 d8 mov -0x28(%rbp),%rax
48 8b 80 e0 00 00 00 mov 0xe0(%rax),%rax
0f b6 10 movzbl (%rax),%edx
48 8b 45 d8 mov -0x28(%rbp),%rax
48 8b 80 98 00 00 00 mov 0x98(%rax),%rax
0f b6 00 movzbl (%rax),%eax
38 c2 cmp %al,%dl
0f 94 c0 sete %al
0f b6 d0 movzbl %al,%edx
48 8b 05 ae 6b 62 00 mov 0x626bae(%rip),%rax # bf86f8 <stderr>
be e6 d1 8b 00 mov $0x8bd1e6,%esi
48 89 c7 mov %rax,%rdi
b8 00 00 00 00 mov $0x0,%eax
e8 d4 0f 42 00 callq 9f2b30 <fprintf@plt>

So I'm a bit stuck... at first I thought we could in fact have
unitialized data... but doing the manual compare there (the first one)
and not getting a warning as well as inspecting the code and memory
contents for sanity, I'm quite stuck.

There has been no difference between gcc 4.3 and 4.4 nor between
valgrind 3.5 and trunk.

Does anybody have any ideas on what I can look at next? or tips on
debugging valgrind? perhaps tracking back as to exactly which operand
to what instruction it's complaining about? or if can get it to warn earlier?

--
Stewart Smith

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Valgrind-users mailing list
Valgrind-users@...
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Leak checking: how to inform Valgrind about internal pointers?

2009-11-26T11:42:57Z

Hi All,

What is the best way to use the Valgrind (3.5.0) API to inform the tool of the
situation that although some objects are reachable only by interior pointers,
this is not an accident, and they are not actually leaked?

I have such a situation: the program maintains a pointer to some objects,
knowing that the true start is at a fixed displacement before that.

There is an associated header structure which holds this interior
pointer. I do have spare room in the header to add a pointer to the
true start of the object (which can be conditionally defined,
initialized, and maintained in sync, if Valgrind support is
enabled at compile time).

Is there another way?

Ideally there would be something like ``For this piece of memory, if
there are live pointers to any of the bytes 0...N, it is considered
reachable''.

Cheers ...

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Valgrind-users mailing list
Valgrind-users@...
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: Fwd: make dist-bzip2 fails while attempting to load docbook.xsl

2009-11-25T23:09:10Z

On Tue, Nov 24, 2009 at 9:38 PM, Erez Zilber <erezzi.list@...> wrote:
> Actually, all I want is to generate a rpm. I thought that I need to
> run make dist-bzip2 for that. Am I right?

Generating a Valgrind RPM involves generating the manual in PDF
format. So you will need to make sure that the PDF can be generated if
you want to build the RPM.

Bart.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Valgrind-users mailing list
Valgrind-users@...
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: xml output escaping ampersand

2009-11-25T21:51:13Z

Thanks Julian, the following is the testcase.

valgrind --xml=yes --xml-file=ls.xml ls '&' '>'

Thanks,
Madhan.

On Tue, Nov 24, 2009 at 3:30 PM, Julian Seward <jseward@...> wrote:

>
> Easy enough to fix. Can you send a small test program and commands to
> show the problem, so I can test the fix?
>
> J
>
> On Tuesday 24 November 2009, Madhan Sadasivam wrote:
>> Hello,
>>
>> An ampersand (&) character when found in the command line arguments of
>> an application,
>> is not encoded into an xml safe form (&) when xml output is enabled.
>>
>> The same characters are encoded properly in the "args" section,
>> but appear as-is in the "preample" section.
>>
>> Please refer to the xml snippet below for an example.
>> This causes a parse failure with standard xml parsers.
>>
>> Thanks,
>> Madhan.
>>
>>
>> <preamble>
>> <line>Memcheck, a memory error detector</line>
>> <line>Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et
>> al.</line> <line>Using Valgrind-3.5.0 and LibVEX; rerun with -h for
>> copyright info</line> <line>Command: ./a && & \></line>
>> </preamble>
>>
>> <pid>5546</pid>
>> <ppid>15439</ppid>
>> <tool>memcheck</tool>
>>
>> <args>
>> <vargv>
>> <exe>/usr/local/bin/valgrind</exe>
>> <arg>--xml=yes</arg>
>> <arg>--xml-file=abc</arg>
>> </vargv>
>> <argv>
>> <exe>./a</exe>
>> <arg>&&</arg>
>> <arg>&</arg>
>> <arg>></arg>
>> </argv>
>> </args>
>>
>> ---------------------------------------------------------------------------
>>--- Let Crystal Reports handle the reporting - Free Crystal Reports 2008
>> 30-Day trial. Simplify your report design, integration and deployment - and
>> focus on what you do best, core application coding. Discover what's new
>> with Crystal Reports now. http://p.sf.net/sfu/bobj-july
>> _______________________________________________
>> Valgrind-users mailing list
>> Valgrind-users@...
>> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>
>
>

Re: Fwd: make dist-bzip2 fails while attempting to load docbook.xsl

2009-11-24T12:38:53Z

On Tue, Nov 24, 2009 at 10:16 PM, Bart Van Assche
<bart.vanassche@...> wrote:

> On Tue, Nov 24, 2009 at 8:29 PM, Erez Zilber <erezzi.list@...> wrote:
>> On Tue, Nov 24, 2009 at 8:52 PM, Bart Van Assche
>> <bart.vanassche@...> wrote:
>>> On Tue, Nov 24, 2009 at 7:30 PM, Erez Zilber <erezzi.list@...> wrote:
>>>> I/O error : Attempt to load network entity
>>>> http://docbook.sourceforge.net/release/xsl/current/fo/docbook.xsl
>>>
>>> Hello Erez,
>>>
>>> Have you already had a look at the file docs/README ? It lists the
>>> packages that must be installed before documentation generation works.
>>> The following bug report might also be interesting to you (not sure
>>> it's still up to date): https://bugs.kde.org/show_bug.cgi?id=162121.
>>>
>>> Bart.
>>>
>>
>> I read docs/README and was able to make some progress. However, I'm
>> still looking for the pdfxmltex & pdftops packages for CentOS 5. Do
>> you know if they are available (as RPMs)? Maybe I'm looking for the
>> wrong package name?
>>
>> I'm currently failing here:
>> [ ... ]
>
> It is a known issue that PDF generation fails on most systems except
> openSUSE 10.1 (see also
> http://article.gmane.org/gmane.comp.debugging.valgrind.devel/876). Do
> you really need the PDF docs ? The following command will generate the
> HTML files that have been published on the Valgrind website:
>
> make -C docs html-docs
>
> Bart.
>

Actually, all I want is to generate a rpm. I thought that I need to
run make dist-bzip2 for that. Am I right?

Erez

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Valgrind-users mailing list
Valgrind-users@...
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: Fwd: make dist-bzip2 fails while attempting to load docbook.xsl

2009-11-24T12:16:36Z

On Tue, Nov 24, 2009 at 8:29 PM, Erez Zilber <erezzi.list@...> wrote:

> On Tue, Nov 24, 2009 at 8:52 PM, Bart Van Assche
> <bart.vanassche@...> wrote:
>> On Tue, Nov 24, 2009 at 7:30 PM, Erez Zilber <erezzi.list@...> wrote:
>>> I/O error : Attempt to load network entity
>>> http://docbook.sourceforge.net/release/xsl/current/fo/docbook.xsl
>>
>> Hello Erez,
>>
>> Have you already had a look at the file docs/README ? It lists the
>> packages that must be installed before documentation generation works.
>> The following bug report might also be interesting to you (not sure
>> it's still up to date): https://bugs.kde.org/show_bug.cgi?id=162121.
>>
>> Bart.
>>
>
> I read docs/README and was able to make some progress. However, I'm
> still looking for the pdfxmltex & pdftops packages for CentOS 5. Do
> you know if they are available (as RPMs)? Maybe I'm looking for the
> wrong package name?
>
> I'm currently failing here:
> [ ... ]

It is a known issue that PDF generation fails on most systems except
openSUSE 10.1 (see also
http://article.gmane.org/gmane.comp.debugging.valgrind.devel/876). Do
you really need the PDF docs ? The following command will generate the
HTML files that have been published on the Valgrind website:

make -C docs html-docs

Bart.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Valgrind-users mailing list
Valgrind-users@...
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: Fwd: make dist-bzip2 fails while attempting to load docbook.xsl

2009-11-24T11:29:46Z

On Tue, Nov 24, 2009 at 8:52 PM, Bart Van Assche
<bart.vanassche@...> wrote:

> On Tue, Nov 24, 2009 at 7:30 PM, Erez Zilber <erezzi.list@...> wrote:
>> I/O error : Attempt to load network entity
>> http://docbook.sourceforge.net/release/xsl/current/fo/docbook.xsl
>
> Hello Erez,
>
> Have you already had a look at the file docs/README ? It lists the
> packages that must be installed before documentation generation works.
> The following bug report might also be interesting to you (not sure
> it's still up to date): https://bugs.kde.org/show_bug.cgi?id=162121.
>
> Bart.
>

I read docs/README and was able to make some progress. However, I'm
still looking for the pdfxmltex & pdftops packages for CentOS 5. Do
you know if they are available (as RPMs)? Maybe I'm looking for the
wrong package name?

I'm currently failing here:

Writing license.gfdl.html for chapter(license.gfdl)
Writing licenses.html for book(licenses)
Writing index.html for set(set-index)
for x in /usr/share/xml/docbook/stylesheet/nwalsh/current/manpages/docbook.xsl
/usr/share/xml/docbook/stylesheet/nwalsh/manpages/docbook.xsl
/usr/share/sgml/docbook/xsl-stylesheets-1.69.1-5.1/manpages/docbook.xsl
; do \
if test -f $x; then \
echo "Using manpage stylesheet: $x"; \
export XML_CATALOG_FILES=/etc/xml/catalog && \
xsltproc --nonet --xinclude -o ./ $x
../docs/xml/manpages-index.xml; \
exit 0; \
fi; \
done; \
echo ""; \
echo "Error: I can't find the XSL_MAN_STYLE file"; \
echo "Please check where it lives on your system, and" \
"amend the line 'XSL_MAN_STYLES = ' in this Makefile."; \
exit 1;
Using manpage stylesheet:
/usr/share/sgml/docbook/xsl-stylesheets-1.69.1-5.1/manpages/docbook.xsl
Error: no ID for constraint linkend: manual-core.comment.
Writing valgrind.1 for refentry(valgrind)
Writing cg_annotate.1 for refentry(cg_annotate)
Writing callgrind_annotate.1 for refentry(callgrind-annotate)
Writing callgrind_control.1 for refentry(callgrind-control)
Writing ms_print.1 for refentry(ms_print)
Generating PDF file: ../docs/print/index.pdf (please be patient)...
export XML_CATALOG_FILES=/etc/xml/catalog && \
mkdir -p ../docs/print && \
mkdir -p ../docs/print/images && \
xsltproc --nonet --xinclude -o ../docs/print/index.fo
../docs/lib/vg-fo.xsl ../docs/xml/index.xml && \
(cd ../docs/print && \
( pdfxmltex index.fo && \
pdfxmltex index.fo && \
pdfxmltex index.fo ) &> print.log < /dev/null && \
echo "Generating PS file: ../docs/print/index.ps ..." && \
pdftops index.pdf && \
rm -f *.log *.aux *.fo *.out)
Making portrait pages on USletter paper (8.5inx11in)
make[2]: *** [print-docs] Error 127
make[2]: Leaving directory `/home1/erez.zilber/work/tmp/vlg/valgrind-3.5.0/docs'
make[1]: *** [distdir] Error 2
make[1]: Leaving directory `/home1/erez.zilber/work/tmp/vlg/valgrind-3.5.0/docs'
make: *** [distdir] Error 1

Thanks,
Erez

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Valgrind-users mailing list
Valgrind-users@...
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: Fwd: make dist-bzip2 fails while attempting to load docbook.xsl

2009-11-24T10:52:25Z

On Tue, Nov 24, 2009 at 7:30 PM, Erez Zilber <erezzi.list@...> wrote:
> I/O error : Attempt to load network entity
> http://docbook.sourceforge.net/release/xsl/current/fo/docbook.xsl

Hello Erez,

Have you already had a look at the file docs/README ? It lists the
packages that must be installed before documentation generation works.
The following bug report might also be interesting to you (not sure
it's still up to date): https://bugs.kde.org/show_bug.cgi?id=162121.

Bart.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Valgrind-users mailing list
Valgrind-users@...
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Fwd: make dist-bzip2 fails while attempting to load docbook.xsl

2009-11-24T10:30:08Z

Hi,

I've asked the question below in the valgrind-developers list, but
maybe asking it here is a better idea. Can anyone help?

Thanks,
Erez

---------- Forwarded message ----------
From: Erez Zilber <erezzi.list@...>
Date: Sun, Nov 22, 2009 at 11:01 AM
Subject: make dist-bzip2 fails while attempting to load docbook.xsl
To: valgrind-developers@...

Hi,

I'm trying to run 'make dist-bzip2' (using v3.5.0) and I got the
following error:

...
make[1]: Entering directory
`/home1/erez.zilber/work/tmp/vlg/valgrind-3.5.0/tests'
mkdir -p -- /home1/erez.zilber/work/tmp/vlg/valgrind-3.5.0/valgrind-3.5.0/tests/..
make[1]: Leaving directory
`/home1/erez.zilber/work/tmp/vlg/valgrind-3.5.0/tests'
make[1]: Entering directory
`/home1/erez.zilber/work/tmp/vlg/valgrind-3.5.0/perf'
mkdir -p -- /home1/erez.zilber/work/tmp/vlg/valgrind-3.5.0/valgrind-3.5.0/perf/..
make[1]: Leaving directory
`/home1/erez.zilber/work/tmp/vlg/valgrind-3.5.0/perf'
make[1]: Entering directory
`/home1/erez.zilber/work/tmp/vlg/valgrind-3.5.0/auxprogs'
mkdir -p -- /home1/erez.zilber/work/tmp/vlg/valgrind-3.5.0/valgrind-3.5.0/auxprogs/..
make[1]: Leaving directory
`/home1/erez.zilber/work/tmp/vlg/valgrind-3.5.0/auxprogs'
make[1]: Entering directory
`/home1/erez.zilber/work/tmp/vlg/valgrind-3.5.0/mpi'
mkdir -p -- /home1/erez.zilber/work/tmp/vlg/valgrind-3.5.0/valgrind-3.5.0/mpi/..
make[1]: Leaving directory
`/home1/erez.zilber/work/tmp/vlg/valgrind-3.5.0/mpi'
make[1]: Entering directory
`/home1/erez.zilber/work/tmp/vlg/valgrind-3.5.0/docs'
mkdir -p -- /home1/erez.zilber/work/tmp/vlg/valgrind-3.5.0/valgrind-3.5.0/docs/images
/home1/erez.zilber/work/tmp/vlg/valgrind-3.5.0/valgrind-3.5.0/docs/internals
/home1/erez.zilber/work/tmp/vlg/valgrind-3.5.0/valgrind-3.5.0/docs/lib
/home1/erez.zilber/work/tmp/vlg/valgrind-3.5.0/valgrind-3.5.0/docs/xml
make \
top_distdir="/home1/erez.zilber/work/tmp/vlg/valgrind-3.5.0/valgrind-3.5.0"
distdir="/home1/erez.zilber/work/tmp/vlg/valgrind-3.5.0/valgrind-3.5.0/docs"
\
dist-hook
make[2]: Entering directory
`/home1/erez.zilber/work/tmp/vlg/valgrind-3.5.0/docs'
Generating the text version of the FAQ ...
export XML_CATALOG_FILES=/etc/xml/catalog && \
xsltproc --nonet --xinclude -o ./FAQ.txt
../docs/lib/vg-faq2txt.xsl ../docs/xml/FAQ.xml
I/O error : Attempt to load network entity
http://docbook.sourceforge.net/release/xsl/current/fo/docbook.xsl
warning: failed to load external entity
"http://docbook.sourceforge.net/release/xsl/current/fo/docbook.xsl"
compilation error: file ../docs/lib/vg-faq2txt.xsl line 10 element
import
xsl:import : unable to load
http://docbook.sourceforge.net/release/xsl/current/fo/docbook.xsl
make[2]: *** [FAQ.txt] Error 5
make[2]: Leaving directory
`/home1/erez.zilber/work/tmp/vlg/valgrind-3.5.0/docs'
make[1]: *** [distdir] Error 2
make[1]: Leaving directory
`/home1/erez.zilber/work/tmp/vlg/valgrind-3.5.0/docs'
make: *** [distdir] Error 1

I tried the following:

[erez.zilber@kpc39:~/work/tmp/vlg/valgrind-3.5.0]$ wget
http://docbook.sourceforge.net/release/xsl/current/fo/docbook.xsl
--18:17:34-- http://docbook.sourceforge.net/release/xsl/current/fo/docbook.xsl
Resolving docbook.sourceforge.net... 216.34.181.96
Connecting to docbook.sourceforge.net|216.34.181.96|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 12666 (12K) [text/xml]
Saving to: `docbook.xsl'

100%[=====================================================================================>]
12,666 22.9K/s in 0.5s

18:17:37 (22.9 KB/s) - `docbook.xsl' saved [12666/12666]

and it seems to work. What is wrong here?

Thanks,
Erez

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Valgrind-users mailing list
Valgrind-users@...
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: xml output escaping ampersand

2009-11-24T01:48:33Z

Easy enough to fix. Can you send a small test program and commands to
show the problem, so I can test the fix?

J

On Tuesday 24 November 2009, Madhan Sadasivam wrote:

> Hello,
>
> An ampersand (&) character when found in the command line arguments of
> an application,
> is not encoded into an xml safe form (&) when xml output is enabled.
>
> The same characters are encoded properly in the "args" section,
> but appear as-is in the "preample" section.
>
> Please refer to the xml snippet below for an example.
> This causes a parse failure with standard xml parsers.
>
> Thanks,
> Madhan.
>
>
> <preamble>
> <line>Memcheck, a memory error detector</line>
> <line>Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et
> al.</line> <line>Using Valgrind-3.5.0 and LibVEX; rerun with -h for
> copyright info</line> <line>Command: ./a && & \></line>
> </preamble>
>
> <pid>5546</pid>
> <ppid>15439</ppid>
> <tool>memcheck</tool>
>
> <args>
> <vargv>
> <exe>/usr/local/bin/valgrind</exe>
> <arg>--xml=yes</arg>
> <arg>--xml-file=abc</arg>
> </vargv>
> <argv>
> <exe>./a</exe>
> <arg>&&</arg>
> <arg>&</arg>
> <arg>></arg>
> </argv>
> </args>
>
> ---------------------------------------------------------------------------
>--- Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> 30-Day trial. Simplify your report design, integration and deployment - and
> focus on what you do best, core application coding. Discover what's new
> with Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Valgrind-users mailing list
> Valgrind-users@...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users

xml output escaping ampersand

2009-11-24T01:37:00Z

Hello,

An ampersand (&) character when found in the command line arguments of
an application,
is not encoded into an xml safe form (&) when xml output is enabled.

The same characters are encoded properly in the "args" section,
but appear as-is in the "preample" section.

Please refer to the xml snippet below for an example.
This causes a parse failure with standard xml parsers.

Thanks,
Madhan.

<preamble>
<line>Memcheck, a memory error detector</line>
<line>Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.</line>
<line>Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info</line>
<line>Command: ./a && & \></line>
</preamble>

<pid>5546</pid>
<ppid>15439</ppid>
<tool>memcheck</tool>

<args>
<vargv>
<exe>/usr/local/bin/valgrind</exe>
<arg>--xml=yes</arg>
<arg>--xml-file=abc</arg>
</vargv>
<argv>
<exe>./a</exe>
<arg>&&</arg>
<arg>&</arg>
<arg>></arg>
</argv>
</args>

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Valgrind-users mailing list
Valgrind-users@...
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: bug in my openmp code or in drd?

2009-11-23T11:02:38Z

On Mon, Nov 23, 2009 at 7:33 PM, Brian J. Miller <miller125@...> wrote:
> I'm testing an array reduction routine with drd and got some surprising
> errors reported. I'm compiling with g++-4.4.2 (built locally following
> directions on the valgrind website regarding futex and using valgrind-3.5.0

Where has the locally built g++-4.4.2 been installed ? libgomp
triggers several conflicting accesses when being used, which are
probably safe (I do not know about a formal correctness proof). The
following suppression pattern is present in glibc-2.X-drd.supp to make
sure that the internal libgomp races are not reported:

{
drd-libgomp
drd:ConflictingAccess
obj:/usr/lib*/libgomp.so*
}

The above suppression pattern will only work when libgomp has been
installed in /usr, and has to be updated when libgomp has been
installed in another location.

Bart.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Valgrind-users mailing list
Valgrind-users@...
https://lists.sourceforge.net/lists/listinfo/valgrind-users

bug in my openmp code or in drd?

2009-11-23T10:33:23Z

Hi,

I'm testing an array reduction routine with drd and got some surprising
errors reported. I'm compiling with g++-4.4.2 (built locally following
directions on the valgrind website regarding futex and using valgrind-3.5.0
This test case illustrates the problem:

#include <stdio.h>
#include <omp.h>
int main(){

#pragma omp parallel
{
#pragma omp barrier
}//end of parallel section

return 0;
}

[bmiller@alastor5 CriticalSectionTest]$ valgrind --tool=drd ./test3
==24220== drd, a thread error detector
==24220== Copyright (C) 2006-2009, and GNU GPL'd, by Bart Van Assche.
==24220== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==24220== Command: ./test3
==24220==
==24220== Conflicting store by thread 1 at 0x05f5c11c size 4
==24220== at 0x53C93FD: gomp_team_barrier_wait (bar.h:66)
==24220== by 0x53C80FE: gomp_team_end (team.c:464)
==24220== by 0x4006E8: main (test3.cc:7)
==24220== Address 0x5f5c11c is at offset 236 from 0x5f5c030. Allocation
context:
==24220== at 0x4C230D7: malloc (vg_replace_malloc.c:195)
==24220== by 0x53C38D8: gomp_malloc (alloc.c:36)
==24220== by 0x53C87CC: gomp_new_team (team.c:144)
==24220== by 0x53C72DB: GOMP_parallel_start (parallel.c:108)
==24220== by 0x4006D9: main (test3.cc:7)
==24220== Other segment start (thread 2)
==24220== at 0x4C2A7CD: sem_wait (drd_pthread_intercepts.c:1003)
==24220== by 0x53C909B: gomp_sem_wait (sem.c:120)
==24220== by 0x53C935C: gomp_team_barrier_wait_end (bar.c:146)
==24220== by 0x4006BC: main.omp_fn.0 (test3.cc:15)
==24220== by 0x53C8037: gomp_thread_start (team.c:115)
==24220== by 0x4C2E3B4: vgDrd_thread_wrapper
(drd_pthread_intercepts.c:272)
==24220== by 0x57E8366: start_thread (pthread_create.c:297)
==24220== by 0x5AD00AC: clone (in /lib64/libc-2.5.so)
==24220== Other segment end (thread 2)
==24220== at 0x57EEE74: __lll_lock_wait (in /lib64/libpthread-2.5.so)
==24220== by 0x57EA873: _L_lock_106 (pthread_mutex_lock.c:251)
==24220== by 0x57EA2DE: pthread_mutex_lock (pthread_mutex_lock.c:86)
==24220== by 0x4C24F51: pthread_mutex_lock (drd_pthread_intercepts.c:579)
==24220== by 0x53C93E8: gomp_team_barrier_wait (mutex.h:44)
==24220== by 0x53C8043: gomp_thread_start (team.c:116)
==24220== by 0x4C2E3B4: vgDrd_thread_wrapper
(drd_pthread_intercepts.c:272)
==24220== by 0x57E8366: start_thread (pthread_create.c:297)
==24220== by 0x5AD00AC: clone (in /lib64/libc-2.5.so)
==24220==
==24220==
==24220== For counts of detected and suppressed errors, rerun with: -v
==24220== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 19 from 18)
[bmiller@alastor5 CriticalSectionTest]$ echo $OMP_NUM_THREADS
3

--
________________________________________________________________________
Brian Miller, L-556
Center for Applied Scientific Computing (CASC)
Lawrence Livermore National Lab (LLNL) Email: miller125@...
P.O. Box 808, 7000 East Ave. Phone: (925)424-4773
Livermore, CA 94551 Fax: (925)422-9429
________________________________________________________________________

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Valgrind-users mailing list
Valgrind-users@...
https://lists.sourceforge.net/lists/listinfo/valgrind-users