valgrind-users — General discussion list for Valgrind users

Re: [Valgrind-users] RH9 and valgrind (vgPlain_do_useseg assertion fail)

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

On Thu, 27 Mar 2003, Tom Hughes wrote:

> > Still having problems with current valgrind CVS. This is on x86/linux.
> > In particular, intel P4, RH 9.
> >
> > Have the patches to do NPTL been integrated yet? If not, could somebody
> > post a current version against today's CVS?
>
> I don't think there is such a patch yet is there? I know what the
> problem is, and I don't think it will be difficult to fix but I haven't
> tried to do so yet as I don't have a system to try it on. Once RH9 is
> out I will probably take a look at this problem if nobody else gets
> there first.

Jeff Johnson of Red Hat wrote a patch for this and sent it to me a month
ago.  The patch is 6,841 lines long... so maybe it's harder than you'd
expect.  The patch did some stuff with the debuginfo package too, I don't
know how much of it was for that.

I looked at it but did nothing more -- I don't know much about Valgrind's
threading stuff.  I just realised that Jeff only sent it to me (I think)
and not Julian, so I just forwarded it to Julian.

N

Re: [Valgrind-users] RH9 and valgrind (vgPlain_do_useseg assertion fail)

[Tom H. <th...@cy...>]

In message <200...@re...>
          Benjamin Kosnik <bk...@re...> wrote:

> Still having problems with current valgrind CVS. This is on x86/linux.
> In particular, intel P4, RH 9.
> 
> I see others have also reported this:
> http://sourceforge.net/mailarchive/forum.php?thread_id=1862598&forum_id=32038
> 
> Have the patches to do NPTL been integrated yet? If not, could somebody
> post a current version against today's CVS?

I don't think there is such a patch yet is there? I know what the
problem is, and I don't think it will be difficult to fix but I haven't
tried to do so yet as I don't have a system to try it on. Once RH9 is
out I will probably take a look at this problem if nobody else gets
there first.

Tom

-- 
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/

[Valgrind-users] RH9 and valgrind (vgPlain_do_useseg assertion fail)

[Benjamin K. <bk...@re...>]

Still having problems with current valgrind CVS. This is on x86/linux.
In particular, intel P4, RH 9. 

I see others have also reported this:
http://sourceforge.net/mailarchive/forum.php?thread_id=1862598&forum_id=32038

Have the patches to do NPTL been integrated yet? If not, could somebody
post a current version against today's CVS?

best,
benjamin

%echo $FLAGS
-v --num-callers=20 --leak-check=yes --leak-resolution=high --show-reachable=yes

%valgrind $FLAGS a.out
==11345== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux.
==11345== Copyright (C) 2002, and GNU GPL'd, by Julian Seward.
==11345== Using valgrind-1.9.4, a program instrumentation system for x86-linux.
==11345== Copyright (C) 2000-2002, and GNU GPL'd, by Julian Seward.
==11345== Startup, with flags:
==11345==    --suppressions=/mnt/hd/bld/H-x86-valgrind/lib/valgrind/default.supp==11345==    -v
==11345==    --num-callers=20
==11345==    --leak-check=yes
==11345==    --leak-resolution=high
==11345==    --show-reachable=yes
==11345== Reading suppressions file: /mnt/hd/bld/H-x86-valgrind/lib/valgrind/default.supp
==11345== Estimated CPU clock rate is 1813 MHz
==11345==
 
