valgrind-users — General discussion list for Valgrind users

[Valgrind-users] Re: Kcachegrind configuration

[Josef W. <Jos...@gm...>]

On Tuesday 22 July 2003 19:43, Alex Ivershen wrote:
> Hi all!
>
> Please, give me a hand with this - I am trying to install Kcachegrind 0.3b
> and I cannot get past configuration stage. I have RH 8.0 with Qt  3.0.5-17
> and KDE 3.0.5a-4 RPMs installed.  Kcachegrind configure can find Qt just
> fine, but bails out on KDE dependencies.  The configuration command is like
> this:
>
> ./configure --with-qt-dir=/usr/lib/qt-3.0.5 --with-gnu-ld
> --prefix=/usr                     (I tries --prefix=/usr/local as well)
>
> The tail ot the configure output is:

Hi,

I just don't know where KDE libs are installed on a Red Hat system,
but you should be able to check with "kde-config --prefix".
Perhaps you don't have developer-packages for kdelibs installed? The C++ 
headers are needed for compilation. Usually the package is called like 
"kdelibs-devel"...

Or use a precompiled binary. At least KCachegrind 0.3a is available on
http://apps.kde.com for Red Hat 8.0.

>
> checking for Qt... libraries /usr/lib/qt-3.0.5/lib, headers
> /usr/lib/qt-3.0.5/include using -mt
> checking if Qt compiles without flags... no
> checking for moc... /usr/lib/qt-3.0.5/bin/moc
> checking for uic... /usr/lib/qt-3.0.5/bin/uic
> checking whether uic supports -L ... yes
> checking whether uic supports -nounload ... yes
> checking if Qt needs -ljpeg... no
> checking for rpath... yes
> checking for KDE... configure: error:
> in the prefix, you've chosen, are no KDE headers installed. This will fail.
> So, check this please and use another prefix!
>
>
> Please, let me know what I am doing wrong here. I just hope I won't have to
> recompile KDE locally here. I would also like to install kcachegring in a

No panic ;-) Recompiling KDE is useless overkill for compiling a KDE app.

> different (shared network) directory, where there are definitely no KDE
> artifacts - it that impossible?

Hmm... The "--prefix" option is the way to choose the path where KCachegrind
should be installed. This doesn't have to be the same as the global KDE path
on your system. Note that the headers should be found neverless (via 
kde-config) by configure.
You only have to make sure after installing to another dir, that the 
executable is in the PATH and environment variable KDEDIR contains the prefix
you have choosen.

Josef

>
> Thanks for your help!
>
> Alex
>
> --
> Alex G. Ivershen                            Inet Technologies, Inc.
> Network Products Dept.                      1500 N. Greenville Ave.
> Inet Technologies Inc.                      Richardson, TX 75081
> Phone: +1-469-330-4295                      USA

[Valgrind-users] Kcachegrind configuration

[Alex I. <ale...@in...>]

