valgrind-users — General discussion list for Valgrind users

Re: [Valgrind-users] problem debugging mysql code...

[Diego T. <dtg...@te...>]

Thanks for the hint :) now everything is working fine (once i've
reimplemented the functions that were causing me some troubles).

So my program ends with exit without problems (?) but then:

--3557-- Caught __NR_exit; running __libc_freeres()
SYSCALL[3557,1]( 91): munmap ( 0x0, 0 )
==3557== Invalid read of size 1
==3557==    at 0x4034B45B: _dl_close (in /lib/libc-2.3.1.so)
==3557==    by 0x4034BE6E: (within /lib/libc-2.3.1.so)
==3557==    by 0x400095BD: _dl_catch_error_internal (in /lib/ld-2.3.1.so)
==3557==    by 0x4034BDB4: (within /lib/libc-2.3.1.so)
==3557==    Address 0x1E7 is not stack'd, malloc'd or free'd

And yes, i'm using some dynamic loaded libraries and closing them without
errors. So, is there a bug on valgrind 1.9.6 (from debian) and libc-2.3.1?
Because valgrind also exits with a segmentation fault. So, who is munmaping
0x0?. any idea?

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

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

> 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). Found plenty of data race writings in my code.

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.

Tangi

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

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

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

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

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

On Thu, 2003-07-17 at 06:02, Tangi Vass wrote:
> Hi,
> 
> I've got the same issue :
> - helgrind with default sanity-level : data race writing outside my code
> - helgrind with sanity-level=2 : valgrind: the `impossible' happened:
> mallocSanityCheckArena
> - memcheck : nothing reported except KLUDGED & IGNORED calls within
> libpthread.so
> 
> Details below.

Can you send me your test program?

	J

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

[Dirk M. <dm...@gm...>]

On Don, 17 Jul 2003, Daniel Blueman wrote:

> Is support for the clone() syscall planned for valgrind at any stage?

is this a ptread app or a NPTL one?


-- 
Dirk

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

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

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.

Please CC replies to me, as I'm not subscribed.

Many thanks!

-- 
Daniel J Blueman

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

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

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

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

Hi,

I've got the same issue :
- helgrind with default sanity-level : data race writing outside my code
- helgrind with sanity-level=2 : valgrind: the `impossible' happened:
mallocSanityCheckArena
- memcheck : nothing reported except KLUDGED & IGNORED calls within
libpthread.so

Details below.

Tangi


$ valgrind --skin=helgrind --num-callers=15 test1

==19289== Helgrind, a data race detector for x86-linux.

==19289== Copyright (C) 2002, and GNU GPL'd, by Nicholas Nethercote.

==19289== Using valgrind-1.9.6, a program instrumentation system for
x86-linux.

==19289== Copyright (C) 2000-2002, and GNU GPL'd, by Julian Seward.

==19289== Estimated CPU clock rate is 2002 MHz

==19289== For more details, rerun with: -v

==19289==

==19289== valgrind's libpthread.so: KLUDGED call to:
pthread_getschedparam

==19289== valgrind's libpthread.so: IGNORED call to:
pthread_setschedparam


==19289== valgrind's libpthread.so: IGNORED call to:
pthread_attr_setinheritsched

==19289== valgrind's libpthread.so: IGNORED call to:
pthread_attr_destroy

==19289== Thread 2:

==19289== Possible data race writing variable at 0x400120B0
(_rtld_global+144)

==19289== at 0x40006E0D: _dl_lookup_versioned_symbol_internal (in
/lib/ld-2.2.93.so)

==19289== by 0x4000A01E: fixup (in /lib/ld-2.2.93.so)

==19289== by 0x4000A18F: _dl_runtime_resolve (in /lib/ld-2.2.93.so)

==19289== by 0x4022C41C: thread_wrapper (vg_libpthread.c:671)

==19289== by 0x4009B16B: do__quit (vg_scheduler.c:2154)

==19289== Address 0x400120B0 is in data section of /lib/ld-2.2.93.so

==19289== Previous state: shared RO, no locks




$ valgrind --skin=helgrind --num-callers=15 --sanity-level=2 test1

==21303== Helgrind, a data race detector for x86-linux.

==21303== Copyright (C) 2002, and GNU GPL'd, by Nicholas Nethercote.

==21303== Using valgrind-1.9.6, a program instrumentation system for
x86-linux.