valgrind: vg_ldt.c:167 (vgPlain_do_useseg): Assertion `(seg_selector & 7) == 7'
failed.
 
sched status:
 
Thread 1: status = Runnable, associated_mx = 0x0, associated_cv = 0x0
==11345== Reading syms from /home/bkoz/work/a.out
==11345== Reading syms from /lib/ld-2.3.2.so
==11345== Reading syms from /mnt/hd/bld/H-x86-valgrind/lib/valgrind/vgskin_memcheck.so
==11345== Reading syms from /mnt/hd/bld/H-x86-valgrind/lib/valgrind/valgrind.so
==11345== Reading syms from /usr/lib/libstdc++.so.5.0.3
==11345==    object doesn't have any debug info
==11345== Reading syms from /lib/tls/libm-2.3.2.so
==11345== Reading syms from /lib/libgcc_s-3.2.2-20030225.so.1
==11345==    object doesn't have any debug info
==11345== Reading syms from /lib/tls/libc-2.3.2.so
==11345==    at 0x42029CD1: __new_exitfn (in /lib/tls/libc-2.3.2.so)
==11345==    by 0x42029C88: __cxa_atexit_internal (in /lib/tls/libc-2.3.2.so)
==11345==    by 0x40259727: (within /usr/lib/libstdc++.so.5.0.3)
==11345==    by 0x40259779: (within /usr/lib/libstdc++.so.5.0.3)
==11345==    by 0x402A4794: (within /usr/lib/libstdc++.so.5.0.3)
==11345==    by 0x4024A204: (within /usr/lib/libstdc++.so.5.0.3)
==11345==    by 0x4000C4C0: _dl_init_internal (in /lib/ld-2.3.2.so)
==11345==    by 0x40000C4C: (within /lib/ld-2.3.2.so)
 
Please report this bug to: js...@ac...
 

Re: [Valgrind-users] problems with cvs...

[Benjamin K. <bk...@re...>]

>Yes, this sometimes happens to me for no apparent reason.  I just wait
>a bit (1/2 hour) and try again and it works.  No, I haven't a clue ...

Working now, thanks..........

-benjamin

Re: [Valgrind-users] problems with cvs...

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

Yes, this sometimes happens to me for no apparent reason.  I just wait
a bit (1/2 hour) and try again and it works.  No, I haven't a clue ...

J


On Thursday 27 March 2003 5:40 pm, Benjamin Kosnik wrote:
> %cvs -d:pserver:ano...@cv...:/cvsroot/valgrind login
> Logging in to :pserver:ano...@cv...:2401/cvsroot/valgrind
> CVS password:
> cvs [login aborted]: end of file from server (consult above messages if
> any)
>
> -benjamin
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by:
> The Definitive IT and Networking Event. Be There!
> NetWorld+Interop Las Vegas 2003 -- Register today!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users

[Valgrind-users] problems with cvs...

[Benjamin K. <bk...@re...>]

%cvs -d:pserver:ano...@cv...:/cvsroot/valgrind login
Logging in to :pserver:ano...@cv...:2401/cvsroot/valgrind
CVS password:
cvs [login aborted]: end of file from server (consult above messages if any)

-benjamin

Re: [Valgrind-users] Need testers for MMX support

[Arnaud D. <arn...@ge...>]

Hi,

I do not have much time as the moment to test it myself
but Richard Brent's irred should be a good test case, small
and simple.
http://web.comlab.ox.ac.uk/oucl/work/richard.brent/irred.html

Regards,

----- Original Message -----
From: "Julian Seward" <js...@ac...>
To: <val...@li...>;
<val...@li...>
Cc: <os...@kd...>
Sent: Wednesday, March 26, 2003 9:30 PM
Subject: [Valgrind-users] Need testers for MMX support


>
> Greetings, y'all.
>
> I just committed to the cvs head, initial support for MMX instructions.
> Just MMX, not SSE or SSE2.  SSE and SSE2 are for later; a staged approach
> keeps the resulting code simpler and more maintainable (I hope).
>
> Most MMX instructions now work.  What would be very useful is for
> people who have apps with MMX instructions, to check out and build the
> head [details below] and then run their MMXish apps on it.  There will
> be initial breakage, but the sooner this is done, the sooner we will
> have working MMX support :-)
>
> So, can anyone help out?
>
> If this all works out satisfactorily, I will seriously consider
backporting
> it to the stable branch (the >= 1.9.4 series).
>
> J
>
>
> Building from anon cvs:
> You need autoconf >= 1.5.  Apart from that it should be easy.
>
> Here's how:
>
> cvs -d:pserver:ano...@cv...:/cvsroot/valgrind
login
>
> When prompted for a password for anonymous, simply press the Enter key.
>
>
cvs -z3 -d:pserver:ano...@cv...:/cvsroot/valgrind
>           co valgrind
>
> cd valgrind
> ./autogen.sh
> ./configure --prefix=....
> make
> make install
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by:
> The Definitive IT and Networking Event. Be There!
> NetWorld+Interop Las Vegas 2003 -- Register today!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>

Re: [Valgrind-users] Need testers for MMX support

[Crispin F. <cr...@th...>]

Hmm, if I use automake 1.6 it compiles and works fine :)

I have tested the MMX instructions using the 'none' skin, and they work
fine (our code uses the MMX1, MMX2_MEMWr and MMX2_MemRd instructions).

Cheers

Crispin





On Thu, 2003-03-27 at 10:38, Crispin Flowerday wrote:
> Hi,
> 
> I had a bit of a problem getting it to compile, I got:
> 
> make[1]: Entering directory `/space/crispin/valgrind/coregrind'
> gcc   -DVG_LIBDIR="\"/opt/valgrind/lib"\"   -Winline -Wall -Wshadow -O
> -fomit-frame-pointer -mpreferred-stack-boundary=2 -g -c `test -f
> vg_dispatch.S || echo './'`vg_dispatch.S
> In file included from vg_dispatch.S:32:
> vg_constants.h:35:31: vg_constants_skin.h: No such file or directory
> make[1]: *** [vg_dispatch.o] Error 1
> 
> 
> so I added $(INCLUDES) into the CFLAGS line in the makefile, not quite
> sure what was happening there.
> 
> Anyway, I got it compiled, however every program I ran (including 'ls')
> aborted with the following error:
> 
> Instruction failed sanity check:
>            2: CALLML    q0              [abcdSD]
> opcode:          54
> lit32:           0x0
> size:            4
> val1,val2,val3:  1, 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: 0, 0
> has_ret_val:     0
> regs_live_after: [abcdSD]
> 
> valgrind: vg_translate.c:628 (vgPlain_saneUCodeBlock): Assertion `sane'
> failed.
> 
> 
> Could that be related to the compile problem?
> 
> Crispin
> 
> 
> 
> On Wed, 2003-03-26 at 21:30, Julian Seward wrote:
> > Greetings, y'all.
> > 
> > I just committed to the cvs head, initial support for MMX instructions.
> > Just MMX, not SSE or SSE2.  SSE and SSE2 are for later; a staged approach
> > keeps the resulting code simpler and more maintainable (I hope).
> > 
> > Most MMX instructions now work.  What would be very useful is for
> > people who have apps with MMX instructions, to check out and build the
> > head [details below] and then run their MMXish apps on it.  There will 
> > be initial breakage, but the sooner this is done, the sooner we will 
> > have working MMX support :-)
> > 
> > So, can anyone help out?
> > 
> > If this all works out satisfactorily, I will seriously consider backporting
> > it to the stable branch (the >= 1.9.4 series).
> > 
> > J
> > 
> > 
> > Building from anon cvs:
> > You need autoconf >= 1.5.  Apart from that it should be easy.
> > 
> > Here's how:
> > 
> > cvs -d:pserver:ano...@cv...:/cvsroot/valgrind login
> > 
> > When prompted for a password for anonymous, simply press the Enter key.
> > 
> > cvs -z3 -d:pserver:ano...@cv...:/cvsroot/valgrind 
> >           co valgrind
> > 
> > cd valgrind
> > ./autogen.sh
> > ./configure --prefix=....
> > make
> > make install
> > 
> > 
> > 
> > 
> > -------------------------------------------------------
> > This SF.net email is sponsored by:
> > The Definitive IT and Networking Event. Be There!
> > NetWorld+Interop Las Vegas 2003 -- Register today!
> > http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
> > _______________________________________________
> > Valgrind-users mailing list
> > Val...@li...
> > https://lists.sourceforge.net/lists/listinfo/valgrind-users
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by:
> The Definitive IT and Networking Event. Be There!
> NetWorld+Interop Las Vegas 2003 -- Register today!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Need testers for MMX support

[Crispin F. <cr...@th...>]

Hi,

I had a bit of a problem getting it to compile, I got:

make[1]: Entering directory `/space/crispin/valgrind/coregrind'
gcc   -DVG_LIBDIR="\"/opt/valgrind/lib"\"   -Winline -Wall -Wshadow -O
-fomit-frame-pointer -mpreferred-stack-boundary=2 -g -c `test -f
vg_dispatch.S || echo './'`vg_dispatch.S
In file included from vg_dispatch.S:32:
vg_constants.h:35:31: vg_constants_skin.h: No such file or directory
make[1]: *** [vg_dispatch.o] Error 1


