valgrind-users — General discussion list for Valgrind users

[Valgrind-users] valgrind-1.9.4.tar.bz2

[Kieun K. <ki...@ec...>]

Hi,

 I would like to install valgrind, but I do not know how to uncompress
this.

 Please let me know how to do this.

 Thanks,

Kieun K.

Re: [Valgrind-users] Using valgrind from a test suite

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

On Fri, 28 Mar 2003, Olly Betts wrote:

> > >   int VALGRIND_SILENT(int silent);
> > >
> > >     If silent is non-zero, suppress *all* output from valgrind.  Returns
> > >     the setting prior to the call.

I think a command line option is more appropriate for this.  Currently
-q turns off all normal output, but still prints errors.  Using -q -q
could suppress everything.  Although this would be useless without using
the following client requests, so maybe a client request is a good way to
do it.


> > >   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.

The variable for counting the number of errors is a static global variable
in coregrind/vg_errcontext.c, called "vg_n_errs_found".  And the variables
for "lost", "possiblylost"  and "reachable" are local variables within the
function VG_(generic_detect_memory_leaks)() in coregrind/vg_memory.c.

The local variables would have to be made into static ones, and then get()
and reset() functions would be needed for the four variables which the
client requests would call.  This isn't much of a problem, I guess.

Also, some reshuffling of the core/skin split I'm doing is likely to make
it necessary to split VALGRIND_READ_COUNTERS into two, since the number of
errors will be a core thing, but the leak counts will be a
Memcheck/Addrcheck skin thing.  But that doesn't matter so much.

All in all, they're pretty minor changes, and I think it's a good thing to
make it easier to incorporate Valgrind into regression testing.  So I'd be
happy to add them, but only once I've done my core/skin reshuffle
(assuming it is completed), which will take a little while.

N

Re: [Valgrind-users] Do you already have a --tidoffset parameter?

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

On Fri, 2003-03-28 at 10:43, Peter H Smith wrote:

> When I run a program under valgrind, pthread_self() will
> return a number between 1 and 50.  This doesn't catch
> some latent errors. 

I've been thinking about ORing in something into the top of thread IDs
as seen by the client code so that skins (like helgrind) can more easily
find thread IDs when scanning memory.  I would have the side effect of
breaking any program which thinks that pthread_t is just a small
integer.


        J

Re: [Valgrind-users] Do you already have a --tidoffset parameter?

[Sebastian <sc...@nb...>]

Hi,

On Fri, Mar 28, 2003 at 01:43:16PM -0500, Peter H Smith wrote:

> When I run a program under valgrind, pthread_self() will return a number
> between 1 and 50.  This doesn't catch some latent errors.  Consider this
> simplification of some bone-headed trace code:
 
> #define PENNY_WISE 5
> char header[PENNY_WISE];
> sprintf(header, "%d: ", pthread_self());
> fprintf(stderr, "%s%s\n", header, message);
 
> There is a latent buffer overrun here that won't be tripped under Valgrind
> because thread ids are always small.  I'd like to be able to set the base
> thread id to something like 0x800000000 or 0xFFFF0000 and test to be sure
> this buffer nonsense is not a problem.

While configurability might be a nice thing in general, this might be too
much. I have never seen code like the one you gave as example (and I have
audited quite a lot open source applications).

What might be nice in general would be to simulate a behaviour similar to
the native implementation. I.e. if libpthread gives high TID's, then
valgrind should, too. But as I have never dabbled with this features of
valgrind, this might be off the road, though.

Also, the program might also just misbehave on small TID's and behave
correctly at large TID's. Or produce a buffer overflow at small TID's. Or
negative ones. Etc. That quickly leads to "fuzzing" the application with
random data that might produce faults.


One can use other examples such as "malloc(0)", which I have seen in real
code to produce process-wide unique-id's. Valgrind or any other malloc
implementation might change this and return a constant (as zero bytes can
never be used), hence break the program. Or they do not. The point is, if
programs are broken without valgrind, valgrind should not try to produce
specific bordercases that might cause trouble.

(My point of view, but maybe the valgrind developers can support/nullify my
 points ;-)


> Peter H. Smith
> Advisory Software Engineer
> xSeries Systems Management
> IBM Server Group

ciao,
Sebastian