==21303== Copyright (C) 2000-2002, and GNU GPL'd, by Julian Seward.

==21303== Estimated CPU clock rate is 1996 MHz

==21303== For more details, rerun with: -v

==21303==

--21303-- mSC [core ]: 1 sbs, 190 tot bs, 1/1 free bs, 16 lists, 1048576
mmap, 7240 loan

--21303-- mSC [skin ]: 1 sbs, 52 tot bs, 1/1 free bs, 16 lists, 1048576
mmap, 1212 loan

--21303-- mSC [symtab ]: 0 sbs, 0 tot bs, 0/0 free bs, 16 lists, 0 mmap,
0 loan

--21303-- mSC [JITter ]: 0 sbs, 0 tot bs, 0/0 free bs, 16 lists, 0 mmap,
0 loan

--21303-- mSC [client ]: 0 sbs, 0 tot bs, 0/0 free bs, 16 lists, 0 mmap,
0 loan

--21303-- mSC [demangle]: 0 sbs, 0 tot bs, 0/0 free bs, 16 lists, 0
mmap, 0 loan

--21303-- mSC [exectxt ]: 0 sbs, 0 tot bs, 0/0 free bs, 16 lists, 0
mmap, 0 loan

--21303-- mSC [errors ]: 0 sbs, 0 tot bs, 0/0 free bs, 16 lists, 0 mmap,
0 loan

--21303-- mSC [transien]: 0 sbs, 0 tot bs, 0/0 free bs, 16 lists, 0
mmap, 0 loan

blockSane: fail -- redzone-hi

mallocSanityCheckArena: sb 0x405D8000, block 2944 (bszW 10): BAD


valgrind: the `impossible' happened:

mallocSanityCheckArena

Basic block ctr is approximately 50000


sched status:


Thread 1: status = Runnable, associated_mx = 0x0, associated_cv = 0x0

==21303== at 0x4000E448: strcmp (in /lib/ld-2.2.93.so)

==21303== by 0x40006E7B: _dl_lookup_versioned_symbol_internal (in
/lib/ld-2.2.93.so)

==21303== by 0x4000A01E: fixup (in /lib/ld-2.2.93.so)

==21303== by 0x4000A18F: _dl_runtime_resolve (in /lib/ld-2.2.93.so)

==21303== by 0x401C8861: _STL::_Locale_impl::_Locale_impl(char const*)
(in /usr/lib/libstlport_gcc.so.4.5)

==21303== by 0x401C8B3E: _STL::_Locale_impl::make_classic_locale() (in
/usr/lib/libstlport_gcc.so.4.5)

==21303== by 0x401C996A: _STL::locale::_S_initialize() (in
/usr/lib/libstlport_gcc.so.4.5)

==21303== by 0x401C98C4: _STL::ios_base::_Loc_init::_Loc_init() (in
/usr/lib/libstlport_gcc.so.4.5)

==21303== by 0x401CACD4: __static_initialization_and_destruction_0(int,
int) (in /usr/lib/libstlport_gcc.so.4.5)

==21303== by 0x401CAD41:
_GLOBAL__I__ZN4_STL7_LocaleC2ERKNS_12_Locale_implE (in
/usr/lib/libstlport_gcc.so.4.5)

==21303== by 0x401DCD54: (within /usr/lib/libstlport_gcc.so.4.5)

==21303== by 0x40179564: (within /usr/lib/libstlport_gcc.so.4.5)

==21303== by 0x4000A7A1: _dl_init_internal (in /lib/ld-2.2.93.so)

==21303== by 0x40000B6C: (within /lib/ld-2.2.93.so)

Re: [Valgrind-users] valgrind-20030716 with calltree and kcachegrind: --> [ SOLVED ].

[Xavier Barnabe-T. <xa...@Th...>]

Hello

Many thanks.

copying, adjusting only two #includes, make clean, configure, make and
make install. It works well.

last but not least: enjoy.

valgrind + skins + kcachegrind ==> a powerfull and easy tool !!


--
Xavier Barnabe-Theriault,  PhD student.
 Institut fuer Theoretische Physik
 Georg-August-Universitaet
 Tammanstrasse 1
 37077 Goettingen

Re: [Valgrind-users] valgrind-20030716 with calltree and kcachegrind: where i'm wrong ?

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

On Thursday 17 July 2003 12:24, Xavier Barnabe-Theriault wrote:
> Hello
>
> I tried to get
> valgrind-20030716

Ooops...
Just noted that valgrind-20030716 *is* a stable release ;-)

I will upload a calltree-0.9.2 shortly.
Thanks,
Josef

Re: [Valgrind-users] valgrind-20030716 with calltree and kcachegrind: where i'm wrong ?

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

On Thursday 17 July 2003 12:24, Xavier Barnabe-Theriault wrote:
> Hello
> [...]
> Everything compiles. But to get trough the configure of calltree, I
> modified the line about the cvs version of valgrind, not accepting
> valgrind-cvs-head-2003... but valgrind-20030716. Then it works.
>
> valgrind with default skin works great, telling me that no error was
> found on my testing program.
>
> valgrind with calltree skin gets the following error message at some
> stage:
>    valgrind: vg_translate.c:658 (vgPlain_saneUCodeBlock): Assertion `sane'
>    failed.