SGkgYWxsIQ0KDQpQbGVhc2UsIGdpdmUgbWUgYSBoYW5kIHdpdGggdGhpcyAtIEkgYW0gdHJ5
aW5nIHRvIGluc3RhbGwgS2NhY2hlZ3JpbmQgMC4zYg0KYW5kIEkgY2Fubm90IGdldCBwYXN0
IGNvbmZpZ3VyYXRpb24gc3RhZ2UuIEkgaGF2ZSBSSCA4LjAgd2l0aCBRdCAgMy4wLjUtMTcN
CmFuZCBLREUgMy4wLjVhLTQgUlBNcyBpbnN0YWxsZWQuICBLY2FjaGVncmluZCBjb25maWd1
cmUgY2FuIGZpbmQgUXQganVzdA0KZmluZSwgYnV0IGJhaWxzIG91dCBvbiBLREUgZGVwZW5k
ZW5jaWVzLiAgVGhlIGNvbmZpZ3VyYXRpb24gY29tbWFuZCBpcyBsaWtlDQp0aGlzOg0KDQou
L2NvbmZpZ3VyZSAtLXdpdGgtcXQtZGlyPS91c3IvbGliL3F0LTMuMC41IC0td2l0aC1nbnUt
bGQNCi0tcHJlZml4PS91c3IgICAgICAgICAgICAgICAgICAgICAoSSB0cmllcyAtLXByZWZp
eD0vdXNyL2xvY2FsIGFzIHdlbGwpDQoNClRoZSB0YWlsIG90IHRoZSBjb25maWd1cmUgb3V0
cHV0IGlzOg0KDQpjaGVja2luZyBmb3IgUXQuLi4gbGlicmFyaWVzIC91c3IvbGliL3F0LTMu
MC41L2xpYiwgaGVhZGVycw0KL3Vzci9saWIvcXQtMy4wLjUvaW5jbHVkZSB1c2luZyAtbXQN
CmNoZWNraW5nIGlmIFF0IGNvbXBpbGVzIHdpdGhvdXQgZmxhZ3MuLi4gbm8NCmNoZWNraW5n
IGZvciBtb2MuLi4gL3Vzci9saWIvcXQtMy4wLjUvYmluL21vYw0KY2hlY2tpbmcgZm9yIHVp
Yy4uLiAvdXNyL2xpYi9xdC0zLjAuNS9iaW4vdWljDQpjaGVja2luZyB3aGV0aGVyIHVpYyBz
dXBwb3J0cyAtTCAuLi4geWVzDQpjaGVja2luZyB3aGV0aGVyIHVpYyBzdXBwb3J0cyAtbm91
bmxvYWQgLi4uIHllcw0KY2hlY2tpbmcgaWYgUXQgbmVlZHMgLWxqcGVnLi4uIG5vDQpjaGVj
a2luZyBmb3IgcnBhdGguLi4geWVzDQpjaGVja2luZyBmb3IgS0RFLi4uIGNvbmZpZ3VyZTog
ZXJyb3I6DQppbiB0aGUgcHJlZml4LCB5b3UndmUgY2hvc2VuLCBhcmUgbm8gS0RFIGhlYWRl
cnMgaW5zdGFsbGVkLiBUaGlzIHdpbGwgZmFpbC4NClNvLCBjaGVjayB0aGlzIHBsZWFzZSBh
bmQgdXNlIGFub3RoZXIgcHJlZml4IQ0KDQoNClBsZWFzZSwgbGV0IG1lIGtub3cgd2hhdCBJ
IGFtIGRvaW5nIHdyb25nIGhlcmUuIEkganVzdCBob3BlIEkgd29uJ3QgaGF2ZSB0bw0KcmVj
b21waWxlIEtERSBsb2NhbGx5IGhlcmUuIEkgd291bGQgYWxzbyBsaWtlIHRvIGluc3RhbGwg
a2NhY2hlZ3JpbmcgaW4gYQ0KZGlmZmVyZW50IChzaGFyZWQgbmV0d29yaykgZGlyZWN0b3J5
LCB3aGVyZSB0aGVyZSBhcmUgZGVmaW5pdGVseSBubyBLREUNCmFydGlmYWN0cyAtIGl0IHRo
YXQgaW1wb3NzaWJsZT8NCg0KVGhhbmtzIGZvciB5b3VyIGhlbHAhDQoNCkFsZXgNCg0KLS0N
CkFsZXggRy4gSXZlcnNoZW4gICAgICAgICAgICAgICAgICAgICAgICAgICAgSW5ldCBUZWNo
bm9sb2dpZXMsIEluYy4NCk5ldHdvcmsgUHJvZHVjdHMgRGVwdC4gICAgICAgICAgICAgICAg
ICAgICAgMTUwMCBOLiBHcmVlbnZpbGxlIEF2ZS4NCkluZXQgVGVjaG5vbG9naWVzIEluYy4g
ICAgICAgICAgICAgICAgICAgICAgUmljaGFyZHNvbiwgVFggNzUwODENClBob25lOiArMS00
NjktMzMwLTQyOTUgICAgICAgICAgICAgICAgICAgICAgVVNBDQoNCg0K

Re: [Valgrind-users] New valgrind version has problems with valgrind-calltree.

[Mathieu M. <Mat...@cr...>]

There is a new version for valgrind-20030716, please go to:

http://kcachegrind.sourceforge.net/

HTH
mathieu

Andrés Roldán wrote:
> Hi Julian, list.
> 
> I am the current valgrind maintainer for the Debian Project. I've uploaded a
> Debian version of valgrind-20030716 which, quoting you, can be considered
> stable.
> 
> Well, Philipp Frauenfelder <pfr...@de...> is maintaining the skin called 
> valgrind-calltree but he could not use it anymore with this new valgrind version.
> 
> What can we do about that? Is there any consideration to have in mind to get this
> skin working again?
> 
> I've attached the Philipp's email that shows clearly the problem.
> 
> Thanks in advance.
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> Subject:
> Re: New valgrind version.
> From:
> Philipp Frauenfelder <pfr...@de...>
> Date:
> Fri, 18 Jul 2003 21:29:50 +0200
> To:
> Andrés Roldán <ar...@fl...>
> 
> 
> Dear Andrés
> 
> Am Fri, Jul 18, 2003 at 11:08:14AM -0500 hat Andrés Roldán getippert:
> 
>>I will upload a new valgrind version today.
> 
> 
> Thanks for telling me.
> 
> 
>>Maybe you may want to take
>>a look to it since valgrind-calltree depends on it. Sources are as follow:
> 
> 
> I recompiled the calltree skin (necessary since API changed) and
> it does not work for me:
> 
> ----------------------------8<--------------
> $ calltree ls
> ==9537== Calltree-0.9.1, a cache profiler for x86-linux.
> ==9537== Copyright (C) 2002, and GNU GPL'd, by N.Nethercote and J.Weidendorfer.
> ==9537== Using valgrind-20030716, a program supervision framework for x86-linux.==9537== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward.
> ==9537== Estimated CPU clock rate is 1426 MHz
> ==9537== For more details, rerun with: -v
> ==9537==
> Instruction failed sanity check:
>            1: CALLMo            t4              [abcdSD]
> opcode:          68
> lit32:           0x4001F4F5
> size:            0
> val1,val2,val3:  4, 0, 0
> tag1,tag2,tag3:  0, 7, 7
> flags_r:         0x0
> flags_w:         0x0
> extra4b:         0x0
> cond:            0x0
> signed_widen:    0
> jmpkind:         0
> argc,regparms_n: 1, 1
> has_ret_val:     0
> regs_live_after: [abcdSD]
>  
> valgrind: vg_translate.c:658 (vgPlain_saneUCodeBlock): Assertion sane' failed.
>  
> sched status:
>  
> Thread 1: status = Runnable, associated_mx = 0x0, associated_cv = 0x0
> ==9537==    at 0x40080B7C: (within /usr/lib/valgrind/valgrind.so)
> ==9537==    by 0x4000972A: call_init (in /lib/ld-2.3.1.so)
> ==9537==    by 0x400097BF: _dl_init_internal (in /lib/ld-2.3.1.so)
> ==9537==    by 0x40000B3C: (within /lib/ld-2.3.1.so)
>  
>  
> Note: see also the FAQ.txt in the source distribution.
> It contains workarounds to several common problems.
>  
> If that doesn't help, please report this bug to: js...@ac...
>  
> In the bug report, send all the above text, the valgrind
> version, and what Linux distro you are using.  Thanks.
> ----------------------------8<--------------
> 
> I guess I will upload an old version which conflicts with the
> new valgrind.
> 
> Regards
> 
> 
> ------------------------------------------------------------------------
> 
> 
> 