-- 
-. sc...@nb... -. + http://segfault.net/~scut/ `--------------------.
-' segfault.net/~scut/pgp `' 5453 AC95 1E02 FDA7 50D2 A42D 427E 6DEF 745A 8E07
`- 4 BLU-82/MOAB articles offered, payment due. hi echelon! -----------------'

[Valgrind-users] Do you already have a --tidoffset parameter?

[Peter H S. <smi...@us...>]

When I run a program under valgrind, pthread_self() will
return a number between 1 and 50.  This doesn't catch
some latent errors.  Consider this simplification of
some bone-headed trace code:

#define PENNY_WISE 5
char header[PENNY_WISE];
sprintf(header, "%d: ", pthread_self());
fprintf(stderr, "%s%s\n", header, message);

There is a latent buffer overrun here that won't be tripped
under Valgrind because thread ids are always small.
I'd like to be able to set the base thread id to something
like 0x800000000 or 0xFFFF0000 and test to be sure
this buffer nonsense is not a problem.

I suppose it's harder, but it would also be nice to be able
to put a "translation layer" between getpid() and kill(), etc
so that you could force pids to be large too.  At least make
getpid() return a configurable value like 0x80000000 or
0xF0000000, and have kill() turn it back to the right value
before passing it on.  Ideally translate any returned pid to
have some minimum value, and translate the returned pids
to real pids on the way out.  This wouldn't be perfect but
would be useful in stoopid programs.

I suppose I should get over "code approach anxiety" and
add it myself, but I'm too busy finding bone-headed buffer
overflows to put it in right now...

Peter H. Smith
Advisory Software Engineer
xSeries Systems Management
IBM Server Group
Phone (919) 543-6140 (T/L 441-6140)
email: smi...@us...

Re: [Valgrind-users] Using valgrind from a test suite

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

On Fri, Mar 28, 2003 at 12:20:44AM +0000, Nicholas Nethercote wrote:
> On Wed, 26 Mar 2003, Olly Betts wrote:
> 
> > I had a brief discussion with Julian back in April 2002 about using
> > valgrind as part of an automated testsuite for a library.
> 
> > 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.
> 
> > 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.
> 
> >   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.
> 
> I don't entirely understand what you want to do.

Sorry, I'll try to elaborate.  Let me know if anything is still not
clear...
 
> Does your entire test suite run as a single process under a single
> invocation of Valgrind?  If so do you use --trace-children for the
> individual tests?

No, the testsuite consists of over 300 tests, grouped into 3 programs.
Each test is a function.  Putting each test in a separate program isn't
feasible - when static linking is in use it would inflate the disk space
requirements to a ludicrous extent.

We could potentially run each test program many times, running one test
function each time.

> I assume your three functions are client requests...  would they be
> inserted into your test harness program, or the test programs themselves?

The test harness is linked into each test program, and calls the test
functions one after another, reporting any which fail (or are skipped
if they can't be run for some reason).  The test harness will also
catch unexpected exceptions and signals.

The 3 client requests would be used in that test harness.

> I guess you want to do something like: run valgrind in silent mode, after
> each test read the counters to see if any leaks occurred and if so print
> out the "terse" failure message, then reset them before going onto the
> next test.

Indeed.  And if the testsuite was run in "verbose" mode (which you
generally use with it running just one test function) it wouldn't put
valgrind into silent mode.

> I would have thought it better for your test harness to run each test
> program under Valgrind separately, maybe using --quiet (although leak
> reports still get printed), and then maybe parse the output to see if any
> leaks occurred.  Then counters wouldn't need to be reset at all.  But
> maybe I'm missing something about what you want to do.

That would require us to run the test program once for each test
function.  Doable, but it feels rather clumsy.  I also worry about the
speed - just running the test programs under valgrind is an excuse for
a teabreak.  If we rerun under valgrind for each testcase that'll incur
valgrind retranslating the common code (test harness and library) 300+
extra times...

Cheers,
    Olly

Re: [Valgrind-users] Using valgrind from a test suite

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

On Wed, 26 Mar 2003, Olly Betts wrote:

> I had a brief discussion with Julian back in April 2002 about using
> valgrind as part of an automated testsuite for a library.

> 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.

> 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.

>   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.

I don't entirely understand what you want to do.

Does your entire test suite run as a single process under a single
invocation of Valgrind?  If so do you use --trace-children for the
individual tests?

I assume your three functions are client requests...  would they be
inserted into your test harness program, or the test programs themselves?

I guess you want to do something like: run valgrind in silent mode, after
each test read the counters to see if any leaks occurred and if so print
out the "terse" failure message, then reset them before going onto the
next test.

I would have thought it better for your test harness to run each test
program under Valgrind separately, maybe using --quiet (although leak
reports still get printed), and then maybe parse the output to see if any
leaks occurred.  Then counters wouldn't need to be reset at all.  But
maybe I'm missing something about what you want to do.

N

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

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

In message <Pin...@ye...>
          Nicholas Nethercote <nj...@ca...> wrote:

> 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.

Well the immediate cause of that failure appears to be the use of
the GDT instead of the LDT to hold thread local data, and I believe
that should be easy to fix - it just needs the set_thread_area system
call to be handled in the same way that modify_ldt currently is, and
future GDT based references to be resolved via the current thread's
local data area as set with the set_thread_area call.

Of course there may be other NPTL related issues that would appear
once that was fixed.

Tom

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

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/