You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
(58) |
Apr
(261) |
May
(169) |
Jun
(214) |
Jul
(201) |
Aug
(219) |
Sep
(198) |
Oct
(203) |
Nov
(241) |
Dec
(94) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(137) |
Feb
(149) |
Mar
(150) |
Apr
(193) |
May
(95) |
Jun
(173) |
Jul
(137) |
Aug
(236) |
Sep
(157) |
Oct
(150) |
Nov
(136) |
Dec
(90) |
| 2005 |
Jan
(139) |
Feb
(130) |
Mar
(274) |
Apr
(138) |
May
(184) |
Jun
(152) |
Jul
(261) |
Aug
(409) |
Sep
(239) |
Oct
(241) |
Nov
(260) |
Dec
(137) |
| 2006 |
Jan
(191) |
Feb
(142) |
Mar
(169) |
Apr
(75) |
May
(141) |
Jun
(169) |
Jul
(131) |
Aug
(141) |
Sep
(192) |
Oct
(176) |
Nov
(142) |
Dec
(95) |
| 2007 |
Jan
(98) |
Feb
(120) |
Mar
(93) |
Apr
(96) |
May
(95) |
Jun
(65) |
Jul
(62) |
Aug
(56) |
Sep
(53) |
Oct
(95) |
Nov
(106) |
Dec
(87) |
| 2008 |
Jan
(58) |
Feb
(149) |
Mar
(175) |
Apr
(110) |
May
(106) |
Jun
(72) |
Jul
(55) |
Aug
(89) |
Sep
(26) |
Oct
(96) |
Nov
(83) |
Dec
(93) |
| 2009 |
Jan
(97) |
Feb
(106) |
Mar
(74) |
Apr
(64) |
May
(115) |
Jun
(83) |
Jul
(137) |
Aug
(103) |
Sep
(56) |
Oct
(59) |
Nov
(61) |
Dec
(37) |
| 2010 |
Jan
(94) |
Feb
(71) |
Mar
(53) |
Apr
(105) |
May
(79) |
Jun
(111) |
Jul
(110) |
Aug
(81) |
Sep
(50) |
Oct
(82) |
Nov
(49) |
Dec
(21) |
| 2011 |
Jan
(87) |
Feb
(105) |
Mar
(108) |
Apr
(99) |
May
(91) |
Jun
(94) |
Jul
(114) |
Aug
(77) |
Sep
(58) |
Oct
(58) |
Nov
(131) |
Dec
(62) |
| 2012 |
Jan
(76) |
Feb
(93) |
Mar
(68) |
Apr
(95) |
May
(62) |
Jun
(109) |
Jul
(90) |
Aug
(87) |
Sep
(49) |
Oct
(54) |
Nov
(66) |
Dec
(84) |
| 2013 |
Jan
(67) |
Feb
(52) |
Mar
(93) |
Apr
(65) |
May
(33) |
Jun
(34) |
Jul
(52) |
Aug
(42) |
Sep
(52) |
Oct
(48) |
Nov
(66) |
Dec
(14) |
| 2014 |
Jan
(66) |
Feb
(51) |
Mar
(34) |
Apr
(47) |
May
(58) |
Jun
(27) |
Jul
(52) |
Aug
(41) |
Sep
(78) |
Oct
(30) |
Nov
(28) |
Dec
(26) |
| 2015 |
Jan
(41) |
Feb
(42) |
Mar
(20) |
Apr
(73) |
May
(31) |
Jun
(48) |
Jul
(23) |
Aug
(55) |
Sep
(36) |
Oct
(47) |
Nov
(48) |
Dec
(41) |
| 2016 |
Jan
(32) |
Feb
(34) |
Mar
(33) |
Apr
(22) |
May
(14) |
Jun
(31) |
Jul
(29) |
Aug
(41) |
Sep
(17) |
Oct
(27) |
Nov
(38) |
Dec
(28) |
| 2017 |
Jan
(28) |
Feb
(30) |
Mar
(16) |
Apr
(9) |
May
(27) |
Jun
(57) |
Jul
(28) |
Aug
(43) |
Sep
(31) |
Oct
(20) |
Nov
(24) |
Dec
(18) |
| 2018 |
Jan
(34) |
Feb
(50) |
Mar
(18) |
Apr
(26) |
May
(13) |
Jun
(31) |
Jul
(13) |
Aug
(11) |
Sep
(15) |
Oct
(12) |
Nov
(18) |
Dec
(13) |
| 2019 |
Jan
(12) |
Feb
(29) |
Mar
(51) |
Apr
(22) |
May
(13) |
Jun
(20) |
Jul
(13) |
Aug
(12) |
Sep
(21) |
Oct
(6) |
Nov
(9) |
Dec
(5) |
| 2020 |
Jan
(13) |
Feb
(5) |
Mar
(25) |
Apr
(4) |
May
(40) |
Jun
(27) |
Jul
(5) |
Aug
(17) |
Sep
(21) |
Oct
(1) |
Nov
(5) |
Dec
(15) |
| 2021 |
Jan
(28) |
Feb
(6) |
Mar
(11) |
Apr
(5) |
May
(7) |
Jun
(8) |
Jul
(5) |
Aug
(5) |
Sep
(11) |
Oct
(9) |
Nov
(10) |
Dec
(12) |
| 2022 |
Jan
(7) |
Feb
(13) |
Mar
(8) |
Apr
(7) |
May
(12) |
Jun
(27) |
Jul
(14) |
Aug
(27) |
Sep
(27) |
Oct
(17) |
Nov
(17) |
Dec
|
| 2023 |
Jan
(10) |
Feb
(18) |
Mar
(9) |
Apr
(26) |
May
|
Jun
(13) |
Jul
(18) |
Aug
(5) |
Sep
|
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
1
(1) |
2
(18) |
3
(3) |
4
|
5
|
|
6
|
7
(2) |
8
(1) |
9
(5) |
10
(3) |
11
(17) |
12
(6) |
|
13
|
14
(3) |
15
(7) |
16
|
17
|
18
(4) |
19
(2) |
|
20
(1) |
21
(5) |
22
(10) |
23
(2) |
24
(11) |
25
(7) |
26
(8) |
|
27
(4) |
28
(5) |
29
|
30
(6) |
|
|
|
|
From: Jesper F. <jes...@si...> - 2011-11-12 23:10:04
|
Dear all,
I get "Invalid read of size 8" in strspn(). The error can be reproduced by the following small program on Fedora 15 (glibc-2.14-5.x86_64):
$ cat valtest.c
#include <stdlib.h>
#include <string.h>
int main()
{
char *s = strdup(" ");
int n = strspn("abc", s);
free(s);
return n;
}
$ gcc -g -Wall valtest.c -o valtest
$ valgrind valtest
==20722== Memcheck, a memory error detector
==20722== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==20722== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==20722== Command: valtest
==20722==
==20722== Invalid read of size 8
==20722== at 0x3D3432735C: __strspn_sse42 (in /lib64/libc-2.14.so)
==20722== by 0x40057A: main (valtest.c:7)
==20722== Address 0x4c37040 is 0 bytes inside a block of size 2 alloc'd
==20722== at 0x4A0649D: malloc (vg_replace_malloc.c:236)
==20722== by 0x3D34280611: strdup (in /lib64/libc-2.14.so)
==20722== by 0x400565: main (valtest.c:6)
==20722==
==20722==
==20722== HEAP SUMMARY:
==20722== in use at exit: 0 bytes in 0 blocks
==20722== total heap usage: 1 allocs, 1 frees, 2 bytes allocated
==20722==
==20722== All heap blocks were freed -- no leaks are possible
==20722==
==20722== For counts of detected and suppressed errors, rerun with: -v
==20722== ERROR SUMMARY: 2 errors from 1 contexts (suppressed: 6 from 6)
Is this safe to suppress this with the following?
{
Invalid read of size 8 in strspn
Memcheck:Addr8
fun:__strspn_sse42
...
}
Best regards
/Jesper
|
|
From: Thomas R. <tr...@st...> - 2011-11-12 19:59:00
|
Panagiotis Foteinos wrote:
> Thank you.
>
> I got your code and compiled it. Not sure, however, what I should do
> next. Should I install valgrind with the new libvex your code
> produced?
It's based on top of SVN valgrind, so I'm not sure whether it will
work on top of a tarball. You need to get an SVN checkout, then apply
each of the patches in the corresponding directory (i.e., one at the
top level for valgrind and one within the VEX subdirectory). Then
compile and install as usual.
--
Thomas Rast
trast@{inf,student}.ethz.ch
|
|
From: Julian S. <js...@ac...> - 2011-11-12 16:16:11
|
> Now, the only difference between the readme.android and this I see is > that in the readme, they say i should see this: > # Platform variant: android > # Primary -DVGPV string: -DVGPV_arm_linux_android=1 > > ... so, how do I hack this platform variant to return a proper result? :) It would be much better if you actually followed the instructions in README.android exactly, and report on what results you got. J |
|
From: Dan K. <da...@ke...> - 2011-11-12 15:10:29
|
On Sat, Nov 12, 2011 at 6:44 AM, Xuehan Xu <xxh...@gm...> wrote: > I'm trying to find out whether there is some kind of dangling > pointers in my program. For example, maybe there are two pointers in my > program that point to the same address, and after one has been free'd, while > the other one is still used to write to that memory location. > Can valgrind detect this kind of error? Yes, probably. > And how to use it to detect it? Did you read http://valgrind.org/docs/manual/QuickStart.html yet? |
|
From: Xuehan Xu <xxh...@gm...> - 2011-11-12 14:44:44
|
Dear Sirs:
I'm trying to find out whether there is some kind of dangling
pointers in my program. For example, maybe there are two pointers in my
program that point to the same address, and after one has been free'd,
while the other one is still used to write to that memory location.
Can valgrind detect this kind of error? And how to use it to detect
it?
Thanks very much:-)
|
|
From: WAROQUIERS P. <phi...@eu...> - 2011-11-12 10:47:29
|
>once I extracted the valgrind-3.7 tarball into android/external, i >just went into the folder and used this >$ ./configure --build i686-pc-linux-gnu --host >arm-marvell-linux-gnueabi > >Then configuration proceeded fine... once everything was >setup, it was easy >$make clean; make >Both passing good and with no errors. > >Then I go into /valgrind-3.7/coregrind and pick up the file from >there, and put it in a folder which is used as the root file system of >the board. A faster alternative to adb pushing really. > >So whichever kind of app Valgrind is, I was guessing that I'll >probably be missing some binaries which is why i compiled it >statically. Effectively, I believe you are guessing properly one source of a problem, but for sure, the way you expect to solve this will *not* solve it. Valgrind is not a single executable, it is made of several executables, and scripts, and files and dynamic libraries. So, on this side, you should really follow README.android and use adb push etc. You might lose 2 minutes due to the adb push, but this will very probably spare hours of mysteries investigations. It looks like what you are trying to do is quite different of what has been tested and documented in README.android. A.o. if you try to just copy the valgrind, this will *not* work. Valgrind cannot be build statically as one single executable. You much better do make install etc. Probably the best is to start by having the minimal differences between the README.android and your actions. And when something does not work as documented, solve it so that you can continue the rest of the actions similarly. So, define the env variables as explained (pointing to your SDK), etc etc. >... so, how do I hack this platform variant to return a proper >result? :) You will probably need some changes in configure.in and similar and then re-run ./autogen.sh before the configure. But I have a close to zero knowledge of automake/autoconf and related, and so can't help you in this area (even if I would have access to a platform similar to yours). Philippe ____ This message and any files transmitted with it are legally privileged and intended for the sole use of the individual(s) or entity to whom they are addressed. If you are not the intended recipient, please notify the sender by reply and delete the message and any attachments from your system. Any unauthorised use or disclosure of the content of this message is strictly prohibited and may be unlawful. Nothing in this e-mail message amounts to a contractual or legal commitment on the part of EUROCONTROL, unless it is confirmed by appropriately signed hard copy. Any views expressed in this message are those of the sender. |
|
From: Panagiotis F. <paf...@gm...> - 2011-11-11 20:35:46
|
Thank you. I got your code and compiled it. Not sure, however, what I should do next. Should I install valgrind with the new libvex your code produced? Regards, Panagiotis On Fri, Nov 11, 2011 at 11:34 AM, Thomas Rast <tr...@st...> wrote: > Hi Panagiotis > > Panagiotis Foteinos wrote: >> Is it possible for memcheck to support FE_UPWARD rounding mode as >> well? I am building applications on top of CGAL (www.cgal.org), a >> package that extensively uses interval arithmetics with FE_UPWARD, >> and I would like to employ Valgrind's capabilities to detect memory >> leaks. > > I'm in much the same situation. Assuming you work on amd64, you could > try the patches I posted on the developers list the other day: > > http://sourceforge.net/mailarchive/forum.php?thread_name=201111091217.47291.trast%40student.ethz.ch&forum_name=valgrind-developers > > Cheers, > > -- > Thomas Rast > trast@{inf,student}.ethz.ch > |
|
From: Александар М. <dar...@gm...> - 2011-11-11 17:14:00
|
Sure,
once I extracted the valgrind-3.7 tarball into android/external, i
just went into the folder and used this
$ ./configure --build i686-pc-linux-gnu --host arm-marvell-linux-gnueabi
Then configuration proceeded fine... once everything was setup, it was easy
$make clean; make
Both passing good and with no errors.
Then I go into /valgrind-3.7/coregrind and pick up the file from
there, and put it in a folder which is used as the root file system of
the board. A faster alternative to adb pushing really.
So whichever kind of app Valgrind is, I was guessing that I'll
probably be missing some binaries which is why i compiled it
statically.
I even went as far as to put it in /tmp/ folder, enter the folder and
try to call it. So... here's what I did to get up to here.
$ ./configure --build i686-pc-linux-gnu --host arm-marvell-eabi
checking host system type... arm-marvell-eabi
checking for a supported CPU... no (arm)
configure: error: Unsupported host architecture. Sorry
** I go into the configure script and fix that. ***
$ ./configure --build i686-pc-linux-gnu --host arm-marvell-eabi
checking for a supported CPU... ok (arm)
checking for a 64-bit only build... no
checking for a 32-bit only build... no
checking for a supported OS... no (eabi)
this one I wasn't going to fix so instead I just did
$ ./configure --build i686-pc-linux-gnu --host arm-marvell-linux-gnueabi
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for arm-marvell-linux-gnueabi-strip... arm-marvell-linux-gnueabi-strip
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking whether ln -s works... yes
checking for arm-marvell-linux-gnueabi-gcc...
/scratch/workareas/MV88DE3100_SDK/SDK_Tools/cross_toolchain/tarballs/4.4.5/arm-marvell-linux-gnueabi-4.4.5/bin/arm-marvell-linux-gnueabi-gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... yes
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
. . . . . . .
Maximum build arch: arm
Primary build arch: arm
Secondary build arch:
Build OS: linux
Primary build target: ARM_LINUX
Secondary build target:
Platform variant: vanilla
Primary -DVGPV string: -DVGPV_arm_linux_vanilla=1
Default supp files: exp-sgcheck.supp xfree-3.supp
xfree-4.supp glibc-2.X-drd.supp glibc-2.34567-NPTL-helgrind.supp
glibc-2.X.supp
Now, the only difference between the readme.android and this I see is
that in the readme, they say i should see this:
# Platform variant: android
# Primary -DVGPV string: -DVGPV_arm_linux_android=1
... so, how do I hack this platform variant to return a proper result? :)
|
|
From: WAROQUIERS P. <phi...@eu...> - 2011-11-11 16:58:09
|
> >But here's what it is: >android sdk is on my VM. the rootfs is on the board. there is no >/external/valgrind/coregrind/valgrind on the board, it's just >/system/bin/valgrind. Every other app I put there becomes "visible" >instantly as i work with a live NFS. I really don't know why valgrind >is acting up and pretending not to be there when it clearly IS there. valgrind is not a typical application, and just copy "valgrind" is to my knowledge not going to work. Which "configure" command did you use ? Which "make" and "make install" command did you use ? Did you (and how?) "push" your valgrind onto the Android ? Or do you assume that the compiled and installed valgrind on the sdk visible through NFS is automatically working ? (in other words, you might indicate the differences between what you are doing and what is indicated in the README.android). Philippe ____ This message and any files transmitted with it are legally privileged and intended for the sole use of the individual(s) or entity to whom they are addressed. If you are not the intended recipient, please notify the sender by reply and delete the message and any attachments from your system. Any unauthorised use or disclosure of the content of this message is strictly prohibited and may be unlawful. Nothing in this e-mail message amounts to a contractual or legal commitment on the part of EUROCONTROL, unless it is confirmed by appropriately signed hard copy. Any views expressed in this message are those of the sender. |
|
From: Александар М. <dar...@gm...> - 2011-11-11 16:50:39
|
Thanks for the input, but the thing is - i'm running on a proprietary board (running on ARMv7+VFP); for which android has been specifically ported. I'm avoiding to disclose potentially sensitive (confidential) info, but here's the deal: When I first try to configure with the arm-eabi compiler I got with this SDK, valgrind doesn't recognize the OS and returns... then i configure it with arm-linux-gnueabi, i've added support for all ARM processors (config.sh, line 5288 or so, changed armv7* to arm*) and that goes well. After I get the compiled binary, I put it in the rootfs folder used for booting up the board, like any other file. That's why I know it's not a PATH issue, because it's the exact same procedure i do for every other app and they *always* get found without absolute pathing. >From what I understood, the "official" way states that it only works on Nexus S, but I know for sure it can run on our board as well - some collegues (which i can't get hold of currently) have used it without too much hassle. But here's what it is: android sdk is on my VM. the rootfs is on the board. there is no /external/valgrind/coregrind/valgrind on the board, it's just /system/bin/valgrind. Every other app I put there becomes "visible" instantly as i work with a live NFS. I really don't know why valgrind is acting up and pretending not to be there when it clearly IS there. I can't even get it to scan through LS, so a hello_world.c won't do me much good either I suppose... but I can try. So, how do I help you help me without breaching any NDAs? :) P.S. I have to compile Valgrind with -static (err... link it statically) for it to run on the board when using the said arm-linux-gnueabi compiler. |
|
From: Thomas R. <tr...@st...> - 2011-11-11 16:34:56
|
Hi Panagiotis Panagiotis Foteinos wrote: > Is it possible for memcheck to support FE_UPWARD rounding mode as > well? I am building applications on top of CGAL (www.cgal.org), a > package that extensively uses interval arithmetics with FE_UPWARD, > and I would like to employ Valgrind's capabilities to detect memory > leaks. I'm in much the same situation. Assuming you work on amd64, you could try the patches I posted on the developers list the other day: http://sourceforge.net/mailarchive/forum.php?thread_name=201111091217.47291.trast%40student.ethz.ch&forum_name=valgrind-developers Cheers, -- Thomas Rast trast@{inf,student}.ethz.ch |
|
From: WAROQUIERS P. <phi...@eu...> - 2011-11-11 15:51:35
|
According to the output below, your valgrind seems to be at least located in /android/external/valgrind-3.7.0/coregrind and so you might try: /android/external/valgrind-3.7.0/coregrind/valgrind But this looks like this Valgrind has not been installed and/or compiled according to the "official way". Cfr my previous mail: I succeeded having a Valgrind running on Android, doing *precisely* what is documented in README.android. It looks like what you did does not match the README.android and this might very well be the source of the problem. Philippe >-----Original Message----- >From: Александар Миленковић [mailto:dar...@gm...] >Sent: Friday 11 November 2011 16:30 >To: Alexander Potapenko >Cc: val...@li... >Subject: Re: [Valgrind-users] Valgrind on Android (Gingerbread) > ><ommited>:/android/external/valgrind-3.7.0/coregrind$ file valgrind >valgrind: ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically >linked, for GNU/Linux 2.6.16, not stripped > > ><ommited>:/android/external/valgrind-3.7.0/coregrind$ head valgrind > ELF ( @ 4 4 ($! p ȍȍ ȍ > - - - 1 > ȍ ( Q td GNU - / > > 0 T # H Ć 0 0 0 S > / > @- 4@ 0 S $0 S ><0 - S 0 @ /ᨕ >0 0 , 0 S > 0 S > O- / @ % `P & >: E @@㔟 @ > ' pP t ` Pf Ɏ 0 0 ` > > > Y P ȅ @ >V p@- M M @ @ / >@ 0 5 / P @ @ / >@ 0 & 㬖 PP @ / >@ 0 * ` V @ @ / @ 0 > 0 ?O * > 0 #S 2 0 !S / V > >Thank you for your response Aleksandr, > >Aleksandar > >On Fri, Nov 11, 2011 at 4:26 PM, Alexander Potapenko ><gl...@go...> wrote: >> Can you try: >> >> $ file `which valgrind` >> and >> $ head `which valgrind` >> ? >> >> On Fri, Nov 11, 2011 at 7:21 PM, Александар Миленковић >> <dar...@gm...> wrote: >>> Unfortunately, the . is necessary for some reason. >>> >>> Here's a more complete log. >>> >>> # . /valgrind --leak-check=yes testapp >>> .: Can't open /valgrind >>> # ./valgrind --leak-check=yes testapp >>> ./valgrind: not found >>> # . valgrind --leak-check=yes testapp >>> /system/bin/valgrind: 1: Syntax error: word unexpected >(expecting ")") >>> # valgrind --leak-check=yes ./system/bin/testapp >>> valgrind: not found >>> >>> Thanks for your time Phillipe. >>> >>> Aleksandar >>> >>> >--------------------------------------------------------------- >--------------- >>> RSA(R) Conference 2012 >>> Save $700 by Nov 18 >>> Register now >>> http://p.sf.net/sfu/rsa-sfdev2dev1 >>> _______________________________________________ >>> Valgrind-users mailing list >>> Val...@li... >>> https://lists.sourceforge.net/lists/listinfo/valgrind-users >>> >> >> >> >> -- >> Alexander Potapenko >> Software Engineer >> Google Moscow >> >--------------------------------------------------------------- >--------------- >RSA(R) Conference 2012 >Save $700 by Nov 18 >Register now >http://p.sf.net/sfu/rsa-sfdev2dev1 >_______________________________________________ >Valgrind-users mailing list >Val...@li... >https://lists.sourceforge.net/lists/listinfo/valgrind-users > ____ This message and any files transmitted with it are legally privileged and intended for the sole use of the individual(s) or entity to whom they are addressed. If you are not the intended recipient, please notify the sender by reply and delete the message and any attachments from your system. Any unauthorised use or disclosure of the content of this message is strictly prohibited and may be unlawful. Nothing in this e-mail message amounts to a contractual or legal commitment on the part of EUROCONTROL, unless it is confirmed by appropriately signed hard copy. Any views expressed in this message are those of the sender. |
|
From: Dan K. <da...@ke...> - 2011-11-11 15:48:29
|
Try compiling a "hello, world" c program with the same compiler and compiler flags you used for valgrind. Maybe it's generating an executable type your system doesn't recognize. |
|
From: Baurzhan I. <ib...@ra...> - 2011-11-11 15:47:47
|
On Fri, Nov 11, 2011 at 04:07:13PM +0100, Александар Миленковић wrote: > # . valgrind --leak-check=yes ./system/bin/testapp > /system/bin/valgrind: 1: Syntax error: word unexpected (expecting ")") Have you intended to start ./valgrind? With kind regards, Baurzhan. |
|
From: Александар М. <dar...@gm...> - 2011-11-11 15:41:19
|
Thanks for the suggestion Philippe but I already did. # . /system/bin/valgrind ls /system/bin/valgrind: 1: Syntax error: word unexpected (expecting ")") # /system/bin/valgrind ls /system/bin/valgrind: not found The way I see it, it doesn't matter if it's a PATH thing or not... I can't even get the basic 'demo run' of ls or any other app. I'm getting slightly frustrated being stuck on this stupid step #1. Thanks for helping, Aleksandar |
|
From: David C. <dcc...@ac...> - 2011-11-11 15:40:53
|
On 11/11/2011 7:21 AM, Александар Миленковић wrote:
> Unfortunately, the . is necessary for some reason.
>
> Here's a more complete log.
>
> # . /valgrind --leak-check=yes testapp
> .: Can't open /valgrind
> # ./valgrind --leak-check=yes testapp
> ./valgrind: not found
> # . valgrind --leak-check=yes testapp
> /system/bin/valgrind: 1: Syntax error: word unexpected (expecting ")")
> # valgrind --leak-check=yes ./system/bin/testapp
> valgrind: not found
>
>
What happens if you run "/system/bin/valgrind --leak-check=yes
testapp"? It seems that valgrind is installed in /system/bin.
What is the search path in the shell? If the search path does not
include the directory in which valgrind is located, the shell will have
trouble finding it.
--
David Chapman dcc...@ac...
Chapman Consulting -- San Jose, CA
|
|
From: Panagiotis F. <paf...@gm...> - 2011-11-11 15:40:28
|
Hello list. Is it possible for memcheck to support FE_UPWARD rounding mode as well? I am building applications on top of CGAL (www.cgal.org), a package that extensively uses interval arithmetics with FE_UPWARD, and I would like to employ Valgrind's capabilities to detect memory leaks. Best Regards, Panagiotis Foteinos |
|
From: WAROQUIERS P. <phi...@eu...> - 2011-11-11 15:37:28
|
># . /valgrind --leak-check=yes testapp >.: Can't open /valgrind ># ./valgrind --leak-check=yes testapp >./valgrind: not found ># . valgrind --leak-check=yes testapp >/system/bin/valgrind: 1: Syntax error: word unexpected (expecting ")") ># valgrind --leak-check=yes ./system/bin/testapp >valgrind: not found I suggest you try with absolute paths both for valgrind and the testapp. E.g. assuming valgrind is in the directory /somewhere/where/you/find/valgrind and your testapp is in the directory /theplace/where/you/find/testapp type: /somewhere/where/you/find/valgrind --leak-check=yes /theplace/where/you/find/testapp This should avoid PATH problems. Philippe ____ This message and any files transmitted with it are legally privileged and intended for the sole use of the individual(s) or entity to whom they are addressed. If you are not the intended recipient, please notify the sender by reply and delete the message and any attachments from your system. Any unauthorised use or disclosure of the content of this message is strictly prohibited and may be unlawful. Nothing in this e-mail message amounts to a contractual or legal commitment on the part of EUROCONTROL, unless it is confirmed by appropriately signed hard copy. Any views expressed in this message are those of the sender. |
|
From: Alexander P. <gl...@go...> - 2011-11-11 15:34:46
|
Can you try: $ file `which valgrind` and $ head `which valgrind` ? On Fri, Nov 11, 2011 at 7:21 PM, Александар Миленковић <dar...@gm...> wrote: > Unfortunately, the . is necessary for some reason. > > Here's a more complete log. > > # . /valgrind --leak-check=yes testapp > .: Can't open /valgrind > # ./valgrind --leak-check=yes testapp > ./valgrind: not found > # . valgrind --leak-check=yes testapp > /system/bin/valgrind: 1: Syntax error: word unexpected (expecting ")") > # valgrind --leak-check=yes ./system/bin/testapp > valgrind: not found > > Thanks for your time Phillipe. > > Aleksandar > > ------------------------------------------------------------------------------ > RSA(R) Conference 2012 > Save $700 by Nov 18 > Register now > http://p.sf.net/sfu/rsa-sfdev2dev1 > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > -- Alexander Potapenko Software Engineer Google Moscow |
|
From: Александар М. <dar...@gm...> - 2011-11-11 15:30:19
|
<ommited>:/android/external/valgrind-3.7.0/coregrind$ file valgrind
valgrind: ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically
linked, for GNU/Linux 2.6.16, not stripped
<ommited>:/android/external/valgrind-3.7.0/coregrind$ head valgrind
ELF ( @�4� 4 ($! p����� � ��ȍȍ� ȍ�
�� -� -� ��� �-� 1 � �����
ȍ ( Q�td GNU �-� ��� �/������� �
��
0��T��#�H��� 0�� �� 0 0��S�
� � �/��
@-�4@�� ���0��S� $0��S�
<0��-�S� �0�� ��@�� �/ᨕ
0��0 ��� �,��0��S�
0��S�
���O-���/� � @��%�`P�&
:����E @@㔟 � �@���� �
��'��pP� �� ��t��`���Pf� �� �� ��Ɏ�0��0�� `�� �� ��
�� � ��� ��
��Y��P�ȅ �@
V��������p@-� �M�M�@�� ��� � @��/ �
@� 0��5� ��/ �����P� ������@�� ��� � @��/ �
@� 0��&� �� �㬖�PP��� ��� � @��/ �
@� 0�� �� �� *�����`������� V���@�� ��� � @��/ � @� 0�� �0��?O� *�
�� 0��#S�2 0��!S�/ V��
Thank you for your response Aleksandr,
Aleksandar
On Fri, Nov 11, 2011 at 4:26 PM, Alexander Potapenko <gl...@go...> wrote:
> Can you try:
>
> $ file `which valgrind`
> and
> $ head `which valgrind`
> ?
>
> On Fri, Nov 11, 2011 at 7:21 PM, Александар Миленковић
> <dar...@gm...> wrote:
>> Unfortunately, the . is necessary for some reason.
>>
>> Here's a more complete log.
>>
>> # . /valgrind --leak-check=yes testapp
>> .: Can't open /valgrind
>> # ./valgrind --leak-check=yes testapp
>> ./valgrind: not found
>> # . valgrind --leak-check=yes testapp
>> /system/bin/valgrind: 1: Syntax error: word unexpected (expecting ")")
>> # valgrind --leak-check=yes ./system/bin/testapp
>> valgrind: not found
>>
>> Thanks for your time Phillipe.
>>
>> Aleksandar
>>
>> ------------------------------------------------------------------------------
>> RSA(R) Conference 2012
>> Save $700 by Nov 18
>> Register now
>> http://p.sf.net/sfu/rsa-sfdev2dev1
>> _______________________________________________
>> Valgrind-users mailing list
>> Val...@li...
>> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>>
>
>
>
> --
> Alexander Potapenko
> Software Engineer
> Google Moscow
>
|
|
From: Александар М. <dar...@gm...> - 2011-11-11 15:22:09
|
Unfortunately, the . is necessary for some reason. Here's a more complete log. # . /valgrind --leak-check=yes testapp .: Can't open /valgrind # ./valgrind --leak-check=yes testapp ./valgrind: not found # . valgrind --leak-check=yes testapp /system/bin/valgrind: 1: Syntax error: word unexpected (expecting ")") # valgrind --leak-check=yes ./system/bin/testapp valgrind: not found Thanks for your time Phillipe. Aleksandar |
|
From: WAROQUIERS P. <phi...@eu...> - 2011-11-11 15:17:02
|
># . valgrind --leak-check=yes ./system/bin/testapp >/system/bin/valgrind: 1: Syntax error: word unexpected (expecting ")") Why do you put a . in front of valgrind ? To my knowledge, this indicates that the shell has to "interpret" this "script". But valgrind is an executable. So, I guess the shell obeys and tries to interpret object code as a script, and reports a syntax error. Does it work to just type: valgrind --leak-check=yes ./system/bin/testapp ? Philippe ____ This message and any files transmitted with it are legally privileged and intended for the sole use of the individual(s) or entity to whom they are addressed. If you are not the intended recipient, please notify the sender by reply and delete the message and any attachments from your system. Any unauthorised use or disclosure of the content of this message is strictly prohibited and may be unlawful. Nothing in this e-mail message amounts to a contractual or legal commitment on the part of EUROCONTROL, unless it is confirmed by appropriately signed hard copy. Any views expressed in this message are those of the sender. |
|
From: Александар М. <dar...@gm...> - 2011-11-11 15:07:42
|
Hi, first post here. So let's get to the stuff I need help with. I have compiled Valgrind 3.7 using arm-linux-gnueabi compiler with the -static option. When I try to run it, I get this: # . valgrind --leak-check=yes ./system/bin/testapp /system/bin/valgrind: 1: Syntax error: word unexpected (expecting ")") The test app is compiled in the same way, also statically linked. Can anyone please help me with this? I appreciate it. Aleksandar |
|
From: Paul A. <pa...@vi...> - 2011-11-10 23:02:34
|
I've also found that if I collapse the "Instance" layer and create the threads directly from main() instead, the problem seems to go away. This leads me to the possible conclusion that HG is having an issue with data access from a thread created by a (non-main) thread. Paul > -----Original Message----- > From: Bart Van Assche [mailto:bar...@gm...] > Sent: Wednesday, November 09, 2011 11:11 AM > To: Paul Archard > Cc: val...@li... > Subject: Re: [Valgrind-users] Thread local storage (TLS) support > > On Wed, Nov 9, 2011 at 7:18 PM, Paul Archard > <pa...@vi...> wrote: > > Could someone in the know please clarify the support of TLS in > Valgrind/Helgrind? > > > > I am running Helgrind (version 3.7.0) on our code, which makes heavy > use of TLS on GCC 4.5.1 with GLIBC 2.13. I am seeing a lot of what I > believe are false positives, where a thread local variable is read on > one thread and set on another "simultaneously". I don't see any > possible way that there is contention since different threads are > involved and by definition this access is safe. This leads me to > believe that Helgrind is not recognizing the fact that the variables > are thread-local. > > > > I have tried using VALGRIND_HG_DISABLE_CHECKING( ) on some of these > variables, but even that seems to not work consistently. It's > important to us for Valgrind tests to pass since we need to hand off > the binaries to another group and they use Valgrind to validate their > releases. > > TLS should be supported by Helgrind and DRD. If you can post a minimal > example that allows to reproduce the issue you observed with TLS we > can have a closer look at it. > > Bart. |
|
From: Paul A. <pa...@vi...> - 2011-11-10 20:17:31
|
Ok, here's a small(ish) code sample that reproduces the issue. There's
two levels of threading going on to model a multi-instance program with
each instance having multiple threads. As you can see, there is a single
thread-local variable which Helgrind claims is being raced...
Code:
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <signal.h>
#include <pthread.h>
#include <unistd.h>
bool g_shutdown = false;
pthread_mutex_t g_lock;
int g_max_threads = 4;
int g_max_controllers = 2;
__thread __attribute__ ((aligned (8))) unsigned long l_inst_id = 0;
int g_max_wait = 100;
bool Shutdown()
{
bool res = false;
pthread_mutex_lock(&g_lock);
res = g_shutdown;
pthread_mutex_unlock(&g_lock);
return res;
}
void Error(const char *message)
{
fprintf(stderr, message);
abort();
}
class Thread
{
public:
Thread(int id)
: m_thread(0), m_id(id) {}
void Run()
{
pthread_create(&m_thread, NULL, &Thread::EntryPoint,
this);
}
void Wait()
{
pthread_join(m_thread, NULL);
}
private:
pthread_t m_thread;
int m_id;
static void *EntryPoint(void *ptr)
{
Thread *thread = (Thread *)ptr;
thread->Start();
return 0;
}
void Start()
{
printf("thread %d start\n", m_id);
fflush(stdout);
l_inst_id = m_id; // <----- offending line of code
printf("thread %d done\n", m_id);
fflush(stdout);
}
};
class Instance
{
public:
void Run()
{
while (!Shutdown())
{
// wait a random time
int wait = rand() % g_max_wait;
usleep(wait * 1000);
Thread *threads[g_max_threads];
printf("inst start\n");
// create and run a random number of threads
int num_threads = (rand() % g_max_threads) + 1;
for (int i = 0; i < num_threads; i++)
{
threads[i] = new Thread(i);
if (threads[i])
threads[i]->Run();
}
// wait for threads to terminate
for (int i = 0; i < num_threads; i++)
{
if (threads[i])
{
threads[i]->Wait();
delete threads[i];
}
}
printf("inst done\n");
fflush(stdout);
}
}
};
class Controller
{
public:
Controller()
{
}
void Run()
{
pthread_create(&m_thread, NULL, &Controller::EntryPoint,
this);
}
void Wait()
{
pthread_join(m_thread, NULL);
}
private:
pthread_t m_thread;
static void *EntryPoint(void *ptr)
{
Controller *controller = (Controller *)ptr;
controller->Start();
return 0;
}
void Start()
{
while (!Shutdown())
{
// wait a random time
int wait = rand() % g_max_wait;
usleep(wait * 1000);
// try to create and run an instance
Instance().Run();
}
printf("controller shutdown\n");
}
};
static void
handle_sigint(int signum)
{
printf("got ctrl-c\n");
pthread_mutex_lock(&g_lock);
g_shutdown = true;
pthread_mutex_unlock(&g_lock);
}
int main(int argc, char *argv[])
{
pthread_mutex_init(&g_lock, NULL);
// set up signal handlers
signal(SIGINT, handle_sigint);
// create a number of controllers
Controller *controllers[g_max_controllers];
for (int i = 0; i < g_max_controllers; i++)
{
controllers[i] = new Controller;
if (controllers[i])
controllers[i]->Run();
}
// wait for controllers to terminate
for (int i = 0; i < g_max_controllers; i++)
{
if (controllers[i])
{
controllers[i]->Wait();
delete controllers[i];
}
}
pthread_mutex_destroy(&g_lock);
return 0;
}
Valgrind output:
==9879== Helgrind, a thread error detector
==9879== Copyright (C) 2007-2011, and GNU GPL'd, by OpenWorks LLP et al.
==9879== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==9879== Command: ./insttest
==9879==
==9879== ---Thread-Announcement------------------------------------------
==9879==
==9879== Thread #7 was created
==9879== at 0x376D2E0BEE: clone (in /lib64/libc-2.13.so)
==9879== by 0x376D605D9F: do_clone.clone.2 (in
/lib64/libpthread-2.13.so)
==9879== by 0x376D60731A: pthread_create@@GLIBC_2.2.5 (in
/lib64/libpthread-2.13.so)
==9879== by 0x4A0950F: pthread_create_WRK (hg_intercepts.c:255)
==9879== by 0x4A096B2: pthread_create@* (hg_intercepts.c:286)
==9879== by 0x400EA6: Thread::Run() (insttest.cpp:40)
==9879== by 0x401062: Instance::Run() (insttest.cpp:92)
==9879== by 0x4011D2: Controller::Start() (insttest.cpp:148)
==9879== by 0x40118B: Controller::EntryPoint(void*) (insttest.cpp:135)
==9879== by 0x4A0969B: mythread_wrapper (hg_intercepts.c:219)
==9879== by 0x376D606CCA: start_thread (in /lib64/libpthread-2.13.so)
==9879== by 0x376D2E0C2C: clone (in /lib64/libc-2.13.so)
==9879==
==9879== ---Thread-Announcement------------------------------------------
==9879==
==9879== Thread #4 was created
==9879== at 0x376D2E0BEE: clone (in /lib64/libc-2.13.so)
==9879== by 0x376D605D9F: do_clone.clone.2 (in
/lib64/libpthread-2.13.so)
==9879== by 0x376D60731A: pthread_create@@GLIBC_2.2.5 (in
/lib64/libpthread-2.13.so)
==9879== by 0x4A0950F: pthread_create_WRK (hg_intercepts.c:255)
==9879== by 0x4A096B2: pthread_create@* (hg_intercepts.c:286)
==9879== by 0x400EA6: Thread::Run() (insttest.cpp:40)
==9879== by 0x401062: Instance::Run() (insttest.cpp:92)
==9879== by 0x4011D2: Controller::Start() (insttest.cpp:148)
==9879== by 0x40118B: Controller::EntryPoint(void*) (insttest.cpp:135)
==9879== by 0x4A0969B: mythread_wrapper (hg_intercepts.c:219)
==9879== by 0x376D606CCA: start_thread (in /lib64/libpthread-2.13.so)
==9879== by 0x376D2E0C2C: clone (in /lib64/libc-2.13.so)
==9879==
==9879== ----------------------------------------------------------------
==9879==
==9879== Possible data race during write of size 8 at 0x6CDE6F8 by thread
#7
==9879== Locks held: none
==9879== at 0x400F30: Thread::Start() (insttest.cpp:64)
==9879== by 0x400EEB: Thread::EntryPoint(void*) (insttest.cpp:55)
==9879== by 0x4A0969B: mythread_wrapper (hg_intercepts.c:219)
==9879== by 0x376D606CCA: start_thread (in /lib64/libpthread-2.13.so)
==9879== by 0x376D2E0C2C: clone (in /lib64/libc-2.13.so)
==9879==
==9879== This conflicts with a previous write of size 8 by thread #4
==9879== Locks held: none
==9879== at 0x400F30: Thread::Start() (insttest.cpp:64)
==9879== by 0x400EEB: Thread::EntryPoint(void*) (insttest.cpp:55)
==9879== by 0x4A0969B: mythread_wrapper (hg_intercepts.c:219)
==9879== by 0x376D606CCA: start_thread (in /lib64/libpthread-2.13.so)
==9879== by 0x376D2E0C2C: clone (in /lib64/libc-2.13.so)
==9879==
==9879==
==9879== For counts of detected and suppressed errors, rerun with: -v
==9879== Use --history-level=approx or =none to gain increased speed, at
==9879== the cost of reduced accuracy of conflicting-access information
==9879== ERROR SUMMARY: 149 errors from 1 contexts (suppressed: 39932 from
419)
Thanks,
Paul
> -----Original Message-----
> From: Bart Van Assche [mailto:bar...@gm...]
> Sent: Wednesday, November 09, 2011 11:11 AM
> To: Paul Archard
> Cc: val...@li...
> Subject: Re: [Valgrind-users] Thread local storage (TLS) support
>
> On Wed, Nov 9, 2011 at 7:18 PM, Paul Archard
> <pa...@vi...> wrote:
> > Could someone in the know please clarify the support of TLS in
> Valgrind/Helgrind?
> >
> > I am running Helgrind (version 3.7.0) on our code, which makes heavy
> use of TLS on GCC 4.5.1 with GLIBC 2.13. I am seeing a lot of what I
> believe are false positives, where a thread local variable is read on
> one thread and set on another "simultaneously". I don't see any
> possible way that there is contention since different threads are
> involved and by definition this access is safe. This leads me to
> believe that Helgrind is not recognizing the fact that the variables
> are thread-local.
> >
> > I have tried using VALGRIND_HG_DISABLE_CHECKING( ) on some of these
> variables, but even that seems to not work consistently. It's
> important to us for Valgrind tests to pass since we need to hand off
> the binaries to another group and they use Valgrind to validate their
> releases.
>
> TLS should be supported by Helgrind and DRD. If you can post a minimal
> example that allows to reproduce the issue you observed with TLS we
> can have a closer look at it.
>
> Bart.
|