Hi,

known problem.
This error is because of changes between vg_skin.h delivered with calltree and 
the vg_skin.h from Valgrind CVS. If you change the configure check, you also
should copy vg_skin.h from Valgrind CVS to the include-cvs/ directory of the 
calltree distribution. Some "#include" line of vg_skin.h has to be changed 
too, to make it compile. It should be clear by the error message you get when 
compiling.
(The error message above suggests a change in the enum for UCodes, e.g. if a 
UCode was added to support some SSE/MMX Opcode).

The big problem is that Valgrind doesn't (yet) install this header file, so 
external skins have to provide an own version, which not necessarily matches 
to one your Valgrind was compiled with. This of course only is true for CVS 
versions, as they are changing regularly.

BTW, the above error message never should happen. Instead, valgrind should 
give out a warning about an old calltree skin. But enforcing this policy only 
makes sense for realeases, not CVS versions.

And thanks for this "bug report", I will include a check in the next calltree 
release.

Josef







> and emits an empty output cachegrind.out.XXXX file. The complete output
> of the run with calltree appears at the end.
>
> valgrind with cachegrind seems to work, giving some output in the
> cachegrind.out.XXXX. kcachegrind seems to work as well. Except that I
> get no information about my program (a small testing program).
>
>
> If some have ideas, thank you. Don't hesitate to ask for more
> information.
>
>
> Xavier
>
> ----------------------------------------------------------------
>
> ==6758== Calltree-0.9.1, a cache profiler for x86-linux.
> ==6758== Copyright (C) 2002, and GNU GPL'd, by N.Nethercote and
> J.Weidendorfer. ==6758== Using valgrind-20030716, a program supervision
> framework for x86-linux. ==6758== Copyright (C) 2000-2003, and GNU GPL'd,
> by Julian Seward. ==6758== Estimated CPU clock rate is 401 MHz
> ==6758== For more details, rerun with: -v
> ==6758==
> Instruction failed sanity check:
> 	   1: CALLMo       	t4		[abcdSD]
> opcode:          68
> lit32:           0x4002021A
> 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
> ==6758==    at 0x4007CF78: (within
> /net/theorie/auto/home3/xavier/lib/valgrind/valgrind.so) ==6758==    by
> 0x4000ABB2: _dl_init_internal (dl-init.c:68)
> ==6758==    by 0x40000AAC: (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.

-- 
--
Dr. Josef Weidendorfer
LRR-TUM - Raum 01.06.056 - Tel. +49 / (0)89 / 289 - 18454

[Valgrind-users] libstdc++-v3 (gcc-3.2.2) : new_opvnt.cc

[JAN S. <loi...@ya...>]

Hi there.

With the latest stable release and latest snapshot,
valgrind reports 2 "Mismatched free() / delete /
delete []":

//---------------
#include <new>
struct xx { xx (int i=7) : x(i) { } int x ; } ;
int main() {
     xx* pxx = new (std::nothrow) xx[10] ;
     delete [] pxx ;
     char* pcc = new (std::nothrow) char[1024] ;
     delete [] pcc ;
}
// ----------------

I have attached a verbose output of valgrind.
As far as I understand, the problem is not in VALGRIND
(which I love very much :-), but in libstdc++-v3, more
specifically  new_opvnt.cc which says:
//----------------
void *
operator new[] (std::size_t sz, const std::nothrow_t&
nothrow) throw() {
  return ::operator new(sz, nothrow)l
}

hence I don't see how valgrind could get it right.
I shall gladly investigate this if it hasn't been
already done (couln't find any traces).


Thank you!
J.



libstdc++-3.2.2-5
gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)
valgrind-20030716

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

[Valgrind-users] valgrind-20030716 with calltree and kcachegrind: where i'm wrong ?

[Xavier Barnabe-T. <xa...@Th...>]

Hello

I tried to get
valgrind-20030716
working with=20
calltree-0.9.1
and of course=20
kcachegrind-0.3b
on
Mandrake Linux release 9.1 (Bamboo) for i586.

Everything compiles. But to get trough the configure of calltree, I
modified the line about the cvs version of valgrind, not accepting
valgrind-cvs-head-2003... but valgrind-20030716. Then it works.

valgrind with default skin works great, telling me that no error was
found on my testing program.

valgrind with calltree skin gets the following error message at some
stage:
   valgrind: vg_translate.c:658 (vgPlain_saneUCodeBlock): Assertion `sane'
   failed.
and emits an empty output cachegrind.out.XXXX file. The complete output
of the run with calltree appears at the end.

valgrind with cachegrind seems to work, giving some output in the
cachegrind.out.XXXX. kcachegrind seems to work as well. Except that I
get no information about my program (a small testing program).


If some have ideas, thank you. Don't hesitate to ask for more
information.


Xavier

----------------------------------------------------------------

=3D=3D6758=3D=3D Calltree-0.9.1, a cache profiler for x86-linux.
=3D=3D6758=3D=3D Copyright (C) 2002, and GNU GPL'd, by N.Nethercote and J.W=
eidendorfer.
=3D=3D6758=3D=3D Using valgrind-20030716, a program supervision framework f=
or x86-linux.
=3D=3D6758=3D=3D Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward.
=3D=3D6758=3D=3D Estimated CPU clock rate is 401 MHz
=3D=3D6758=3D=3D For more details, rerun with: -v
=3D=3D6758=3D=3D=20
Instruction failed sanity check:
=09   1: CALLMo       =09t4=09=09[abcdSD]
opcode:          68
lit32:           0x4002021A
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' fai=
led.

sched status:

Thread 1: status =3D Runnable, associated_mx =3D 0x0, associated_cv =3D 0x0
=3D=3D6758=3D=3D    at 0x4007CF78: (within /net/theorie/auto/home3/xavier/l=
ib/valgrind/valgrind.so)
=3D=3D6758=3D=3D    by 0x4000ABB2: _dl_init_internal (dl-init.c:68)
=3D=3D6758=3D=3D    by 0x40000AAC: (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.



--=20
Xavier Barnabe-Theriault, PhD student.               http://xebu.org/
Institut f=FCr Theoretische Physik
Georg-August-Universit=E4t
Tammanstrasse 1
37077 G=F6ttingen

[Valgrind-users] valgrind-20030716 is available ...

[Julian S. <js...@ac...>]

... at http://developer.kde.org/~sewardj/valgrind-20030716.tar.bz2

20030716 is a snapshot of our current CVS head (development) branch.
This is the branch which will become valgrind-2.0.  It contains
significant enhancements over the 1.9.X branch.

Despite this being a snapshot of the CVS head, it is believed to be
quite stable -- at least as stable as 1.9.6 or 1.0.4, if not more so
-- and therefore suitable for widespread use.  Please let us know asap
if it causes problems for you.

Two reasons for releasing a snapshot now are:

- It's been a while since 1.9.6, and this snapshot fixes
  various problems that 1.9.6 has with threaded programs 
  on glibc-2.3.X based systems.

- So as to make available improvements in the 2.0 line.

Major changes in 20030716, as compared to 1.9.6:

- More fixes to threading support on glibc-2.3.1 and 2.3.2-based
  systems (SuSE 8.2, Red Hat 9).  If you have had problems
  with inconsistent/illogical behaviour of errno, h_errno or the DNS
  resolver functions in threaded programs, 20030716 should improve
  matters.  This snapshot seems stable enough to run OpenOffice.org
  1.1rc on Red Hat 7.3, SuSE 8.2 and Red Hat 9, and that's a big
  threaded app if ever I saw one.

- Automatic generation of suppression records; you no longer
  need to write them by hand.  Use --gen-suppressions=yes.

- The GDB attach mechanism is more flexible.  Allow the GDB to
  be run to be specified by --gdb-path=/path/to/gdb, and specify
  which file descriptor V will read its input from with
  --input-fd=<number>.

- Complete support for the MMX instruction set.

- Partial support for the SSE and SSE2 instruction sets.  Work for this
  is ongoing.  About half the SSE/SSE2 instructions are done, so
  some SSE based programs may work.  Currently you need to specify
  --skin=addrcheck.  Basically not suitable for real use yet.

- Significant speedups (10%-20%) for standard memory checking.

- Fix assertion failure in pthread_once().

- Fix this:
    valgrind: vg_intercept.c:598 (vgAllRoadsLeadToRome_select): 
              Assertion `ms_end >= ms_now' failed.

- Implement pthread_mutexattr_setpshared.

- Understand Pentium 4 branch hints.  Also implemented a couple more
  obscure x86 instructions.

- Lots of other minor bug fixes.

- We have a decent regression test system, for the first time.
  This doesn't help you directly, but it does make it a lot easier
  for us to track the quality of the system, especially across
  multiple linux distributions.  

  You can run the regression tests with 'make regtest' after 'make
  install' completes.  On SuSE 8.2 and Red Hat 9 I get this:
 
     == 84 tests, 0 stderr failures, 0 stdout failures ==

  On Red Hat 8, I get this:

     == 84 tests, 2 stderr failures, 1 stdout failure ==
     corecheck/tests/res_search               (stdout)
     memcheck/tests/sigaltstack               (stderr)

  sigaltstack is probably harmless.  res_search doesn't work
  on R H 8 even running natively, so I'm not too worried.   

  On Red Hat 7.3, a glibc-2.2.5 system, I get these harmless failures:

     == 84 tests, 2 stderr failures, 1 stdout failure ==
     corecheck/tests/pth_atfork1              (stdout)
     corecheck/tests/pth_atfork1              (stderr)
     memcheck/tests/sigaltstack               (stderr)

  You need to run on a PII system, at least, since some tests
  contain P6-specific instructions, and the test machine needs
  access to the internet so that corecheck/tests/res_search
  (a test that the DNS resolver works) can function.

As ever, thanks for the vast amount of feedback :) and bug reports :(
We may not answer all messages, but we do at least look at all of
them, and tend to fix the most frequently reported bugs.

[Valgrind-users] baffled by vg output

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

Hi all,
    I've been fooling around with valgrind (very impressed btw) and I'm not
100% clear on all the program output.

firstly, maybe there is an available FAQ for understanding vg output ?
I checked the usual culprits i.e. vg.sf.net && sf.net/projects/vg and 
couldn't
find such a beast.

secondly, if anyone understands this better that I do that would be 
great ;-)
this is what is presently baffeling me:

==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"

but how does that help me ?


Cheers all; any help is appriciated ;-)
                            -Tristan


PS:
    valgrind-1.9.6
    glibc-2.2
    linux-2.4.16

Re: [Valgrind-users] Odd startup

[Julian S. <js...@ac...>]

On Wednesday 16 July 2003 17:20, Steve G wrote:
> >RedHat 7.3 with grsec 2.4.21 kernel
>
> The grsec kernel does a lot of things to prevent security
> related attacks. I suspect they've got a different program
> layour when fork/execv is called.
>
> Try booting the normal Red Hat kernel for the software
> devlopment and see if that fixes your problem.

That probably will fix the problem -- which is that /proc/self/maps
isn't readable on the grsec kernel, I guess.

J

Re: [Valgrind-users] Odd startup

[Steve G <lin...@ya...>]

>RedHat 7.3 with grsec 2.4.21 kernel

The grsec kernel does a lot of things to prevent security
related attacks. I suspect they've got a different program
layour when fork/execv is called.

Try booting the normal Red Hat kernel for the software
devlopment and see if that fixes your problem.

Best Regards,
-Steve Grubb


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

[Valgrind-users] Odd startup

[William M. <wi...@dr...>]

valgrind.so: When searching for client's argc/argc/envp:
        Cannot determine stack segment from /proc/self/maps