so I added $(INCLUDES) into the CFLAGS line in the makefile, not quite
sure what was happening there.

Anyway, I got it compiled, however every program I ran (including 'ls')
aborted with the following error:

Instruction failed sanity check:
           2: CALLML    q0              [abcdSD]
opcode:          54
lit32:           0x0
size:            4
val1,val2,val3:  1, 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: 0, 0
has_ret_val:     0
regs_live_after: [abcdSD]

valgrind: vg_translate.c:628 (vgPlain_saneUCodeBlock): Assertion `sane'
failed.


Could that be related to the compile problem?

Crispin



On Wed, 2003-03-26 at 21:30, Julian Seward wrote:
> Greetings, y'all.
> 
> I just committed to the cvs head, initial support for MMX instructions.
> Just MMX, not SSE or SSE2.  SSE and SSE2 are for later; a staged approach
> keeps the resulting code simpler and more maintainable (I hope).
> 
> Most MMX instructions now work.  What would be very useful is for
> people who have apps with MMX instructions, to check out and build the
> head [details below] and then run their MMXish apps on it.  There will 
> be initial breakage, but the sooner this is done, the sooner we will 
> have working MMX support :-)
> 
> So, can anyone help out?
> 
> If this all works out satisfactorily, I will seriously consider backporting
> it to the stable branch (the >= 1.9.4 series).
> 
> J
> 
> 
> Building from anon cvs:
> You need autoconf >= 1.5.  Apart from that it should be easy.
> 
> Here's how:
> 
> cvs -d:pserver:ano...@cv...:/cvsroot/valgrind login
> 
> When prompted for a password for anonymous, simply press the Enter key.
> 
> cvs -z3 -d:pserver:ano...@cv...:/cvsroot/valgrind 
>           co valgrind
> 
> cd valgrind
> ./autogen.sh
> ./configure --prefix=....
> make
> make install
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by:
> The Definitive IT and Networking Event. Be There!
> NetWorld+Interop Las Vegas 2003 -- Register today!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users

[Valgrind-users] Re: [Valgrind-developers] Need testers for MMX support

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

On Wed, 2003-03-26 at 13:30, Julian Seward wrote:

> Greetings, y'all.
> 
> I just committed to the cvs head, initial support for MMX instructions.
> Just MMX, not SSE or SSE2.  SSE and SSE2 are for later; a staged approach
> keeps the resulting code simpler and more maintainable (I hope).
> 
> Most MMX instructions now work.  What would be very useful is for
> people who have apps with MMX instructions, to check out and build the
> head [details below] and then run their MMXish apps on it.  There will 
> be initial breakage, but the sooner this is done, the sooner we will 
> have working MMX support :-)
> 
> So, can anyone help out?

I don't have much which uses MMX for anything other than a quick memcpy,
but I'll give it a spin.  SSE and 3DNOW are more likely to get used (may
even get the nvidia drivers doing something sane).

Unfortunately I suspect MMX instructions do frequently operate on
uninitialized data, so I'm not sure how far the MMX support as
implemented will go.  I wonder if its worthwhile having a CLO to
enable/disable MMX support?

And, um, cpuid hasn't been updated to advertise MMX:


: ixodes:pts/17; valgrind '--skin=none' x86info -a
==5099== Nulgrind, a binary JIT-compiler for x86-linux.
==5099== Copyright (C) 2002, and GNU GPL'd, by Nicholas Nethercote.
==5099== Using valgrind-1.9.4, a program instrumentation system for x86-linux.
==5099== Copyright (C) 2000-2002, and GNU GPL'd, by Julian Seward.
==5099== Estimated CPU clock rate is 1878 MHz
==5099== For more details, rerun with: -v
==5099==
x86info v1.11.  Dave Jones 2001, 2002
Feedback to <da...@su...>.

Need to be root to use specified options.
Found 1 CPU
eax in: 0x00000000, eax = 00000001 ebx = 756e6547 ecx = 6c65746e edx = 49656e69
eax in: 0x00000001, eax = 0000052b ebx = 00000000 ecx = 00000000 edx = 000001bf

Family: 5 Model: 2 Stepping: 11 Type: 0
CPU Model: Pentium 75-200 Original OEM
Feature flags:
 fpu vme de pse tsc msr mce cx8

Connector type: Socket 5/7 (296 Pin PGA)


1817.95 MHz processor (estimate).

==5099==


Cool!  A 1.8GHz P75!

This should fix it:

Index: coregrind/vg_helpers.S
===================================================================
RCS file: /cvsroot/valgrind/valgrind/coregrind/vg_helpers.S,v
retrieving revision 1.17
diff -u -r1.17 vg_helpers.S
--- coregrind/vg_helpers.S      14 Dec 2002 23:59:08 -0000      1.17
+++ coregrind/vg_helpers.S      26 Mar 2003 22:27:48 -0000
@@ -147,7 +147,7 @@
        movl    $0x52b, %eax
        movl    $0x0,   %ebx
        movl    $0x0,   %ecx
-       movl    $0x1bf, %edx
+       movl    $0x008001bf, %edx
        jmp     cpuid__99
 cpuid__0:
        movl    $0x1,        %eax




        J

[Valgrind-users] Using valgrind from a test suite

[Olly B. <ol...@su...>]

I had a brief discussion with Julian back in April 2002 about using
valgrind as part of an automated testsuite for a library.  The testsuite
code could exercise features of the library and use valgrind to detect
accesses to uninitialised data, memory leaks, mismatched calls to
malloc/new/..., etc.

My particular interest is the GPLed search engine library I work on
(http://www.xapian.org/) which is mostly C++.  We've tried catching
memory leaks using an LD_PRELOAD library to wrap malloc and free, and
other tricks to intercept new and delete, but it doesn't work well -
various STL implementations do things which mess it up, and we've
eventually given up on that approach.  And of course we can't catch
accesses to uninitialised data.  The LD_PRELOAD approach would probably
work for a C library, but the using valgrind still offers benefits.

This would only work on x86 Linux, but that's not a big problem for
libraries like ours with almost no platform specific code.  On platforms
without valgrind, or on x86 Linux without valgrind installed, the test
suite would just not notice memory leaks.

My idea was to add a call or two so that the testsuite could be run
under valgrind and the test harness could find out about problems
from valgrind and fail the test in question.

Julian asked me to propose an interface.  I made a first stab at one and
things stalled there.  I contacted Julian and Nick a few months ago.
Nick responded briefly, but I imagine they're both swamped with mail.

I'm happy to try to implement this myself, but I'd like to settle
on an interface first to avoid wasted work.  I thought it would be
worthwhile to post this to the list so at least other valgrind users
can comment on the interface.

The intervening months have at least allowed me to mull this over, and
my envisioned interface is now rather simpler and more widely useful
than either of my previous suggestions.

The testsuite needs to be able to test if memory has been leaked (so it
can fail that test) and it would be useful to be able to totally
suppress valgrind's output for that check when running in the
testsuite's terse mode - it would just print "test7: FAIL (MEMORY LEAK)"
or something similar.

And if a test has failed with a memory leak or valgrind error, we want
to be able to reset valgrind's counters so we can move onto the next
test and not have the same problem re-reported.

My revised proposed interface adds three calls:

  int VALGRIND_SILENT(int silent);

    If silent is non-zero, suppress *all* output from valgrind.  Returns
    the setting prior to the call.

  VALGRIND_READ_COUNTERS(int *errors, int *lost, int *possiblylost,
			 int *reachable);

    Read counters into pointed to variables.  A pointer can be zero if
    you aren't interested in a particular value.

  VALGRIND_RESET_COUNTERS

    Zeros error and leak counters.

Cheers,
    Olly

[Valgrind-users] Re: [Valgrind-developers] Need testers for MMX support

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

On Wed, 26 Mar 2003, Julian Seward wrote:

> Building from anon cvs:
> You need autoconf >= 1.5.  Apart from that it should be easy.

I find automake version "1.4-p2" (which I think comes with RH 7.1) works
fine for me;  I just have to change the value of the "AUTOMAKE_OPTIONS"
variable in Makefile.am from "1.5" to "1.4" before starting the
installation.  YMMV.

N

[Valgrind-users] Need testers for MMX support

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

Greetings, y'all.

I just committed to the cvs head, initial support for MMX instructions.
Just MMX, not SSE or SSE2.  SSE and SSE2 are for later; a staged approach
keeps the resulting code simpler and more maintainable (I hope).

Most MMX instructions now work.  What would be very useful is for
people who have apps with MMX instructions, to check out and build the
head [details below] and then run their MMXish apps on it.  There will 
be initial breakage, but the sooner this is done, the sooner we will 
have working MMX support :-)

So, can anyone help out?

If this all works out satisfactorily, I will seriously consider backporting
it to the stable branch (the >= 1.9.4 series).

J


Building from anon cvs:
You need autoconf >= 1.5.  Apart from that it should be easy.

Here's how:

cvs -d:pserver:ano...@cv...:/cvsroot/valgrind login

When prompted for a password for anonymous, simply press the Enter key.

cvs -z3 -d:pserver:ano...@cv...:/cvsroot/valgrind 
          co valgrind

cd valgrind
./autogen.sh
./configure --prefix=....
make
make install

[Valgrind-users] =?iso-2022-jp?B?GyRCISEhIUwkPjVCejktOXAhdiMzMi8xXyRYJE4wbEpiISEhISEhISEhISEhGyhC?=

[<sb...@or...>]

$B!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!L$>5Bz9-9p!v(B
$B!c;v6H<T!d;qK\6b#12/#1@iK|!aA4?.6(4XO"3t<0K!?M!cJ]>Z<uBw6(2q!&(B
$B!!J]>Z6(2q!&A4?.6(!&%*%j%(%s%H!&$($S$9$d!d(B $B#3(B7$BG/$N<B@S!&9q:]J]>Zkz7t!!;v6HO"9g2q!R<+<#Bg?CEPO?#9!>#5#69f!S8xG'!&(B
$B!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!$40U8+$O(B 03-5458-8163$B>5$j@lMQ(B
$B:#8eITMW$NJ}$O(Bhttp://orient-sky.com/deny.htm$B$K$F$*4j$$?=$7>e$2(B
$B$^$9!#(B
$B(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(B

$B!!!!!!$"$N;~!"!"#12/1_0J>e$"$C$?$i(B
$B!!!!!!!!!!!!!!(B
$B!!!!!!!!!!!!!!!!!!$"$N;~!"J]>Z>Z7t$GJ]>Z$N8*Be$o$j$7$F$$$?$i(B

$B!!!!!!!!!!!!!!(B  $B!!!!!!!!:#$O!":G9b$G!"$h$j0J>e$KK-$+$J?M@8$J$N$K(B  

$B!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!#32/1_$X$N0lJb!!(B
$B!!!!!!!!!y"f"f"f"f"f!z"f"f"f"f"f!y"f"f"f"f"f!z"f"f"f"f"f!y(B
$B!zJ]>Z;v6H$KIT67$J$7!&J]>Z$KG:$s$G$$$k?M$O!"B?$$$+$i!#(B3$B@iK|$0$i(B
$B!!$$M_$7$$?M$OBgB??t$@$+$i!"<+J,$GJ]>Z8\Ld$K$J$j!"(B2$B2/!"(B3$B2/!"(B5$B2/(B9$B@i(B
  $BK|1_3MF@<T$KDI$$$D$-$^$7$g$&!#(B
$B!!7hCG$H<B9T$O>Z5r$+$i!&>Z5r$OJ*E*>Z5r!&13$D$-$^$;$s!&qY$5$l$?$/$J$$(B
  $B?M$O>Z5r$r!*(B
$B!!!!!!!z"f"f"f"f"f!y"f"f"f"f"f!z"f"f"f"f"f!y"f"f"f"f!z(B
         $B!!!!!!!!!!!!!!(B
$B!!!!!!!!!!!!!!:#$+$i$G$bCY$/$"$j$^$;$s!*!*(B

$B:#$,@d9%$N%A%c%s%9!*IT67$@$+$iDI$$Iw$N!VJ]>Z:_Bp8\Ld!aE9J^IT(B
$BMW$N%3%s%S%KE9$N%*!<%J!<$HF1$8!W$K!*>Z5r3NG'>)Ne!">Z5rL5$7$O;v(B
$B<BL5$7$H8+$F0B?4$N0U8+B?$$!#(B
  
$B!!!|$3$A$i$+$i(B $B!!(B http://orient-sky.com/ $BL5NA$N;qNA$4@A5a$G$-$^$9!#(B
  $B!!(B
$B!!(BHP$B$N%H%C%W%Z!<%8$@$18+$F;qNA@A5a$9$kJ}$,B?$$$G$9!#M}M3$O;qNA(B
$B!!$NJ}$,2r$j0W$$!&$H$N$3$H$G$9!#(B
$B!!!!!!!y"f"f"f"f"f!z"f"f"f"f"f!y"f"f"f"f"f!z"f"f"f"f"f!y(B
$B$3$l$+$i$N0B?4$H$f$H$j$N6b3[$rL\;X$7$F!"$"$J$?$b8\Ld$K$J$j$^$;$s(B
$B$+!)(B
$BBh0lJb$H$7$F;qNA@A5a$r$7$F$/$@$5$$!#!!!!!!L5NA$G;qNA$rM9Aw$7$^$9!#(B
$B;qNA$G$$$m$$$m$J;v<B$H>Z5r$r3NG'$7$F2<$5$$!#(B
(I"$B>^6b#1#2#0K|1_%W%i%9(B=$B#7#4#4K|1_(I#$B$N8"Mx$r!*?M?t@hCe=g@)8B$K$D$-!"(B
$B;j5^;qNA$r@A5a$7$F$/$@$5$$!*(B 
 $B!!!!!!!!(B
$B!!!!!!!!!|(B    $B2?;v$b>Z5r$,0lHV$K;v<B$N>ZL@(B  $B!!!|(B
$B$=$NCf$G$bJ*E*>Z5r$,4V0c$$$J$$$N$O<~CN$NDL$j$G$9!#(B
$BJ]>Zkz7t$GJ]>Z$NHa7`$rKI$0;v6H$G$9!#(B 
$B<R2q9W8%$r$7$J$,$i9bN(<}F~$rF@$i$l$^$9!#(B 
$B$^$?J]>Z$N@UG$$O$9$Y$?<uBw6(2q$,;}$A!"8\Ld$K$O0l@Z@UG$$O$"$j$^(B
$B$;$s!#(B
$BJ]>Z$N%j%9%/$O0l@Z$"$j$^$;$s!"$40B?4$r!#(B 
$B8\Ld8xG'HV9f$r;H$&$N$G$"$J$?$NL>A0$OC/$K$bCN$i$l$:$K=PMh$^$9!#(B 