-- 
Mathieu Malaterre
CREATIS
28 Avenue du Doyen LEPINE
B.P. Lyon-Montchat
69394 Lyon Cedex 03
http://www.creatis.insa-lyon.fr/~malaterre/

Re: [Valgrind-users] baffled by vg output

[Tristan V. B. <va...@to...>]

Paul Pluzhnikov wrote:

>Nicholas Nethercote wrote:
>
>  
>
>>Since the memory is within a malloc'd block (so says the 2nd part of
>>the message) it should be addressable.  But you say it's also
>>initialised.
>>    
>>
>
>It is possible that the memory *was* initialized at some point, 
>but no longer is at the time of the syscall. E.g.
>
>int main()
>{
>   char buf[8];
>   int x;
>
>   memset(buf, 'a', sizeof(buf));
>   *(int *)buf = x; /* oops -- buf is "uninitialized" again */
>   write(1, buf, sizeof(buf));
>
>   return 0;
>}
>
>  
>
Good point. I found my bug by now but still dont know the connection to the
"unaddressable bytes" exactly (I had a race condition where I was recieving
old packets and mistaking them for a "synchronous response") I have a 
feeling
the VG message had something to do with variable length packet 
structures but
thats just a guess.

Thanks all,
                        -Tristan

[Valgrind-users] Re: Wierdness with LD_LIBRARY_PATH Mashing

[Lee K. <lki...@cs...>]

Nicholas Nethercote writes:
 > On Mon, 21 Jul 2003, Lee Kindness wrote:
 > > Guys, have been seeing so real wiredness with VG 1.9.6 and in the
 > > recently released snapshot.
 > >
 > >  *** env.sorted  2003-07-21 10:42:25.000000000 +0100
 > >  --- env-vg.sorted       2003-07-21 10:42:11.000000000 +0100
 > >  ***************
 > >  *** 8,14 ****
 > >  ! LD_LIBRARY_PATH=/home/lofs/lofs_1.1.4-20030721a/lib:
 > >  --- 8,16 ----
 > >  ! LD_LIBRARY_PATH=                         /home/lofs/lofs_1.1.4-20030721a/lib:
 > >  ***************
 > >  *** 23,32 ****
 > >
 > > Note the spaces before LD_LIBRARY_PATH - this is causing the libraries
 > > to be missed! Something up with the "mashing" that is done? Currently
 > > the script only adds to LD_LIBRARY_PATH if the appropriate path isn't
 > > already there - changing this to always setup LD_LIBRARY_PATH from
 > > scratch causes the binary to run as expected.
 > 
 > Yes, Valgrind adds an entry to the start of LD_LIBRARY_PATH, and then
 > blanks it out for any child processes.  This leaves a big hole in the
 > result, as above.  A similar thing is done with LD_PRELOAD.
 > 
 > I thought this (having blanks present) was acceptable, but maybe not?  I
 > can fix it if it's incorrect.

No, the blanks kill the library search mechanism - it's looking for
the paths exactly as specified, including the leading whitespace.

If you leave the ':' separator in when mashing, ie: LD_LIBRARY_PATH
would be:

 LD_LIBRARY_PATH=                        :/home/lofs/lofs_1.1.4-20030721a/lib:

then everything is fine since the whitespace is tacked onto a valid
path, but rather is "on its own".

I'm guessing though that this behaviour may be a recent addition to
glibc - i've certainly seen my program and valgrind work as expected
before!

Thanks for the quick response.

L.

[Valgrind-users] Re: Wierdness with LD_LIBRARY_PATH Mashing

[Nicholas N. <nj...@ca...>]

On Mon, 21 Jul 2003, Lee Kindness wrote:

> Guys, have been seeing so real wiredness with VG 1.9.6 and in the
> recently released snapshot.
>
>  *** env.sorted  2003-07-21 10:42:25.000000000 +0100
>  --- env-vg.sorted       2003-07-21 10:42:11.000000000 +0100
>  ***************
>  *** 8,14 ****
>  ! LD_LIBRARY_PATH=/home/lofs/lofs_1.1.4-20030721a/lib:
>  --- 8,16 ----
>  ! LD_LIBRARY_PATH=                         /home/lofs/lofs_1.1.4-20030721a/lib:
>  ***************
>  *** 23,32 ****
>
> Note the spaces before LD_LIBRARY_PATH - this is causing the libraries
> to be missed! Something up with the "mashing" that is done? Currently
> the script only adds to LD_LIBRARY_PATH if the appropriate path isn't
> already there - changing this to always setup LD_LIBRARY_PATH from
> scratch causes the binary to run as expected.