valgrind.so: Startup or configuration error:
   couldn't find client's argc/argc/envp
valgrind.so: Unable to start up properly.  Giving up.

now i get this when i do anything even just type valgrind i installed the
new version

Re: [Valgrind-users] Odd startup

[Dan K. <da...@ke...>]

William McInnis wrote:
> it happens with all programs i try 
>  RedHat 7.3 with grsec 2.4.21 kernel
> Gcc V 2.96
> valgrind-1.0.4
> just did ./configure then make then make install

valgrind-1.0.4 is very out of date.  Please try the latest,
valgrind-1.9.6.
- Dan

-- 
Dan Kegel
http://www.kegel.com
http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

[Valgrind-users] Odd startup

[William M. <wi...@dr...>]

it happens with all programs i try 
 RedHat 7.3 with grsec 2.4.21 kernel
Gcc V 2.96
valgrind-1.0.4
just did ./configure then make then make install

Re: [Valgrind-users] ODD start up error

[Steve G <lin...@ya...>]

Hello,

Does this happen on all your programs or just one in
particular? What OS & compiler? What version of valgrind?
What configure options did you use for valgrind?

My esp isn't working today. :)

-Steve Grubb

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

[Valgrind-users] ODD start up error

[William M. <wi...@dr...>]

valgrind.so: When searching for client's argc/argc/envp:
        startup %esp is not near any VG_STARTUP_STACK_BASE_*
   constants defined in vg_include.h.  You should investigate.