$B!|$3$A$i$+$i(B $B!!(Bhttp://orient-sky.com/ $B!!L5NA$N;qNA$4@A5a$G$-$^$9!#(B

$B!}8D?M!":_Bp!"7s6H$G!"#22/1_!"#32/1_!"#52/#9@iK|1_$N<}F~<TB3=P>Z(B
$B!!5rM-$j$^$9!&8+$;$^$9!&2?;v$bqY$5$l$?$/$J$$0Y$K@'Hs!">Z5r$N3NG'(B
  
$B!!!z(B--$B!z(B--$B!~(B--$B!z!!%M%C%H%P%V%k$NJx2u$N8=67!!!z(B--$B!~(B--$B!z(B--$B!~(B

$B!|%M%C%H%S%8%M%9$G!V8D?M$NG/<}#5@iK|1_0J2<$NJ}!9!W$O!V6%AhAj<jF1(B
$B!!6H<T2a>j6H<o!W$,860x$H8@$o$l$F$$$^$9!#(B
$B!|_'C+$N0l$D$N%S%k$K#2#3<T!J<R!&I{6H!&(BSOHO$B!K$$$^$7$?$,!":#$O!"#1!!(B
$B!!?M$@$1$K$J$j!"BgItJ,$O6a$/$N!V%Q%=%3%sGc$$<h$jE9!W$KGd5Q$7$?$H$N!!(B
$B!!>pJs$G$9!#(B
$B!!@5$K%M%C%H%P%V%k$NJx2u$r>]D'$7$?8=>]$G$9!#(B
$B!!%9!<%Q!<!&%G%Q!<%H!&>&E9$G$b!V%G%U%l!W$NGH$GGQ6H!"=L>.$N;~Be$G$9!#(B
$B(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(B
  $B!!!!!z(B--$B!~(B--$B!zJ]>Z>Z7tH/9TJ]>Z0z$-<u$1;v6H$O!z(B--$B!~(B--$B!z(B
$B!!!!!!!!!z(B--$B!~!!F|K\$G;O$a$FEv6(2q$G3+H/$7#3#7G/!!!z(B--$B!~(B
$B!!!!!z(!(!(!!&!&!&(!(!(!(!!&!&!&!&(!(!(!!&!&!&(!(!(!!&!&!&(!!=!=!z(B
$BJ]>Z>Z7t$GJ]>Z$NHa7`$r8*Be$o$j$9$k#1#5<o>Z7t!a>Z7tJ]>Z%5!<%S%9(B
$B!W$r><OB#4#1G/$+$iH/9T$7$FA49qE*$KJ]>Z$7$F$$$k$N$OF|K\$GM#0l!"Ev(B
$BJ]>Z<uBw6(2q$@$1$G$9!#(B
$B(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(B
 $B!!!!!z(B--$B!~!!#22/1_!"#32/1_!"#52/1_$N8D?M<}F~<TH/@8(B  $B!z(B--$B!~(B
$B!!!!!!!!!!!!!!!z(B--$B!~!!$NM}M3$O%P%V%kJx2u(B     $B!z(B--$B!~(B
$B!z(!(!(!!&!&!&(!(!(!(!!&!&!&!&(!(!(!!&!&!&(!(!(!!&!&!&(!!=!=!z(B
$B!}!H5.J}MM$bDI$$$D$-DI$$H4$/J]>Z>Z7t;v6H!I$O!">&9f!aJ]>Z:_Bp;v(B
$B!!6H8\!!Ld!&J]>Z6(2qD9!JE9J^!";vL3=jITMW$N%3%s%S%KE9$N%*!<%J!<$H(B
$B!!F1MM!K$O!"!!M=Dj!"4uK>!"L4Ey$r%*!<%P!<$7$?<}F~>Z5r$NM}M3$OC1=c(B
$B!!$G$9!#(B
$B!!%M%C%H%P%V%k!J<{MW$h$j6!5k<T$,5^A}$7$?!K$H@5H?BP$K!"IT67$N@z$j$G!!(B
$B!!;q6b!J@83h!";v6H!"8=>u0];}!"IT7J5$BP:v!K$,M_$7$$?M$,!"%P%V%kJx(B
$B!!2u#1#2G/0J>e7QB3$7$FA}2C$7$F$$$k$+$i$G$9!#(B
$B!}6d9T$N6/@)E*2s<}!"B_$7=B$j!"@=IJ>&IJ$N%G%U%lDc2A3J6%Ah!&J]>Z(B
$B!!?M$N:b;::9$72!$5$(!&J]>Z?M:DL3<T$N<+;&%[!<%`%l%9!&Ey$NF|K\7P(B
$B!!:Q$N<:GT!!$K$h$k5>@7<T$HM=Hw73$O_'C+$N#2#3<T$N#1<T$N$_@8$-;D(B
$B!!$kNc$+$7$F:#8e!!99$K3HBg798~$H$N>pJs!#(B
$B!!$=$N$*Lr$KN)$A$?$$!VJ]>Z>Z7t$r!a?M=u$1J]>Z%5!<%S%9>&IJ!W$H$J$k(B
$B!!$+$i$G$9!#(B
$B!|$3$A$i$+$i(B $B!!(Bhttp://orient-sky.com/ $B!!L5NA$N;qNA$4@A5a$G$-$^$9!#(B

 $B!!!!(B

[Valgrind-users] Patch for recvfrom()

[Crispin F. <cr...@th...>]

Hi,

I noticed that with 1.9.4, calling recvfrom with a NULL 'from' argument
returned an error by valgrind, the attached patch stops this error.

Cheers

Crispin

Re: [Valgrind-users] Invalid free() error

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

On Thu, 20 Mar 2003, Eyal Lebedinsky wrote:

> I get the following report on program shutdown:
>
> ==10648== Time: 2003/03/20 18:05:19
> ==10648== Invalid free() / delete / delete[]
> ==10648==    at 0x4015E2CD: free (vg_clientfuncs.c:182)
> ==10648==    by 0x42B5DB6B: (within /lib/libc-2.2.93.so)
> ==10648==    by 0x42ACA021: __libc_freeres (in /lib/libc-2.2.93.so)
> ==10648==    by 0x4015EADD: vgPlain___libc_freeres_wrapper
> (vg_clientfuncs.c:587)
> ==10648==    by 0x42A7C208: exit (in /lib/libc-2.2.93.so)
> ==10648==    by 0x429C682D: ??? (exit.c:216)
> ==10648==    by 0x429D467F: skmain (main.c:1098)
> ==10648==    by 0x8050462: main (ssasrsv.c:789)
> ==10648==    by 0x42A66913: __libc_start_main (in /lib/libc-2.2.93.so)
> ==10648==    by 0x804E3D0: (within /home/eyal/a1i/bin/ssasrsv.orig)
> ==10648==    Address 0x42A2A830 is not stack'd, malloc'd or free'd
>
> The stamenet at exit.c:216 is 'exit (0)'.
>
> What are the possible causes of this?

From the most recent docs:

  <li><code>--run-libc-freeres=yes</code> [the default]<br>
      <code>--run-libc-freeres=no</code>
      <p>The GNU C library (<code>libc.so</code>), which is used by
      all programs, may allocate memory for its own uses.  Usually it
      doesn't bother to free that memory when the program ends - there
      would be no point, since the Linux kernel reclaims all process
      resources when a process exits anyway, so it would just slow
      things down.
      <p>
      The glibc authors realised that this behaviour causes leak
      checkers, such as Valgrind, to falsely report leaks in glibc,
      when a leak check is done at exit.  In order to avoid this, they
      provided a routine called <code>__libc_freeres</code>
      specifically to make glibc release all memory it has allocated.
      The MemCheck and AddrCheck skins therefore try and run
      <code>__libc_freeres</code> at exit.
      <p>
      Unfortunately, in some versions of glibc,
      <code>__libc_freeres</code> is sufficiently buggy to cause
      segmentation faults.  This is particularly noticeable on Red Hat
      7.1.  So this flag is provided in order to inhibit the run of
      <code>__libc_freeres</code>.  If your program seems to run fine
      on valgrind, but segfaults at exit, you may find that
      <code>--run-libc-freeres=no</code> fixes that, although at the
      cost of possibly falsely reporting space leaks in
      <code>libc.so</code>.
      </li><br><p>

Hope this explains it.

N

Re: [Valgrind-users] Assertion Failed

[Tom H. <th...@cy...>]

In message <200...@ac...>
          Julian Seward <js...@ac...> wrote:

> 
> > > valgrind: vg_ldt.c:167 (vgPlain_do_useseg): Assertion `(seg_selector &
> > > 7) == 7'
> 
> > The fact that this assertion is talking about segment selectors
> > suggests that thread local storage is involved, and hence this is
> > probably a threading related problem.
> 
> The lowest 3 bits of the segment selector is a tag which indicates some
> properties of the segment (iirc).  111b means a LDT selector, and that's
> what the above assertion tests.   I think you've probably hit a
> GDT selector (011b iirc).

I suspect the same - the NPTL documentation does mention that it
uses the GDT to handle thread local storage instead of the LDT that
is used by the old threading system.

There is also a new system call, tls, to manage the GDT so valgrind
is probably going to need to intercept that and emulate the GDT in a
similar way to that the LDT emulation is does at the moment.

Tom

-- 
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/

Re: [Valgrind-users] Assertion Failed

[Tom H. <th...@cy...>]

In message <200...@ac...>
          Julian Seward <js...@ac...> wrote:

> But anyway, as Tom says, R H 8.1 contains NPTL, which V can't emulate
> well enough to be useful, and we don't have an ETA on fixing it either.
> Best advice is to avoid 8.1 if you want to use V.  At least for the
> moment.

I wrote my earlier message based on your comment in the documentation
that NPTL will need extra work, but I was thinking afterwards that as
valgrind replaces libpthread.so with it's own version that NPTL won't
actually get a chance to be involved will it?

Presumably there must be some other problem though, perhaps with the
use of thread local storage by the main C library or something?

Tom

-- 
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/

Re: [Valgrind-users] Assertion Failed

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

> > valgrind: vg_ldt.c:167 (vgPlain_do_useseg): Assertion `(seg_selector & 
> > 7) == 7'

> The fact that this assertion is talking about segment selectors
> suggests that thread local storage is involved, and hence this is
> probably a threading related problem.

The lowest 3 bits of the segment selector is a tag which indicates some
properties of the segment (iirc).  111b means a LDT selector, and that's
what the above assertion tests.   I think you've probably hit a 
GDT selector (011b iirc).

But anyway, as Tom says, R H 8.1 contains NPTL, which V can't emulate
well enough to be useful, and we don't have an ETA on fixing it either.
Best advice is to avoid 8.1 if you want to use V.  At least for the
moment.

J

Re: [Valgrind-users] Assertion Failed

[Tom H. <th...@cy...>]

In message <3E7...@br...>
        Seth Ladd <se...@br...> wrote:

> I'm attempting to run valgrind 1.9.4 on redhat 8.1 beta, using gcc
> 3.2.1.  I'm trying to run a program under it, but I get a Assertion
> failed message.  The full text of the output is included below.  I
> checked the mailing list archives, and the nano-faq, but didn't see
> this mentioned.  Does any of this ring a bell?  Is there something I
> can do?

RedHat 8.1 uses glibc 2.3 with the NPTL thread package instead of
the linuxthreads thread package and valgrind is therefore highly
unlikely to work with threaded programs under RedHat 8.1 until some
work is done to make it handle the changes to threading.

The fact that this assertion is talking about segment selectors
suggests that thread local storage is involved, and hence this is
probably a threading related problem.

Before anybody worries about the update to glibc 2.3.2 that was
released for RedHat 8.0 the other day, that version was built with
linuxthreads so there is no problem there.

Tom

-- 
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/

[Valgrind-users] Assertion Failed

[Seth L. <se...@br...>]

Hello,

I'm attempting to run valgrind 1.9.4 on redhat 8.1 beta, using gcc 
3.2.1.  I'm trying to run a program under it, but I get a Assertion 
failed message.  The full text of the output is included below.  I 
checked the mailing list archives, and the nano-faq, but didn't see this 
mentioned.  Does any of this ring a bell?  Is there something I can do?

Thanks very much,
Seth

[root@disheveled .libs]# valgrind -v ./state testmode
shell-init: could not get current directory: getcwd: cannot access 
parent direct
ories: No such file or directory
sh_makepath: could not get current directory: getcwd: cannot access 
parent direc
tories: No such file or directory
==15339== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux.
==15339== Copyright (C) 2002, and GNU GPL'd, by Julian Seward.
==15339== Using valgrind-1.9.4, a program instrumentation system for 
x86-linux.
==15339== Copyright (C) 2000-2002, and GNU GPL'd, by Julian Seward.
==15339== Startup, with flags:
==15339==    --suppressions=/usr/local/lib/valgrind/default.supp
==15339==    -v
==15339== Reading suppressions file: /usr/local/lib/valgrind/default.supp
==15339== Estimated CPU clock rate is 865 MHz
==15339==

valgrind: vg_ldt.c:167 (vgPlain_do_useseg): Assertion `(seg_selector & 
7) == 7'
failed.

sched status:
Thread 1: status = Runnable, associated_mx = 0x0, associated_cv = 0x0
==15339== Reading syms from /home/seth/code/G4/src/.libs/state
==15339== Reading syms from /lib/ld-2.3.1.so
==15339== Reading syms from /usr/local/lib/valgrind/vgskin_memcheck.so
==15339== Reading syms from /usr/local/lib/valgrind/valgrind.so
==15339== Reading syms from 
/home/seth/code/G4/external/dist/lib/libcomms.so.0.0
.0
==15339== Reading syms from 
/home/seth/code/G4/external/dist/lib/libcurl.so.2.0.
2
==15339== Reading syms from 
/home/seth/code/G4/external/dist/lib/libssl.so.0.9.7
==15339== Reading syms from /lib/libdl-2.3.1.so
==15339==    object doesn't have any debug info
==15339== Reading syms from 
/home/seth/code/G4/external/dist/lib/libcore.so.0.0.
0
==15339== Reading syms from 
/home/seth/code/G4/external/dist/lib/libbrivodb.so.0
.0.0
==15339== Reading syms from 
/home/seth/code/G4/external/dist/lib/librdf.so.0.0.0
==15339== Reading syms from 
/home/seth/code/G4/external/dist/lib/libraptor.so.0.
0.0
==15339== Reading syms from 
/home/seth/code/G4/external/dist/lib/libxml2.so.2.5.
3
==15339== Reading syms from 
/home/seth/code/G4/external/dist/lib/libz.so.1.1.4
==15339== Reading syms from 
/home/seth/code/G4/external/dist/lib/libcrypto.so.0.
9.7
==15339== Reading syms from 
/home/seth/code/G4/external/dist/lib/libinterface.so
.0.0.0
==15339== Reading syms from /usr/local/lib/valgrind/libpthread.so
==15339== Reading syms from /usr/lib/libstdc++.so.5.0.2
==15339== Reading syms from /lib/tls/libm-2.3.1.so
==15339== Reading syms from /lib/libgcc_s-3.2.1-20021208.so.1
==15339== Reading syms from /lib/tls/libc-2.3.1.so
==15339==    at 0x42029BA1: __new_exitfn (in /lib/tls/libc-2.3.1.so)
==15339==    by 0x42029B58: __cxa_atexit_internal (in 
/lib/tls/libc-2.3.1.so)
==15339==    by 0x404767E7: 
__static_initialization_and_destruction_0(int, int)
(/usr/src/build/177318-i386/BUILD/gcc-3.2.1-20021208/obj-i386-redhat-linux/i386-
redhat-linux/libstdc++-v3/include/iostream:63)
==15339==    by 0x40476839: 
_GLOBAL__I__ZThn8_NSt14basic_iostreamIwSt11char_trai
tsIwEED0Ev.._.._.._.._libstdc___v3_src_io_inst.ccJGVYgb 
(/usr/src/build/177318-i
386/BUILD/gcc-3.2.1-20021208/obj-i386-redhat-linux/i386-redhat-linux/libstdc++-v
3/include/bits/locale_facets.h:107)

Please report this bug to: js...@ac...

[root@disheveled .libs]# gcc -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2.1/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man 
--infodir=/usr/share/info --enable-shared --enable-threads=posix 
--disable-checking --with-system-zlib --enable-__cxa_atexit 
--host=i386-redhat-linux
Thread model: posix
gcc version 3.2.1 20021207 (Red Hat Linux 8.0 3.2.1-2)

Re: [Valgrind-users] SystemC with valgrind?

[Joe S. <st...@sa...>]

Julian Seward wrote:
 > Don't I know your name in connection with denotational semantics, or
 > something?

Yes, that's me.  Seems a while ago now.

 > Umm ... what's systemC ?

It's a system for simulation of hardware and other designs, built on top
of C++.  From http://www.systemc.org: "SystemC is the standard design
and verification language built in C++ that spans from concept to
implementation in hardware and software. Designers design and verify
using SystemC and standard ANSI C++. EDA vendors create tools that are
automatically interoperable."

I had written:

 >> Can anyone suggest what I should do next with the following
 >> problem?

I have now sorted this out, thank you.  It was indeed a classic
premature-deletion bug.  I think Valgrind comes out with an
"A-double-minus" grade.  It gets a basic A because it did indeed detect
the invalid use of memory which had already been freeed.  But it doesn't
quite get a straight A because:
1. It got confused about the error message (presumably because of the
multi-threading).  It ought to have told me simply that it was memory in
the free store which I'd already deallocated; instead it went on about
how it was from another thread's stack area.
2.  My setting the address invalid, by VALGRIND_MAKE_NOACCESS, seemed
not to affect my claiming it, using it and releasing it; it was only
when I used it after that that the error message told me it was because
I had invalidated it.  (Maybe that's part of the bug Julian mentions in
his message -- I had indeed included "valgrind.h", not "memcheck.h".)
3.  The documentation emphasises that the system is designed to be "as
non-intrusive as possible".  I did not therefore realises that it
nevertheless alters all the memory addresses used.  This should perhaps
be emphasised -- after all, if you're investigating memory usage errors,
addresses tend to be relevant.

Julian and Nick gave me helpful advice about gdb (some of which I was
already doing).  But the tricky part was hunting down where I  had
prematurely deleted the item.  Two ways came to mind:
1.  If the program was already printing lots of diagnostic output, run
with Valgrind's --trace-malloc=yes.  Then you can search for the delete,
and see which of your own messages surround it.
2.  If you know the type of the errant object, you can write code in its
destructor to break for the case you're looking for.
But these are both a little bit clunky.  Perhaps a Valgrind option to do
it more cleanly would be nice.  I'm not sure.

Anyway, thanks again for your help.

joe stoy

Re: [Valgrind-users] SystemC with valgrind?

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

Don't I know your name in connection with denotational semantics,
or something?

> (a)
> Has anyone had experience debugging SystemC programs with valgrind?
> Were there any unexpected problems?

Umm ... what's systemC ?

> (b)
> Can anyone suggest what I should do next with the following problem?
>
> I have a SystemC program which maintains a number of queues, implemented
> as C++ list<packet *>.  gdb reveals that after the simulation has been
> running for a considerable time, I create and initialise a packet and
> put it on the back of one queue, but a packet with the same pointer is
> already at the front of a quite different queue and has its contents
> overwritten.  (All queues and packets are in storage around 0x8,000,000.)
>
> This looks like a classic case of premature deletion, so I try to find
> it with valgrind.  But valgrind produces an "invalid read" error a
> little bit earlier in the simulation, and gdb shows all the packets in
> the queue about to be clobbered have now been moved to invalid addresses
> around 0x43,000,000.  (Valgrind guesses that this address is "on thread
> 1's stack", but I'm not sure that's reliable.)
>
> Running without valgrind shows, according to gdb at the relevant moment,
> no sign of this relocation.
>
> So I reckon that if the packets have turned up in the new place,
> something (presumably with access rights) must have put them there.  So
> I try again with the offending address made invalid by a
> VALGRIND_MAKE_NOACCESS call, hoping to catch whatever it is that wrote
> them in the first place.  But the program fails in the same place as
> before (though this time the error is because I've declared the address
> invalid, not because valgrind thought it was invalid anyway).  The
> packets are all there at the new place, with their proper contents; but
> whatever it is that wrote them there snuck in under my prohibition.
>
> Sorry to go on at length, but I'm a bit stuck.  I'd be grateful for any
> suggestions . . .

3 comments.

1. Increase valgrind's --freelist-vol parameter to as large a number
   as you can.  The manual describes what it is and why this might
   be useful.   (do  valgrind --skin=memcheck --help, assuming you
   are using v-1.9.4).

2. If you are doing this VALGRIND_MAKE_NOACCESS with valgrind version
   1.1.0 or later, we found recently a bug in which the file to 
   include is "memcheck.h" and not "valgrind.h".  The real bad thing
   is that including "valgrind.h" still seems to work, but strange
   things happen at run time.  I've put in a fix to both the head
   and 2_0_BRANCH to cause a compilation error if you include valgrind.h
   directly, and that will be in 1.9.5.

3. As Nick rightly points out, make friends with GDB's hardware 
   watchpoints if you haven't already.  In summary, 
      watch *(int*) 0xAddressToWatch
   They've saved my ass on various occasions since I learnt of them.

J

[Valgrind-users] hardcoded /usr/bin/gdb

[Ruben G. <ru...@ug...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In valgrind 1.0.4 (dont know if this is fixed in development)
the location of gdb is hardcoded in vg_main.c as /usr/bin/gdb.

Gdb sources, on the other hand, install by default in /usr/local/bin/gdb.
Surely a patch to the ./configure to check where gdb is installed cannot 
be difficult.

Thanks!

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org

iD8DBQE+eigdkzndl97WsggRAuEiAJ4oDZHdPTA/H34ruZnO+Tfqc7tNUQCeMdoA
oG6azwlPvd+HSEeY0B1cMxo=
=bsaQ
-----END PGP SIGNATURE-----

Re: [Valgrind-users] SystemC with valgrind?

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

On Thu, 20 Mar 2003, Joe Stoy wrote:

> (a)
> Has anyone had experience debugging SystemC programs with valgrind?
> Were there any unexpected problems?

I have no experience, but there shouldn't be any problems, since Valgrind
works in principle with programs written in any languages (although it can
do a bit more with C and C++ programs).

> (b)
> Can anyone suggest what I should do next with the following problem?

I don't have much to say about this, except maybe GDB watch points could
be useful?  Don't know.

N