Yes, Valgrind adds an entry to the start of LD_LIBRARY_PATH, and then
blanks it out for any child processes.  This leaves a big hole in the
result, as above.  A similar thing is done with LD_PRELOAD.

I thought this (having blanks present) was acceptable, but maybe not?  I
can fix it if it's incorrect.

N

[Valgrind-users] Re: Support for clone(2)...

[Adam G. <ar...@cy...>]

At 11:50 18/07/2003 -0700, Jeremy Fitzhardinge <je...@go...> wrote:

>On Fri, 2003-07-18 at 06:48, Daniel Blueman wrote:
>> This app uses:
>> 
>> res = __clone(lwp, stack + STACK_SIZE,
>>     CLONE_VM | CLONE_FS | CLONE_FILES | CLONE_SIGHAND,
>>     (void *) ctx)) == -1);
>> 
>> Perhaps this is a varient that valgrind does not support?
>
>Valgrind does not currently support any variant of clone.  We are
>considering adding clone support, but I don't think it will be possible
>to do all (or even many) of the possible combinations of CLONE_* flags -
>but fortunately it seems that something like the flag set above would
>cover almost all real uses of clone().

the WINE variant of valgrind _does_ have support for clone(). currently
it only supports CLONE_VM | CLONE_FS | CLONE_FILES (not CLONE_SIGHAND).

I'm not sure if it could be made to support CLONE_SIGHAND easily.


Seeya,
 Adam
--
Real Programmers don't comment their code. If it was hard to write,
it should be hard to read, and even harder to modify.
These are all my own opinions.

[Valgrind-users] Wierdness with LD_LIBRARY_PATH Mashing

[Lee K. <lki...@cs...>]

Guys, have been seeing so real wiredness with VG 1.9.6 and in the
recently released snapshot.

Background: I've got a threaded server which in turn also forks off
clients to "process" files. The fork actually calls a script which in
turn sets up the environment and then calls the appropriate binary.

Now, the binary was failing to load its shared libraries. I've dumped
out the environment outwith vg, and within the script (which is now
running "under" vg, but withut the follow child option), the
differences:

 *** env.sorted  2003-07-21 10:42:25.000000000 +0100
 --- env-vg.sorted       2003-07-21 10:42:11.000000000 +0100
 ***************
 *** 8,14 ****
   HOSTTYPE=i386-linux
   LAMHELPFILE=/etc/lam/lam-helpfile
   LANG=en_GB.UTF-8
 ! LD_LIBRARY_PATH=/home/lofs/lofs_1.1.4-20030721a/lib:
   LESSOPEN=|/usr/bin/lesspipe.sh %s
   LOFS_DATA_DIR=/home/lofs
   LOFS_HOME_DIR=/home/lofs/lofs_1.1.4-20030721a
 --- 8,16 ----
   HOSTTYPE=i386-linux
   LAMHELPFILE=/etc/lam/lam-helpfile
   LANG=en_GB.UTF-8
 ! LD_ASSUME_KERNEL=2.2.5
 ! LD_LIBRARY_PATH=                         /home/lofs/lofs_1.1.4-20030721a/lib:
 ! LD_PRELOAD=                                            /usr/mlocal/lib/valgrind/valgrinq.so:
   LESSOPEN=|/usr/bin/lesspipe.sh %s
   LOFS_DATA_DIR=/home/lofs
   LOFS_HOME_DIR=/home/lofs/lofs_1.1.4-20030721a
 ***************
 *** 23,32 ****
   PWD=/home/lofs
   QTDIR=/usr/lib/qt-3.1
   SHELL=/bin/tcsh
 ! SHLVL=1
   SSH_ASKPASS=/usr/libexec/openssh/gnome-ssh-askpass
   SUPPORTED=en_GB.UTF-8:en_GB:en
   TERM=xterm
   USER=lofs
   VENDOR=intel
 ! XAUTHORITY=/home/lofs/.xauthp1zf4n
 --- 25,35 ----
   PWD=/home/lofs
   QTDIR=/usr/lib/qt-3.1
   SHELL=/bin/tcsh
 ! SHLVL=2
   SSH_ASKPASS=/usr/libexec/openssh/gnome-ssh-askpass
   SUPPORTED=en_GB.UTF-8:en_GB:en
   TERM=xterm
   USER=lofs
   VENDOR=intel
 ! VG_ARGS= --suppressions=/usr/mlocal/lib/valgrind/default.supp  --num-callers=10
 ! XAUTHORITY=/home/lofs/.xauth2aTeKl

Note the spaces before LD_LIBRARY_PATH - this is causing the libraries
to be missed! Something up with the "mashing" that is done? Currently
the script only adds to LD_LIBRARY_PATH if the appropriate path isn't
already there - changing this to always setup LD_LIBRARY_PATH from
scratch causes the binary to run as expected.

System is Red Hat 9:

 Linux kelvin 2.4.20-9 #1 Wed Apr 2 13:42:50 EST 2003 i686 i686 i386 GNU/Linux

Thanks, Lee.

Re: [Valgrind-users] README_MISSING_SYSCALL_OR_IOCTL out of date with V 1.9.6

[Nicholas N. <nj...@ca...>]

