Sometimes these crude techniques (not using valgrind) work well enough anyway.
Typically the overhead is a few percent or less.
1) # http://udrepper.livejournal.com/11429.html
export MALLOC_PERTURB_=$(($RANDOM % 255 + 1))
echo 1>&2 MALLOC_PERTURB_=$MALLOC_PERTURB_ " # $HOME/.bash_profile"
>I encounter a problem of running Apache httpd server using Valgrind.
> Valgrind seems to decrease the performance of Apache server too much that
> the client always report a timeout error. I am also not sure if I used the
> correct command line option. I just type "Valgrind --tool=xxx ./httpd
On 05/31/2012 07:10 PM, ?? wrote:
> I try to use Valgrind to wrap some functions in target sotfwares such as
> php, libtiff. But i found that valgrind will slow down them significantly(up
> to 25 times slowwer), even if run valgrind with '--tool=none'. And as
> described in valgrind mannual
> Please help me diagnose the following configure error on a x86_64/Linux
> system.
The error happens because the logic in ./configure does not like "gcc4" as the
name of the compiler. The logic confuses the trailing '4' as part of the
numerical version "4.6.0". But there is no dot '.' after th
On 05/05/2012 07:22 AM, Philippe Waroquiers wrote:
> On Fri, 2012-05-04 at 17:32 +, Oliver Schneider wrote:
>> I've got a question about Valgrind and its Memcheck tool. Is it possible
>> to take a snapshot of a program under Valgrind, kinda similar to the way
>> a fork() clones the process spa
> *Is there the **possibility**to **choose**what tool to **install**?*
In the top-level Makefile you can name which tools you want.
Just edit these two lists, deleting the entries that you do not want:
-
TOOLS = memcheck \
cachegrind \
callgrind \
> Can you point me towards how to get you the information you require?
It's a *BUG* in valgrind that valgrind does not print the bytes [or words, etc.]
of the instruction stream that valgrind does not understand.
[This is immediately obvious to *EVERY* user, but so far the developers
have been ob
>> ==3898== Memcheck, a memory error detector
>> ==3898== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
>> ==3898== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
>> ==3898== Command: ./mkvariable_key
[snip]
>> ==3898== Conditional jump or move depends on unin
> export CFLAGS="-mcpu=arm926ej-s -I/opt/lemonix/cdt/arm-linux-gnueabi/include"
> export LDFLAGS="-L/opt/lemonix/cdt/arm-linux-gnueabi/lib"
>
> export CROSS_COMPILE=/opt/lemonix/cdt/bin/arm-linux-
>
> export CC=${CROSS_COMPILE}gcc
> export CPP=${CROSS_COMPILE}cpp
> export CXX=${CROSS_COMPILE}g++
> /usr/local/netd_tools_v1/arm/bin/armv5b-softfloat-linux-gnu-gcc ... -marm
> -mcpu=cortex-a8 ...
> cc1: error: bad value (cortex-a8) for -mcpu= switch
That compiler does not understand the cortex-a8 CPU.
Either get a compiler which does understand cortex-a8,
or try omitting the specification o
> make[2]: Entering directory
> `/home/ssunil/valgrind-3.6.0/valgrind-3.6.0/coregrind'
Why aren't you using valgrind-3.7.0 which was released on 5 November 2011?
http://valgrind.org/downloads/current.html
--
--
Better
> I am trying to profile my multi threaded application using Valgrind i have
> aome questions
>
> 1:- I can use valgrind on a Target (ARM)
armv7 is the official minimum hardware requirement,
although patches are available for running memcheck on armv5tel.
[The patches are being ignored. You ca
> vex amd64->IR: unhandled instruction bytes: 0xC5 0xFB 0x10 0x44 0x24 0xF8
> 0xC3 0x90
> ==17934== valgrind: Unrecognised instruction at address 0x560cf43.
> ==17934==at 0x560CF43: __mpn_construct_double (in /lib64/libc-2.14.1.so)
> ==17934==by 0x56056D3: strtod_l_internal (in /lib64/
>> vex x86->IR: unhandled instruction bytes: 0x66 0xF 0x3A 0x16
> That's "PEXTRD r/m32, xmm2, Ib" ...
Perhaps just copy the relevant lines
from VEX/priv/guest_amd64_toIR.c
to VEX/priv/guest_x86_toIR.c
--
--
Keep
> vex x86->IR: unhandled instruction bytes: 0x66 0xF 0x3A 0x16
> ==18426==at 0x804BE18: manhattan(unsigned char const*, unsigned char
> const*) (emmintrin.h:208)
That's "PEXTRD r/m32, xmm2, Ib" which extracts a 32-bit wide, 32-bit aligned,
known-in-advance slice from xmm2, then places the sl
> I'm having an issue with valgrind - mine regression takes 4 hours instead
> of 45 mins when run in valgrind.
An elapsed time ratio of 240:45 (5.3 : 1) is not unusual, and may be better
than average.
> I would like to keep my set of regression
> tests untouched
> --2990-- Considering /usr/lib/mylib.so.debug ..
> --2990-- .. CRC is valid
>
> The above statements are the last 2 statements of the whole output. Valgrind
> gets stuck here everytime ...
> The valgrind version is: *valgrind-3.6.1*
> and the Linux OS is based off of: *montavista*
You hav
> ... apache2 server itself create process for my fastcgi application
> [which I want to run under valgrind] ...
"Wrap" the fastcgi application inside a shell script which invokes valgrind
on the app. Tell apache2 server to invoke that shell script instead of
invoking the fastcgi app directly.
-
> https://bugs.kde.org/show_bug.cgi?id=294285
> 1) Am I correct that this is a bug?
It seems to me that there may be at least one set of cases where
the memcheck complaint might be correct, namely if there is no '\0'
in an allocated block whose length is not a multiple of 16.
[Example: blk = mall
> Hello. I downloaded the development version of valgrind from
> Subversion today.
Thank you for mentioning the version of valgrind!
> It configured and built fine, but while trying to
> run it on my application, I got this error during the run:
>
> vex amd64->IR: unhandled
On 02/09/2012 03:50 AM, Istvan Csanady wrote:
> vex amd64->IR: unhandled instruction bytes: 0x66 0xF 0x3A 0xDF 0xD1 0x1 0xE8
> 0x6A
> Any help is greatly appreciated.
Such as, RTFM? It's even a FAQ!!
Begin at http://valgrind.org . Notice "Documentation" in the sidebar.
Click on "FAQ". http
On 01/26/2012 08:49 AM, David Henningsson wrote:
> In the call to POST(sys_ioctl), ARG2 is a 64 bit value, which for every
> call except mine had the upper 32 bits set to zero. For my particular
> call, ARG2 was set to 0xC008551A, so it would not match my ioctl
> of C008551A in the follo
On 01/23/2012 01:02 PM, Daniel Mierswa wrote:
> On 23.01.2012 21:46, John Reiser wrote:
>> and then perhaps do some matching on the low 12 bits (0xFFF) of the address:
>> 0x44143D0 ==> any address ending in 0x3D0.
>0x000143d0 <+880>: vmovd 0x4(%eax),%xmm0
>>
> whenever i want to memcheck a 32bit program on my 64bit system i receive the
> following
> message:
>
> vex x86->IR: unhandled instruction bytes: 0xC5 0xF9 0x6E 0x40
> ==16815== valgrind: Unrecognised instruction at address 0x44143d0.
> ==16815==at 0x44143D0: _dl_sysdep_start (dl-sysdep.c:1
> Are these series bugs?
I suppose you mean "serious bugs", that is, bugs that have
a large impact or must not be ignored.
>
> My code is running fine.
>
> Generally, how many memory leak is really bad?
>
>
> ==407== LEAK SUMMARY:
> ==407==definitely lost: 3,752 bytes in 79 blocks
> ==407
On 01/13/2012 11:07 PM, Sune Ahlgren wrote:
> Thanks for your input.
>
> By adding --track-origins=yes to Memcheck I was able to pin-point the issue.
>
> Valgrind rocks!!!
Other users would appreciate reading what you learned.
Using --track-origins=yes is powerful. The result of
applying that
On 01/13/2012 08:34 PM, Sune Ahlgren wrote:
> I'm writing the following in what will become a TCP client:
>
>>
>
> struct sockaddr_in daemon_addr;
>
>
> /* Connect to localhost */
> daemon_addr.sin_family = AF_INET;
> daemon_addr.sin_port= htons((*conn)-
On 01/08/2012 12:44 AM, Hershkovitz, Koby (Koby) wrote:
> Indeed I have check this patch is correctly in place.
> The relevant strace output is:
> mmap2(0x6229, 1064960, PROT_READ|PROT_WRITE|PROT_EXEC,
> MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, 0, 0) = 0x6229
That mmap2 is OK because the MAP_F
> However, after using callgrind_annotate --auto=yes, there is no information
> for a particular function, say, "foo". The name of "foo" in the assembly is
> "_Z10foo". I checked and evidence show that this function, which is the core
> computational part, should be executed, so there should be
> I’ve managed to build valgrind after patching with 64365,64147,64366,64946
> AND using the following configure:
[[snip]]
>
> ==2776== error 22 Invalid argument
>
> ==2776== error VG_(am_shared_mmap_file_float_valgrind)
> /tmp/vgdb-pipe-shared-mem-vgdb-2776-by-root-on-???
This hints that it
> I'm using Arch Linux and found old bug about strlen and SSE instructions
> among other thing. Also there was some posts about stripped libc and I have:
> $ file /lib/libc-2.14.1.so
> /lib/libc-2.14.1.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV),
> dynamically linked (uses shared l
> * Apply #2.
> * Apply #3 in VEX.
> * Revert coregrind/m_dispatch/dispatch-arm-linux.S.
> * Apply #6.
>
> Is this how you've meant it?
Yes.
> I've tried this on r12305 and was able to build it for arm-linux-gnu.
> Running it on PXA255 under Debian results in an illegal instruction at
> 0x38041f
On 12/12/2011 04:49 AM, Baurzhan Ismagulov wrote:
> On Fri, Dec 09, 2011 at 08:26:38AM -0800, John Reiser wrote:
>>>> The patch is: https://bugs.kde.org/show_bug.cgi?id=276897#c2
> ...
>> Did you look at Comment #3, immediately following (and about 1 hour after)
>>
On 12/09/2011 03:37 AM, Baurzhan Ismagulov wrote:
>> The patch is: https://bugs.kde.org/show_bug.cgi?id=276897#c2
> arm-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../include -I../VEX/pub
> -DVGA_arm=1 -DVGO_linux=1 -DVGP_arm_linux=1 -DVGPV_arm_linux_vanilla=1
> -I../coregrind -DVG_LIBDIR="\
> I wan't to know does valgrind can support armv6 (eg.arm1176)?
The recently-released Valgrind 3.7.0 supports only armv7 and above.
There are patches which provide support for v6 and even for non-
threaded programs on v5. Threaded programs have problems on v5
because v5 lacks the better sync
> I'm trying to use valgrind to debug my program, but I can't seem to get any
> line numbers to display in the output... [snip]
> I've tried compiling with "g++ -O0 -g" ... [snip]
> Any suggestions?
Compile and link the smallest executable which gives a problem.
Apply "gzip -9", then attach both
On 11/26/2011 03:37 AM, Dominic Monroe wrote:
> When setting the locale to C, there is no issue. [snip]
With the current Arch Linux default package glibc-2.14-1 [x86], then memcheck
does not complain for any of the three locales C, en_US.utf-8, and ru_RU.utf-8.
After "pacman --sync glibc" updates
On 11/25/2011 05:56 AM, Dominic Monroe wrote:
> I've been trying to run Valgrind on an application, and found a ridicolous
> amount of false positives. It was suggested to me I should email this list
> with errors. I identified the function setlocale to be "errorneous"
[snip]
> ==23068== I
On 10/19/2011 06:53 PM, Jacob Evans wrote:
>
> I seem to be experiencing problems running Valgrind and java together. I've
> ran the combination across multiple platforms (all x64 on vms and pure
> hardware). Attempting to launch Valgrind of version >=3.5 causes the jvm to
> exit with SSE2 not
On 10/14/2011 08:01 AM, Yeshurun, Meir wrote:
> 1. How do you know that?
By the statistics on downloads of valgrind (as adjusted for typical
multiple-installs-from-one-download), by the statistics on
median {,S}DRAM in x86* machines of any kind (still < 4GB),
by the limits on memory controller dri
> Is it possible to overcome the 32G limit? I don't think machines with more
> memory than that are rare.
Such machines ARE rare. They are fewer than 0.4% (1:250) of the machines
that have _ever_ run memcheck, and that number is already very small.
--
Please re-open bug 282527. The memcheck option --read-var-info=yes
triggers further un-aligned accesses which give bad answers on ARM.
[Yes, I'm running the regression tests.]
I attached another patch to: https://bugs.kde.org/show_bug.cgi?id=282527
--
--
On 08/26/2011 04:32 AM, Ali Günhan Akyürek wrote:
> Thanks for the responses. As far as I understand, currently it's not
> possible to the some limitations.
I've achieved initial success for armv5te: "valgrind /bin/date" runs
on my sheevaplug (1200 BogoMIPS, 512MB RAM) under Debian testing (wheezy
On 09/21/2011 04:13 PM, Tom Hughes wrote:
> On 21/09/11 22:05, Wickham, Mark wrote:
>> I think replacing all of the *(UShort *) and *(UInt *) and *(ULong *)
>> expressions in coregrind/m_debuginfo/readdwarf.c with read_UShort() and
>> friends would solve the problem. I was able to verify that i
> ==483== Process terminating with default action of signal 4 (SIGILL)
> ==483== Illegal opcode at address 0x380AC1A8
> ==483==at 0x4000960: _start (in /lib/ld-uClibc-0.9.30.2.so)
Don't be so lame. Show us the contents of relevant memory!
In this case, the words at 0x380AC1A8 and at 0x400096
> ==8280== Thread 3:
> ==8280== Syscall param read(buf) points to unaddressable byte(s)
> ==8280==at 0x40ABF5B: ??? (syscall-template.S:82)
> ==8280==by 0x40A496D: start_thread (pthread_create.c:300)
> ==8280==by 0x437BA4D: clone (clone.S:130)
> ==8280== Address 0x0 is not stack'd, mal
On 07/21/2011 06:51 PM, CHEN Hong lin wrote:
> The version of the valgrind I used is Release 3.6.1. I downloaded it from
> http://www.valgrind.org/downloads/current.html . I think it is the latest
> version published. Where can I find the upstream snapshot you mentioned?
See http://valgrind.o
> Does it mean that valgrind can not run with NFS mount?
valgrind will run if the pieces are there, and if the pathnames are correct.
Take a look at valgrind on i686 or x86_64. You must replicate that layout,
from the viewpoint of the target.
The output from
strace -e trace=file the/p
On 07/20/2011 12:24 PM, Mudric, Dusan (Dusan) wrote:
> I forgot to mention one more fact. I am using NFS mount.
>
> /etc/fstab:
>
> 47.135.159.188:/exports /exports nfs intr,noauto,nolock 0 0
>
> Here is the "valgrind ls -l" output. If started as NFS mounted, nothing
> happens
On 07/20/2011 10:41 AM, Mudric, Dusan (Dusan) wrote:
> I did something similar. However, "valgrind ls -l" does nothing. It never
> completes this instruction.
"valgrind ls -l" does _something_, if nothing other than "Cannot exec", or
SIGSEGV,
or some other complaint. ("Normal exit" is a [silen
> From the Valgrind site
> (http://www.valgrind.org/docs/manual/manual-core.html#manual-core.whatdoes ),
> it looks like Valgrind can be used on ARMv6 with some limitations.
>
> *2.11. Limitations *
>
> “On ARM, essentially the entire ARMv7-A instruction set is supported, in both
> ARM and Thu
>If it is going to be a significant
> performance hit, maybe it would be better to have an option that can
> turn this on for all syscalls? That way when debugging a fuse
> file-system, the syscalls won't deadlock, but it won't slow things
> down for the general user.
> detecting shared memory regions?
Something like:
strace -o strace.out -e trace=mmap,mmap2,shmget,shmat ./my_app args...
then grep for MAP_SHARED in the mmap* cases, etc.
--
--
Storage Efficiency Calculator
This m
> Is there a reason for assuming that syscalls won't block by default?
There is substantial overhead to allow for the possibility that a syscall
might block. This wakes up valgrind's internal machinery for threads,
which is not spry. chdir and fchdir are used infrequently enough that
it might no
> Is it possible to keep track of inlined functions or instructions that appear
> because of the inlining? Can I get the function which was inlined ?In most
In most cases, inlining loses track of the identity of the function
which has been inlined. However, the line number information for a
give
> Hi! Is there any obvious way to know if the addresses that lackey
> outputs (when --trace-mem=yes) are local to a function or global?
If near the stack pointer, then definitely local.
If not near the stack pointer, then probably not local, but
could be indeterminate, especially for local-but-'st
On 07/11/2011 08:00 AM, Naveen Kumar wrote:
objdump --dwarf /lib/ld-2.2.4.so
>
> John looks like the version of objdump that came with the system does not
> have the --dwarf option. It has a -G(--stabs) for STABS info. Would that be
> sufficient ?
OK, this is older software. (It's always
On 07/11/2011 07:36 AM, Josef Weidendorfer wrote:
> On Monday 11 July 2011, John Reiser wrote:
>> [snip]
>>From my example in my last mail, you can see that a recursive implementation
> can produce the same code as a loop-based one. So you can never say with
> certainty
>
On 07/08/2011 10:54 AM, Josef Weidendorfer wrote:
> On Friday 08 July 2011, John Reiser wrote:
>> <>
> The first thing I must note here is that "callgrind_annotate" is meant
> as fallback solution for people who can/do not want to use a GUI.
> KCachegrind (the G
> [M Rajesh-B22236] Here is /proc/cpuinfo values
> processor : 0
> cpu : e500v2
> clock : 1499.985015MHz
> revision: 3.0 (pvr 8021 0030)
> bogomips: 149.50
>
> total bogomips : 149.50
> timebase: 74999251
> platform: MPC8572 DS
> model
On 07/07/2011 01:53 PM, Naveen Kumar wrote:
>>Run "strace valgrind" and look near the end of the output
>>to see if some system call (that valgrind expects the OS to have)
>>is not implemented. File a bug report; see:
>>http://valgrind.org/support/bug_reports.html
> John I did some digging and
> I tried to use valgrind-3.6.1 memcheck tool for platform ppc32-linux,
>
> I cross compiled(CC=powerpc-none-linux-gnuspe-gcc) on my host(Ubuntu) and
> copied to target board.
What model CPU chip is on your board? What does "cat /proc/cpuinfo" say?
> disInstr(ppc): unhandled instruction: 0x1
On 07/08/2011 05:45 AM, Josef Weidendorfer wrote:
> On Thursday 07 July 2011, John Reiser wrote:
>>> valgrind --tool=callgrind --ct-verbose=1 ...
>>
>> When I run callgrind and callgrind_annotate, then I don't understand
>> the output. For instance, the con
> valgrind --tool=callgrind --ct-verbose=1 ...
When I run callgrind and callgrind_annotate, then I don't understand
the output. For instance, the connection between "73" and the number
of actual dynamic calls to exit() is mysterious to me:
=
$ valgrind --tool=callgrind /bin/date
==3790== Usin
> I have a binary file what i compile it with -g.So i need to perform a
> set of action in my computer and see behavior of my file, This mean , i
> need to see functions of run when i perform those set of actions,
This sounds like some kind of profiling. Re-compile and re-link with
"gcc -p" or "g
> Question: When running a simple fork program I see that syscallno returns it
> as a clone() call syscallno=56 not a fork() syscallno=57.
>
> Does this have to do with the way linux implements fork()? or is this due to
> valgrind?
glibc implements fork() as clone() with some particular parameter
On 06/30/2011 12:06 PM, WAROQUIERS Philippe wrote:
>> Perhaps the best that you can do is modify the custom allocator
>> using something like:
>> -
>> #include
>>
>> if (RUNNING_ON_VALGRIND)
>> *p = 0;
>> else if (*p)
>> *p = 0;
>
> I wonder if the above "
On 06/30/2011 08:34 AM, Szabolcs Nagy wrote:
> hm this is actually in the calloc implementation
> of a libc (musl)
>
> i was testing with statically linked binaries
>
> now i see that with dynamic linking valgrind
> knows calloc semantics (i guess it preloads
> its own calloc)
Yes. valgrind has
> int *alloczero() {
> int *p = malloc(sizeof *p);
>
> if (*p)
> *p = 0;
> return p;
> }
>
> valgrind reports 'conditional jump..'
> at line 'if (*p)', which is correct
> and easy to suppress
>
> but later whereever i read *p i get
> '..uninitialised' value errors
> eventhoug
> 1> Is valgrind capable of assessing software that contains interrupts ?
> (hardware or software interrupts) If so, How to set this up?
It just works, right out-of-the-box.
valgrind is a user-mode program for Linux, and the subject [analyzed]
programs are also user-mode programs for Linux, and "
> I managed to cross-compile valgrind for linux on ppc (MPC8313), but
> failed to run it. Below is the err info caught by strace.
> What's wrong with it? Thanks in advance.
> BTW, the configure options are like:
> configure --host=powerpc-unknown-linux --target=powerpc-unknown-linux
> --pref
On 06/25/2011 11:16 AM, rafael ferraz wrote:
> ==2486== Conditional jump or move depends on uninitialised value(s)
> ==2486==at 0x338C016BD6: index (in /lib64/ld-2.14.so)
> ==2486==by 0x338C007547: expand_dynamic_string_token (in
> /lib64/ld-2.14.so)
> This could be classified as a bug? I
> OS: Redhat 7.1 with gcc-3.0, binutils-2.18.
> This is with valgrind-3.6.1. valgrind 3.2.1 runs fine on same machine
> using same toolchain. FYI I was running valgrind with 'ls'.
> A plain valgrind without any progs actually shows segmentation fault.
Run "strace valgrind" and look near the end
> valgrind: the 'impossible' happened:
>Killed by fatal signal
> ==31001==at 0x38066A08: ??? (in
> /home/elem/local/lib/valgrind/none-x86-linux)
> ==31001==by 0x38066B2B: report_and_quit (m_libcassert.c:225)
> ==31001==by 0x38066CB5: panic (m_libcassert.c:277)
<>
You've probabl
> I tried a similar test case like yours and it works ok. Unfortunately my
> program is extremely large and complicated. In fact I get other errors
> like "conditional jump depends on uninitialized value" but these errors
> exist in another part of the code entirely.
If the other errors include
It's always a good idea to try a small test case that has "the same" behavior.
-
#include
#include
#include
#define PDE_MAT_SIZE1 4
#define PDE_MAT_SIZE2 4
int main()
{
int *rowptr = malloc((PDE_MAT_SIZE2 + 1) * sizeof(int));
printf("rowptr=%p errno=%d\n", rowptr,
> When the program runs by itself, all the malloc calls are successful.
> However when I run it with valgrind's memcheck or massif tools (v
> 3.6.0), a malloc call fails (which is trying to allocate around 6.4 Gb).
Which Linux distribution, which Linux kernel ("uname -a"), and which
C runtime l
> Im having some trouble in my program, but I dont know why. It seems to happen
> before the program execution because before any line of code is executed
> valgrind prints this. Anyone know why this could be happening?
>
Please state which Linux distribution and release version you are running
On 06/10/2011 05:38 AM, Igmar Palsenberg wrote:
>
> On Jun 9, 2011, at 5:04 PM, John Reiser wrote:
>
>>> ==1019== Warning: noted but unhandled ioctl 0xae03 with no size/direction
>>> hints
>>> ==1019==This could cause spurious value e
> ==1019== Warning: noted but unhandled ioctl 0xae03 with no size/direction
> hints
> ==1019==This could cause spurious value errors to appear.
> ==1019==See README_MISSING_SYSCALL_OR_IOCTL for guidance on
> writing a proper wrapper.
The syscall is:
ioctl(fd, 0xae03, ...)
where 'f
On 06/03/2011 11:35 PM, durga prasad wrote:
> I had a test application with a memory leak of 100 bytes.When I run the
> valgrind with the
> test application its not showing the memory leak
Post the source code. It can't be that big,
and it might not have any actual leak.
and also its giving se
> Those are probably the most labor-intensive ways that you can do it. It's
> usually easier to just pass "--without-mpicc" to configure and use the normal
> build process in all other respects.
1. No documentation: no mention of MPI in README*, no explicit list of packages
that might be eli
> I just like to know whether it's possible to disable the MPI feature when
> building Valgrind.
Here are two things to try:
1) Uninstall MPI (at least 'mpicc') then re-build valgrind, starting with
./autogen.sh . See "Building and installing it" in the README file.
or,
2) Remove the "mpi \
> Not sure what you mean however.
The characters in the original message were
* global_array[0] *= value1;
* global_array[1] *= value2;
except there were no spaces and no semicolons. This is unclear.
Why the leading star '*' before "global_array"?
My mail reader interpreted this i
> 1) Suppose that there is a global array named 'global_array'. Image the
> scenario where Thread1 does *global_array[0]*=value1 and Thread2 does
> *global_array[1]*=value2 without any protection. Clearly, that scenario does
> not cause any inconsistency problems. Is it possible that helgrind r
>>> FWIW this is a matter of 227Mb large /usr/lib/valgrind versus 71Mb without
>>> debug.
>>
>> Which machine architecture and compiler?
>
> amd64 gcc, but indeed with -g, because it's how binaries are supposed to
> be built in Debian.
For many [most?] packages, Fedora handles this by building _w
> Hi, in the packaging readme[0] for valgrind it's stated that it's a bad
> idea to strip what's in /usr/lib/valgrind/ ...
> FWIW this is a matter of 227Mb large /usr/lib/valgrind versus 71Mb without
> debug.
Which machine architecture and compiler?
There's a difference between stripped (applyin
> As posted above http://pastebin.com/LijCA8Km shows that there are some
> symbols that are undefined. I see that in x86, these symbols are also
> undefined. I don't really know what happens in the background if a symbol is
> undefined but there is no problem running valgrind on x86 with these
> What is the output from:
> $ ldd ./hello-arm-bionic ### print the shared libs needed by the app
> and what is the status of __libc_freeres with respect to each of the
> libraries named by ldd?
>
>
> Surprisingly, ldd says my program is not a dynamic executable
See /usr/bin
> This is objdump of vgpreload_core-arm-linux.so (on Android) :
> http://pastebin.com/X0Ngr8JP
I see:
052c g F .text 0070 _vgnU_freeres
which might be related to an intended replacement for __libc_freeres.
> So effectively, there is no __libc_freeres in the symbol table. So, to
> x0152532@unx0152532:~/mydroid$ readelf --segments ./linker
>
> Elf file type is EXEC (Executable file)
> Entry point 0xb0001000
> There are 5 program headers, starting at offset 52
>
> Program Headers:
> Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
> LOAD
> The formula end = (iph->p_vaddr - interp_addr) + iph->p_memsz; gives us
> 0xb001269c = (0xb0009000 - 0x0) + 0x969c so that's why we have interp_size
> as big as 2.9GB. So I tried to do interp_size = end & 0xF.. There is no
> more UME 22 Error but I got a Segmentation fault (the program w
> /data # strace valgrind --tool=none ./hello-arm-bionic
[snip]
> mmap2(0x8000, 4096, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0x8000
> fstat64(3, {st_mode=S_IFREG|0777, st_size=6788, ...}) = 0
> readlink("/proc/self/fd/3", "/data/hello-arm-bionic", 4096) = 22
> mmap2(0x9000, 4096, PR
On 04/20/2011 03:43 PM, Chatterjee, Shash wrote:
> I deleted my locally built log4cxx, apt and apt-util from /usr/local/lib,
> and reinstalled using yum. Now the ldd list is bigger and more like yours,
> except for differences like gcc-4.5.1 versus 4.6, etc.
How well does "valgrind ./test" wor
On 04/20/2011 02:51 PM, Chatterjee, Shash wrote:
>
> ... Still no go, same results!
>
In an earlier message Shash wrote:
-
Here's ldd output:
libapr-1.so.0 => /usr/local/lib/libapr-1.so.0 (0x0080e000)
libaprutil-1.so.0 => /usr/local/lib/libaprutil-1.so.0 (0x002c4000)
It also works for me on Fedora 15 i686 under valgrind 3.6.0 and
gcc-c++-4.6.0-5.fc15.i686:
$ valgrind ./test
==1811== Memcheck, a memory error detector
==1811== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==1811== Using Valgrind-3.6.0 and LibVEX; rerun with -h for copyright in
> I am on Fedora Core 14, kernel 2.6.35.12-88, g++ 4.5.1, glibc-2.13.1.
> int main(const int argc,
> const char** argv)
> {
> return (0);
> }
> g++ -g -Wall -o Test.o -c Test.cpp ### Note no "src/"
> g++-g Test.o -o test -llog4cxx
It works for me on Fedora 14:
gcc-c++
> I have used VG_(track_die_mem_stack) to track the SP change. I know that when
> C function is called, arguments will be pushed into stack firstly and
> secondly the function will be called. After the call, the callee will restore
> SP to the call point, and the caller is responsible in discard
On 04/01/2011 10:03 AM, WAROQUIERS Philippe wrote:
>>> 2. add a new kind of error in memcheck: "failed (re-)allocation".
>> I support such a warning the first time (each) for malloc and realloc.
>> For realloc because memcheck tries to increase the chances of
>> such an error;
>> for malloc bec
On 04/01/2011 08:32 AM, WAROQUIERS Philippe wrote:
> I suggest to look at two "fixes/improvements":
> 1. integrate the patch https://bugs.kde.org/show_bug.cgi?id=250101
> (I just tried a 3.7.0 SVN with this (updated) patch, and
> the program of Bob Harris works now perfectly till the
401 - 500 of 600 matches
Mail list logo