valgrind.so: Startup or configuration error:
   couldn't find client's argc/argc/envp
valgrind.so: Unable to start up properly.  Giving up.

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

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

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?

Thanks,
Mike

Re: [Valgrind-users] --gen-suppressions prompting

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

Guys, any chance of this patch getting applied to HEAD? It makes the
--gen-suppressions functionality much more usable.

I've fixed up Madhu's original diff so it can be applied against CVS
HEAD and have run this on my apps... However due to the format of the
original diff, the changes since then, and the flakyness of SF's CVS
server it's not an identical copy of the original diff...

Anyway, attached in context diff format for your consideration.

Thanks, Lee.

Madhu M. Kurup writes:
 > Hi,
 > 
 > Leonard mckinley wrote:
 > >What do you think of a --gen-suppressions={yes|no|ask} option.  "yes"
 > >would generate suppressions without a prompt for every flagged issue,
 > >and "ask" would do what yes does now.  I just want it to dump
 > >everything in a file and when it prompts me I have to sit there and
 > >bang "y" on the keyboard.
 > 
 > Attached is a patch that does precisely that. It accumulates suppressions
 > and dumps them into a file, sorted by frequency at which they were hit
 > during the execution.
 > 
 > 	I've found this to be fairly useful by running through my programs
 > with the simplest startup/shutdown execution path. This captures all the
 > background noise. With the generated suppression file, I then try the
 > various options in the code to discover problems that I'm in a position to
 > fix. In addition, reading the low frequency count errors is a good idea :)
 > 
 > 	Could you apply this patch and let me know how it goes?
 > 
 > Cheerio,
 > M
 > 
 >  Madhu M Kurup /* Nemo Me Impune Lacessit */ mmk at yahoo-inc dt com
 > 
 > [ original diff snipped ]

Re: [Valgrind-users] Chaperon from Parasoft.

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

On 07-Jul-2003 Denis Perchine wrote:

 > It seems like Parasoft (parasoft.com) has a tool Chaperon similar to
 > valgrind.
 > Does it have something interesting valgrind lacks?

Chaperon currently supports NPTL, and all x86 instructions (MMX, SSE, SSE2).
This makes it usable with NVidia OpenGL drivers, for example.

 > Could it be that it is a changed version of valgrind?

Chaperon predates valgrind by 2 years: version 1.0 was released in
June 1999.

I could not find original announcement in c.o.l.a, but this post
includes a copy of it:
http://groups.google.com/groups?selm=37775561.78900398%40fel.tno.nl

Cheers,
-- 
Paul Pluzhnikov		pa...@pa...

Re: [Valgrind-users] problem debugging mysql code...

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

>>>>> On Mon, 14 Jul 2003 01:27:34 +0200, "Diego Torres" <dtg...@te...> said:

    > the atoi is performed over the returned row: atoi(row[0]). 

Which means that "row" is a pointer ...

    > now i'm copying the row content to another variable, but got the same
    > result.

You are copying a *pointer* to data to another pointer. It's the *data*
that you want to copy. What you've done is (apparently) equivalent to:

  char *p = strdup("hello");
  char *q;
  memcpy(&q, &p, sizeof(q));
  free(p);
  return q;

    > The strange thing is that the program is working without problems, and data
    > from the returned row is always valid. coincidence? 

Yes. That's what makes "dangling" bugs so hard to find.

Cheers,
-- 
Paul Pluzhnikov		pa...@pa...