On Tue, 8 Jul 2003, Anne Dudfield wrote:

> Very very small point but could be important for someone new to
> Valgrind -- I had to do some hunting to figure out how to change my
> personalized IOCTLs from 1.0.x. (I use Valgrind on click, which is
> custom packet handling software with a Linux kernel-loadable module
> that defines several of its own IOCTLs.)
>
> "README_MISSING_SYSCALL_OR_IOCTL" still talks about calling
> "must_be_readable" and "must_be_writable". It looks like these should
> be changed to SYSCALL_TRACK(pre_mem_read, ...) and
> SYSCALL_TRACK(pre_mem_write, ...).

Yes, that's been fixed in the latest version (20030716).  Thanks for the
report.

> One question: What's the difference between 'pre_mem_read' and
> 'pre_mem_read_asciiz'?

'pre_mem_read_asciiz' indicates memory is being read which is a string,
ie. a null-terminated sequence of chars;  usually a pathname.
'pre_mem_read' is for any other block of memory being read, which usually
(always?) requires an accompanying size argument.

N

Re: [Valgrind-users] Supressing leaks in mbsrtowcs glibc-2.2.5

[Nicholas N. <nj...@ca...>]

On Mon, 21 Jul 2003, Michael B Allen wrote:

> > It's unfortunate that the functions at the top of the stack trace are so
> > generic in this case, but hopefully it won't matter.
>
> That might exclude all memory allocated by calloc!

Why?  If you only put a single function in the suppression, yes, but if
you put four it should be ok, no?

> Is it completely infeasible to collect the violations and then walk each
> stack trace looking for matches? Provided the matching occured after the
> run was completed such a thing would not impact runtime performace.

Waiting until the run ended is not feasible -- what if Memcheck waited
until the end of the run before telling you that your program was about to
seg fault?

More complex suppression/stack trace matching is possible at runtime. But
there hasn't been much call for it so far, however, and we don't like
adding complexity without good reason.  (I guess this is the opportunity
for everybody who has found the current suppression format too
restrictive, but never said anything, to speak up...)

N

Re: [Valgrind-users] Supressing leaks in mbsrtowcs glibc-2.2.5

[Michael B A. <mb...@io...>]

> It's unfortunate that the functions at the top of the stack trace are so
> generic in this case, but hopefully it won't matter.
>
> N

That might exclude all memory allocated by calloc!

Is it completely infeasible to collect the violations and then walk each
stack trace looking for matches? Provided the matching occured after the
run was completed such a thing would not impact runtime performace.

This makes me think of a neat piece of code I found somewhere. It does
simple dos like wildcard marching. See the attached file with function
wildcmp. If the input was an array of symbols (or some value representing
the symbols) instead of an array of characters and the pattern was an
array of symbols with every other element effectively being a '*' you
could have a pretty sophisticated stack trace matching algorithm.

Mike

Re: [Valgrind-users] baffled by vg output

[<pa...@pa...>]

Nicholas Nethercote wrote:

> Since the memory is within a malloc'd block (so says the 2nd part of
> the message) it should be addressable.  But you say it's also
> initialised.

It is possible that the memory *was* initialized at some point, 
but no longer is at the time of the syscall. E.g.

int main()
{
   char buf[8];
   int x;

   memset(buf, 'a', sizeof(buf));
   *(int *)buf = x; /* oops -- buf is "uninitialized" again */
   write(1, buf, sizeof(buf));

   return 0;
}

Re: [Valgrind-users] baffled by vg output

[Nicholas N. <nj...@ca...>]

On Wed, 16 Jul 2003, Tristan Van Berkom wrote:

> firstly, maybe there is an available FAQ for understanding vg output ?

The user docs has some info:  see
developer.kde.org/~sewardj/docs-1.9.5/mc_main.html#mc-top, the section
"Explanation of errors from Memcheck".


> ==1854== Syscall param socketcall.sendto(msg) contains uninitialised or
> unaddressable byte(s)
> ==1854==    at 0x408E2D92: __libc_sendto (in /lib/libc-2.1.3.so)
> ==1854==    by 0x40815AA6: trans_send (in
> /usr/local/touchtunes/lib/libttipc.so.0.0.0)
> ==1854==    by 0x40813D63: evts_send (in
> /usr/local/touchtunes/lib/libttipc.so.0.0.0)
> ==1854==    by 0x40814A0F: sync_call (in
> /usr/local/touchtunes/lib/libttipc.so.0.0.0)
>
> the "msg" param in my case is definitly initialized (even added memset
> to be sure). now what could be meant by "unaddressable bytes" ? could
> this be a result of sending a message of 63 bytes instead of 64 (meaning
> only one of every 4 bytes is "truely addressable") ? I'm not feeding
> `sendto' any register variables if thats what it is supposed to mean.
>
> ==1854==    Address 0x42193CB0 is 60 bytes inside a block of size 63 alloc'd
> ==1854==    at 0x40166498: malloc (in /usr/lib/valgrind/valgrind.so)
> ==1854==    by 0x40815A2E: trans_send (in
> /usr/local/touchtunes/lib/libttipc.so.0.0.0)
> ==1854==    by 0x40813D63: evts_send (in
> /usr/local/touchtunes/lib/libttipc.so.0.0.0)
> ==1854==    by 0x40814A0F: sync_call (in
> /usr/local/touchtunes/lib/libttipc.so.0.0.0)
>
> and this is what follows directly after the previous message.
> funny, ("0x42193CB0" - ( decimal 60 )) == "0x42193C74"
> which happens to be the pointer to my 63 byte long message.
> Is there something wrong with address 0x42193CB0 ? why are my trailing
> 3 bytes no good or "nonaddressable" ?
>
> might as well have said that:
>      "Address 0x42193CB1 is 61 bytes inside a block of size 63 alloc'd"

The two parts of the error go together, the first part tells you where in
the code it happens (in this case the actual line isn't identified because
it's in a library that has had debug info stripped), the second tells you
what memory is uninitialised/unaddressable (the byte or bytes starting at
0x42193CB0) and how/where that memory was allocated.

Since the memory is within a malloc'd block (so says the 2nd part of the
message) it should be addressable.  But you say it's also initialised.  A
quick way to find out whether it's unaddressable or uninitialised is to
try the "Addrcheck" skin -- run "valgrind --skin=addrcheck ...".
Addrcheck only detects addressibility errors so that will tell you whether
you have an addressability or uninitialised problem.  Without the code for
the program, it's hard to tell any more than that.  If you can reduce your
program down to a small, complete example and post that, that would be
very helpful.

N

Re: [Valgrind-users] Supressing leaks in mbsrtowcs glibc-2.2.5

[Nicholas N. <nj...@ca...>]

On Tue, 15 Jul 2003, Michael B Allen wrote:

> There are leaks in mbsrtowcs in my glibc-2.2.5:
>
> ==19983== 564 bytes in 1 blocks are still reachable in loss record 5 of 5
> ==19983==    at 0x40166CCD: calloc (vg_clientfuncs.c:245)
> ==19983==    by 0x40008A0B: _dl_new_object (in /lib/ld-2.2.5.so)
> ==19983==    by 0x400049EE: _dl_map_object_from_fd (in /lib/ld-2.2.5.so)
> ==19983==    by 0x40005DB6: _dl_map_object_internal (in /lib/ld-2.2.5.so)
> ==19983==    by 0x42112187: dl_open_worker (in /lib/i686/libc-2.2.5.so)
> ==19983==    by 0x4000B4B2: _dl_catch_error_internal (in /lib/ld-2.2.5.so)
> ==19983==    by 0x42112760: _dl_open (in /lib/i686/libc-2.2.5.so)
> ==19983==    by 0x42113490: do_dlopen (in /lib/i686/libc-2.2.5.so)
> ==19983==    by 0x4000B4B2: _dl_catch_error_internal (in /lib/ld-2.2.5.so)
> ==19983==    by 0x4211333B: __libc_dlopen (in /lib/i686/libc-2.2.5.so)
> ==19983==    by 0x4202028B: __gconv_find_shlib (in /lib/i686/libc-2.2.5.so)
> ==19983==    by 0x4201FC34: find_module (in /lib/i686/libc-2.2.5.so)
> ==19983==    by 0x4201FEAE: __gconv_lookup_cache (in /lib/i686/libc-2.2.5.so)
> ==19983==    by 0x42019498: __gconv_find_transform (in
> /lib/i686/libc-2.2.5.so)
> ==19983==    by 0x420A56B8: __wcsmbs_load_conv (in /lib/i686/libc-2.2.5.so)
> ==19983==    by 0x420877DD: __mbsrtowcs (in /lib/i686/libc-2.2.5.so)
> ==19983==    by 0x4022841C: cfg_load_env (src/cfg.c:234)
> ==19983==    by 0x410471C2: ???
> ==19983==    by 0x8048E62: run_suite (tmba.c:73)
> ==19983==    by 0x80491B7: main (tmba.c:135)
>
> I tried to add the following to /usr/local/lib/valgrid/default.supp:
>
> {
>    test
>    Memcheck:Cond
>    fun:__mbsr*
> }
>
> but it had no effect. How do I supress these messages?

The error type is "Leak", not "Cond".

The stack trace in suppressions must contain the top 1,2,3, or 4 functions
in the call trace, not just one from the middle.

Try this:

{
    test
    Memcheck:Leak
    fun:calloc
    fun:_dl_new_object
    fun:_dl_map_object_from_fd
    fun:_dl_map_object_internal
}

I think that's right.

Or use the --gen-suppression=yes option in the new 20030716 snapshot (from
developer.kde.org/~sewardj).

It's unfortunate that the functions at the top of the stack trace are so
generic in this case, but hopefully it won't matter.

N

Re: [Valgrind-users] float cast

[Nicholas N. <nj...@ca...>]

On Thu, 10 Jul 2003, ragnar sjoberg wrote:

> Thanks for the help, I've upgraded to 1.9.6,
> but valgrind still gives the same result.

I tried your program with the current CVS head, and I get no errors.
Maybe it depends which version of gcc you use.

Can you reduce your program to the smallest two versions that show the
different behaviours, and then post the (complete) assembly code for them?
That will give us a better chance of working out what the problem is.

N



>
> Considering the following code:
> int
> main (int argc, char **argv)
> {
> float e;
>
>   e = 0;
>   e = e * (float)0.7;
>
>   return 0;
> }
>
>
> Gcc treats:
> float e;
>   e = e * 0.7;
> differently from :
> e = e * (float)0.7;
>
> As is shown in this assembler output,
> when toggling first with the (float) cast
> then without:
> ---------------
> .section        .rodata
>         .align 4
> .LC0:
>         .long 0x3f333333
> .text
>         .align 4
> <snip>
>         flds .LC0
>         fmulp %st,%st(1)
>
> --------------
>
> .section        .rodata
>         .align 8
> .LC0:
>         .long 0x66666666,0x3fe66666
> .text
>         .align 4
> <snip>
>         fldl .LC0
>         fmulp %st,%st(1)
> -------
>
> My guess is the first assembler output
> is using single-precision, and the second
> defaults to double ?
>
> So the func.c/prog.c should use double-precision correctly I assume ?
>
> Still, is there a error in the func.c/prog.c program, that valgrind thinks ?
>
> thanks
> Ragnar
>
>
> ___________________________________________________
> Who invented the Centigrade scale of temperature?
>
> Find out at postmaster.co.uk
>
> http://www.postmaster.co.uk/cgi-bin/meme/quiz.pl?id=196
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Parasoft
> Error proof Web apps, automate testing & more.
> Download & eval WebKing and get a free book.
> www.parasoft.com/bulletproofapps
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>

Re: [Valgrind-users] Basic question on Valgrind.

[Igmar P. <mai...@jd...>]

>   My program runs perfectly fine when run with
> valgrind. But dumps on Sig11 when run without it. How
> do I find out where the problem is.

1) Compile app with -g
2) gdb executable

in gdb : 'run' as command

when it crashes, type 'where'
 



	Igmar

Re: [Valgrind-users] Basic question on Valgrind.

[Bastien C. <ba...@ch...>]

On Saturday 19 July 2003 11:18, Vijeth Bhat wrote:
>   My program runs perfectly fine when run with
> valgrind. But dumps on Sig11 when run without it. How
> do I find out where the problem is.

I remember that sig11 one of those things that one doesn=B4t want to see at=
 all=20
as cases I saw had RAM problems. After a quick search
     http://www.google.com/search?q=3Dsig11
I think you'd like to read at least this page
     http://www.bitwizard.nl/sig11/

But perhaps I=B4m all wrong here.

Salut,
  Bastien

=2D-=20
        -- The universe has its own cure for stupidity. --
         -- Unfortunately, it doesn't always apply it. --

[Valgrind-users] Basic question on Valgrind.

[Vijeth B. <vi...@ya...>]

Hi all,
  My program runs perfectly fine when run with
valgrind. But dumps on Sig11 when run without it. How
do I find out where the problem is.

Thanks and Regards,
 Vijeth

__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

[Valgrind-users] Re: Valgrind-users -- confirmation of subscription -- request 475851

[mblsha <mai...@ma...>]

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

val...@li... wrote:
> Valgrind-users -- confirmation of subscription -- request 475851
>
> We have received a request from 62.118.155.23 for subscription of your
> email address, <mai...@ma...>, to the
> val...@li... mailing list.  To confirm the
> request, please send a message to
> val...@li..., and either:
>
> - maintain the subject line as is (the reply's additional "Re:" is
> ok),
>
> - or include the following line - and only the following line - in the
> message body:
>
> confirm 475851
>
> (Simply sending a 'reply' to this message should work from most email
> interfaces, since that usually leaves the subject line in the right
> form.)
>
> If you do not wish to subscribe to this list, please simply disregard
> this message.  Send questions to
> val...@li....


=2D --=20
 Michail "mblsha" Pishchagin - MAZsoft
mb...@us... - http://maz.sf.net

Plato, by the way, wanted to banish all poets from his proposed Utopia
because they were liars.  The truth was that Plato knew philosophers
couldn't compete successfully with poets.
		-- Kilgore Trout (Philip J. Farmer), "Venus on the Half Shell"
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE/GMr55mhuYpsVoGwRAlq4AJ4siOfHI9bCp1gPxNPAp1UWYAwFoACg425X
houfgs18sXAJp2MKD3naTQ0=3D
=3DpCNK
=2D----END PGP SIGNATURE-----

Re: [Valgrind-users] Support for clone(2)...

[Jeremy F. <je...@go...>]

On Fri, 2003-07-18 at 06:48, Daniel Blueman wrote:
> This app uses:
> 
> res = __clone(lwp, stack + STACK_SIZE,
>     CLONE_VM | CLONE_FS | CLONE_FILES | CLONE_SIGHAND,
>     (void *) ctx)) == -1);
> 
> Perhaps this is a varient that valgrind does not support?

Valgrind does not currently support any variant of clone.  We are
considering adding clone support, but I don't think it will be possible
to do all (or even many) of the possible combinations of CLONE_* flags -
but fortunately it seems that something like the flag set above would
cover almost all real uses of clone().

	J

Re: [Valgrind-users] Support for clone(2)...

[Daniel B. <dan...@gm...>]

This app uses:

res = __clone(lwp, stack + STACK_SIZE,
    CLONE_VM | CLONE_FS | CLONE_FILES | CLONE_SIGHAND,
    (void *) ctx)) == -1);

Perhaps this is a varient that valgrind does not support?

Dan

> On Thu, 2003-07-17 at 07:40, Daniel Blueman wrote:
> > Is support for the clone() syscall planned for valgrind at any stage?
> > 
> > Valgrind-20030716 seems to be better than ever, and is such a powerful
> tool!
> > Just that it can't go on when hitting a clone() it seems.
> 
> What sort of clone()?  If you're threading with a thread library V
> should never see them, so I'm guessing you're doing something special. 
> What flags are you passing to clone()?
> 
> 	J
> 

-- 
Daniel J Blueman

+++ GMX - Mail, Messaging & more  http://www.gmx.net +++

Jetzt ein- oder umsteigen und USB-Speicheruhr als Prämie sichern!

[Valgrind-users] using calltree

[Mathieu M. <Mat...@cr...>]

Hi valgrind hackers,
    I wanted to profile my program thus I tried kcachegrind, but I get 
this error while using calltree:


Calltree: ct_main.c:4028 (setup_bbcc): Assertion 
`fn_active_array[fn_number] == 1' failed.

sched status:

Thread 1: status = Runnable, associated_mx = 0x0, associated_cv = 0x0
==9586==    at 0x40153C26: _init (in /usr/local/lib/libkgfo.so.1.1.1)
==9586==    by 0x4000B781: _dl_init_internal (in /lib/ld-2.2.5.so)
==9586==    by 0x40000B8C: (within /lib/ld-2.2.5.so)



Does anyone knows how to work around this,
Thanks,
mathieu

OS: Linux RedHat 7.3
Valgrind 1.9.6
calltree 0.9.1

Re: [Valgrind-users] Re: [Helgrind] Segfault -> mallocSanityCheckArena

[Jeremy F. <je...@go...>]

On Thu, 2003-07-17 at 12:21, Tangi Vass wrote:
> > Excellent!  I'd be interested to know what your real bug:false bug ratio
> > is.  It seems to me that helgrind is a bit sensitive to false positives,
> > but I haven't tried it on many real programs.  I'd also be interested in
> > what classes of errors hit you most (races vs. lock ordering).
> 
> I might have found an interesting false bug family.
> Consider:
> - thread A producing sets of data
> - thread B using these
> - a ref counted MT-safe global smart pointer to pass those sets from
> thread A to thread B.
> 
> It seems like Helgrind complains about the fact that thread B is
> deleting (because of the ref-counted mechanism) data created by thread A
> as no common mutex was locked during filling and emptying of the sets. A
> mutex is locked only during the ownership tranfer between thread A and
> B.
> 
> As I've got tons of data, each piece producing such a data race writing
> warning, I can harly see the others.

Yes, that's the prime source of false error reports from helgrind. 
There are two ways in which false errors can arise here:
     1. If your MT-safe smart pointer library is using atomic
        instructions for manipulating the count (rather than
        pthread_mutex), which is likely, then I don't think helgrind
        will realize it is a safe operation.  You could use
        VALGRIND_HG_KNOWN_RACE(&refcount, sizeof(refcount)) when
        initializing the refcount in each object so that helgrind won't
        bother reporting "problems" with the refcount.
     2. The ownership transfer.  You can use VALGRIND_HG_CLEAN_MEMORY to
        reset your object's memory state so that the new thread will
        become the owner of the memory.  If you have many places in
        which the ownership transfer happens, this might not be
        practical (but if there's one site which does 90% of the
        transfers, that would cut your noise level a lot).

> That's of course only how I figure out the problem but being a very new
> user of Valgrind/helgrind, I may say stupid things. 

Helgrind is a relatively new skin, it *does* say many stupid things.

	J

Re: [Valgrind-users] Re: [Helgrind] Segfault -> mallocSanityCheckArena

[Tangi V. <tan...@co...>]

> Excellent!  I'd be interested to know what your real bug:false bug ratio
> is.  It seems to me that helgrind is a bit sensitive to false positives,
> but I haven't tried it on many real programs.  I'd also be interested in
> what classes of errors hit you most (races vs. lock ordering).

I might have found an interesting false bug family.
Consider:
- thread A producing sets of data
- thread B using these
- a ref counted MT-safe global smart pointer to pass those sets from
thread A to thread B.

It seems like Helgrind complains about the fact that thread B is
deleting (because of the ref-counted mechanism) data created by thread A
as no common mutex was locked during filling and emptying of the sets. A
mutex is locked only during the ownership tranfer between thread A and
B.

As I've got tons of data, each piece producing such a data race writing
warning, I can harly see the others.

The idea of comparing locked mutexes between two "concurrent" writes of
data is bright but in many cases a thread may have lost his reference to
a data when another is modifying it (because of ownership transfer).

That's of course only how I figure out the problem but being a very new
user of Valgrind/helgrind, I may say stupid things. 

Tangi

Re: [Valgrind-users] Re: [Helgrind] Segfault -> mallocSanityCheckArena

[Jeremy F. <je...@go...>]

On Thu, 2003-07-17 at 09:43, Tangi Vass wrote:
> > Can you send me your test program?
> 
> I just upgraded to release 20030716 and I'm now able to go further with
> helgrind if I don't attach gdb (which seems to start much before the
> segfault).

Hm.

>  Found plenty of data race writings in my code.

Excellent!  I'd be interested to know what your real bug:false bug ratio
is.  It seems to me that helgrind is a bit sensitive to false positives,
but I haven't tried it on many real programs.  I'd also be interested in
what classes of errors hit you most (races vs. lock ordering).

> My test suite is quite big and needs many libraries. I'll try a bit
> further and send you the whole package when I can reproduce it at will
> again.

Hm, OK.  The last time this crashing bug came up it was with a large
complex thing as well.  I'm hoping that there's a relatively simple way
of reproducing it.

	J