valgrind-users — General discussion list for Valgrind users

Re: [Valgrind-users] Possible bug in valgrind-1.9.4

[Dominic M. <dma...@ai...>]

On Fri, 4 Apr 2003, Julian Seward wrote:
> 
> Hi.  Yes, 1.9.4 does have an obscure bug in the handling of floating
> point conditional code sometimes.  I've fixed it in cvs and I hope to
> get it out to the world by shipping 1.9.5 at the weekend, or soon
> thereafter.  In the meantime I attach a patch with the fix -- easy,
> you just need to delete two lines of code.  
>
> It would be good if you could confirm that it works.

Yep, that fixes it.  Thanks!

> Thanks for chasing down a small example, even though I didn't use it
> -- you've no idea how much that helps.  Reproducing problems that people
> report is the #1 problem we have in debugging V; once we reproduce a
> problem, tracking it down is simple.

I understand all too well.  :)

Regards,
Dominic

> J
> 
> Index: coregrind/vg_from_ucode.c
> ===================================================================
> RCS file: /cvsroot/valgrind/valgrind/coregrind/vg_from_ucode.c,v
> retrieving revision 1.41
> retrieving revision 1.42
> diff -u -3 -p -r1.41 -r1.42
> --- coregrind/vg_from_ucode.c   26 Mar 2003 21:08:00 -0000      1.41
> +++ coregrind/vg_from_ucode.c   26 Mar 2003 23:43:57 -0000      1.42
> @@ -3412,8 +3412,6 @@ static void emitUInstr ( UCodeBlock* cb,
>        case FPU:
>           vg_assert(u->tag1 == Lit16);
>           vg_assert(u->tag2 == NoValue);
> -         if (anyFlagUse ( u ))
> -            emit_get_eflags();
>          if (!(*fplive)) {
>             emit_get_fpu_state();
>             *fplive = True;
> 
> 
> On Friday 04 April 2003 6:57 pm, Dominic Mazzoni wrote:
> > Hi,
> >
> > I've been using valgrind for about six months, and it's been wonderful to
> > have.  I was spoiled having access to purify on Solaris machines for a
> > while, and missed having something similar on Linux.  Many thanks to
> > Julian Seward and everyone else who contributed to its development.
> >
> > I've included a very small program that generates different output when
> > it's run through valgrind.  I noticed the error while I was debugging a
> > function to quickly check if an array of single-precision floats has any
> > NaNs in it - it turns out that doing a bitwise test is 2-3x faster than
> > calling the finite() function.
> >
> > Anyway, the error only occurs if you compile it with the options:
> >
> >   gcc -O2 -mcpu=pentiumpro -march=pentiumpro
> >
> > However, the exact same error occurs whether I compile the program with
> > gcc 2.96 (RedHat 7.3's version) or gcc 3.2.
> >
> > The correct output of the program is "0.000000".  When run under valgrind
> > 1.9.4, it outputs "1.000000".
> >
> > I hope this helps!  It's easy enough for me to work around, but I can only
> > guess that this is probably the symptom of a bug that could manifest
> > itself in other ways.
> >
> > - Dominic
> >
> > #include <stdio.h>
> >
> > int main(int argc, char **argv)
> > {
> >    union {
> >       float a[2];
> >       int b[2];
> >    } u;
> >
> >    u.a[0] = 0.0 / 0.0;
> >    u.a[1] = ((*u.b & 0x7FC00000) != 0x7FC00000);
> >    printf("%f\n", u.a[1]);
> >
> >    return 0;
> > }
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: ValueWeb:
> > Dedicated Hosting for just $79/mo with 500 GB of bandwidth!
> > No other company gives more support or power for your dedicated server
> > http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
> > _______________________________________________
> > Valgrind-users mailing list
> > Val...@li...
> > https://lists.sourceforge.net/lists/listinfo/valgrind-users
> 
> 

Re: [Valgrind-users] Possible bug in valgrind-1.9.4

[John R. <re...@cs...>]

> Design for debuggability / verifiability, I say.  Automated debugging
> is the way to go.

Yep -- for example about a year ago I was coding a tricky algorithm that
happily lended itself to testing vs. a simulator using random inputs.
After I finished finding bugs in my implementation there was one more bug
left that turned out to be an error in the original specification of the
algorithm!

Details on page 12 of this paper if anyone is interested :).

http://www.cs.utah.edu/flux/papers/spak-flux-tn-02-01/regehr-rtss02.pdf

John

[Valgrind-users] profiling/debugging inside shared objects

[<cha...@ya...>]

 Hi,

 I wonder if there are issues about profiling
dinamically loaded plugins? valgrind --skin=cachegrind
doesnt seem to produce any relevant info about code in
those plugins, only code in statically linked
libraries

 Greetings

(btw: im using valgrind 1.9.2, gcc 3.2, redhat 7.2)


------------
¡Internet GRATIS es Yahoo! Conexión!
Usuario "yahoo", contraseña "yahoo". 
Desde Buenos Aires, 4004-1010.
Otras ciudades: http://conexion.yahoo.com.ar/avanzados.html

Re: [Valgrind-users] Possible bug in valgrind-1.9.4

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

On Friday 04 April 2003 8:17 pm, John Regehr wrote:
> > -- you've no idea how much that helps.  Reproducing problems that people
> > report is the #1 problem we have in debugging V; once we reproduce a
> > problem, tracking it down is simple.
>
> Is it just reproducing the problem that's hard, or do you mean
> "reproducing in a reasonable sized program"?

Reproducing it at all.  Quite often we get reports of the form

  I have a 1/2 million line fortran program for doing geophysics
  calculations.  Under some obscure circumstances, this causes
  V to bomb out with ... assertion failure.  I am running on 
  MutantLinux 12.34.567 (with foobar-1.9 patch) and the code is
  compiled by ExpensiveRealMoneyCompiler v 41.97.  Our code is
  proprietary, so unfortunately we can't send you the source.

  Can you help us?

and in these circumstances there's practically nothing we can do apart
from note the bug and hope that someone finds a more tractable test
case for it.  Even if we could have the sources, setting up the precise
environment to repro it is very time consuming, and we all have 
day jobs (etc).

Interestingly, one solution to the above is for the bug reporter to
make me an account on their machine and allow me to ssh in, so I can
reproduce the bug in-place.  This has proved very effective in the
half-dozen or so times I've done it, and I appreciate the trust of
those who allow it.  I bet not many people can say they have used 
emacs at a distance of 12000 miles -- the most recent example of this,
the bug was is New Zealand, and I'm in the UK.


> If the latter, then there are techniques that might be able to help.
> They basically perform a space-wise or time-wise binary search in order to
> narrow down the problem, exploiting the fact that we have a known-correct
> implementation of an x86.

Yes, that's how V was debugged in the first place.  I knew from the 
start that making the virtual CPU work properly would be a problem.
So a fundamental design decision was that the program, when run on
valgrind, had a memory layout which allows switching over to the
real CPU at any point.  By changing the switchover point, you can 
do a binary search to find the exact basic block which is being
mistranslated.  This is controlled by the --stop-after= flag.
Without that, V would never have worked.

Design for debuggability / verifiability, I say.  Automated debugging
is the way to go.

J

Re: [Valgrind-users] Possible bug in valgrind-1.9.4

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

On Fri, 2003-04-04 at 11:58, Julian Seward wrote:
> report is the #1 problem we have in debugging V; once we reproduce a
> problem, tracking it down is simple.
                              ^ often

	J

Re: [Valgrind-users] Possible bug in valgrind-1.9.4

[John R. <re...@cs...>]

> -- you've no idea how much that helps.  Reproducing problems that people
> report is the #1 problem we have in debugging V; once we reproduce a
> problem, tracking it down is simple.

Is it just reproducing the problem that's hard, or do you mean
"reproducing in a reasonable sized program"?

If the latter, then there are techniques that might be able to help.
They basically perform a space-wise or time-wise binary search in order to
narrow down the problem, exploiting the fact that we have a known-correct
implementation of an x86.

I saw a great implementation of this idea presented by Jim Gray one time.
The goal was to flush out bugs in SQL implementations.  They would
repeatedly generate these massive random queries and feed them to four or
five databases until they found a query that did not return identical
results across the databases.  They then pruned the parse tree that
generated the query until they found the smallest query that elicited
different answers from different databases, at which point the problem was
pretty obvious.

Something similar could be done with Valgrind I think.  I'm not sure that
generating random C or asm programs would work, but maybe it's possible to
turn Valgrind on and off during the execution of a program?  This would
lead to a strategy where we are searching for the briefest application of
Valgrind that gives a different result than a native x86.  Again, the
problem should be obvious at that point.

John

Re: [Valgrind-users] Possible bug in valgrind-1.9.4

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

Hi.  Yes, 1.9.4 does have an obscure bug in the handling of floating
point conditional code sometimes.  I've fixed it in cvs and I hope to
get it out to the world by shipping 1.9.5 at the weekend, or soon
thereafter.  In the meantime I attach a patch with the fix -- easy,
you just need to delete two lines of code.  

It would be good if you could confirm that it works.

Thanks for chasing down a small example, even though I didn't use it
-- you've no idea how much that helps.  Reproducing problems that people
report is the #1 problem we have in debugging V; once we reproduce a
problem, tracking it down is simple.

J

Index: coregrind/vg_from_ucode.c
===================================================================
RCS file: /cvsroot/valgrind/valgrind/coregrind/vg_from_ucode.c,v
retrieving revision 1.41
retrieving revision 1.42
diff -u -3 -p -r1.41 -r1.42
--- coregrind/vg_from_ucode.c   26 Mar 2003 21:08:00 -0000      1.41
+++ coregrind/vg_from_ucode.c   26 Mar 2003 23:43:57 -0000      1.42
@@ -3412,8 +3412,6 @@ static void emitUInstr ( UCodeBlock* cb,
       case FPU:
          vg_assert(u->tag1 == Lit16);
          vg_assert(u->tag2 == NoValue);
-         if (anyFlagUse ( u ))
-            emit_get_eflags();
         if (!(*fplive)) {
            emit_get_fpu_state();
            *fplive = True;


On Friday 04 April 2003 6:57 pm, Dominic Mazzoni wrote:
> Hi,
>
> I've been using valgrind for about six months, and it's been wonderful to
> have.  I was spoiled having access to purify on Solaris machines for a
> while, and missed having something similar on Linux.  Many thanks to
> Julian Seward and everyone else who contributed to its development.
>
> I've included a very small program that generates different output when
> it's run through valgrind.  I noticed the error while I was debugging a
> function to quickly check if an array of single-precision floats has any
> NaNs in it - it turns out that doing a bitwise test is 2-3x faster than
> calling the finite() function.
>
> Anyway, the error only occurs if you compile it with the options:
>
>   gcc -O2 -mcpu=pentiumpro -march=pentiumpro
>
> However, the exact same error occurs whether I compile the program with
> gcc 2.96 (RedHat 7.3's version) or gcc 3.2.
>
> The correct output of the program is "0.000000".  When run under valgrind
> 1.9.4, it outputs "1.000000".
>
> I hope this helps!  It's easy enough for me to work around, but I can only
> guess that this is probably the symptom of a bug that could manifest
> itself in other ways.
>
> - Dominic
>
> #include <stdio.h>
>
> int main(int argc, char **argv)
> {
>    union {
>       float a[2];
>       int b[2];
>    } u;
>
>    u.a[0] = 0.0 / 0.0;
>    u.a[1] = ((*u.b & 0x7FC00000) != 0x7FC00000);
>    printf("%f\n", u.a[1]);
>
>    return 0;
> }
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: ValueWeb:
> Dedicated Hosting for just $79/mo with 500 GB of bandwidth!
> No other company gives more support or power for your dedicated server
> http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users

[Valgrind-users] Possible bug in valgrind-1.9.4

[Dominic M. <dma...@ai...>]

Hi,

I've been using valgrind for about six months, and it's been wonderful to 
have.  I was spoiled having access to purify on Solaris machines for a 
while, and missed having something similar on Linux.  Many thanks to 
Julian Seward and everyone else who contributed to its development.

I've included a very small program that generates different output when 
it's run through valgrind.  I noticed the error while I was debugging a 
function to quickly check if an array of single-precision floats has any 
NaNs in it - it turns out that doing a bitwise test is 2-3x faster than 
calling the finite() function.

Anyway, the error only occurs if you compile it with the options:

  gcc -O2 -mcpu=pentiumpro -march=pentiumpro

However, the exact same error occurs whether I compile the program with 
gcc 2.96 (RedHat 7.3's version) or gcc 3.2.

The correct output of the program is "0.000000".  When run under valgrind 
1.9.4, it outputs "1.000000".

I hope this helps!  It's easy enough for me to work around, but I can only 
guess that this is probably the symptom of a bug that could manifest 
itself in other ways.

- Dominic

#include <stdio.h>

int main(int argc, char **argv)
{
   union {
      float a[2];
      int b[2];
   } u;

   u.a[0] = 0.0 / 0.0;
   u.a[1] = ((*u.b & 0x7FC00000) != 0x7FC00000);
   printf("%f\n", u.a[1]);

   return 0;
}

Re: [Valgrind-users] GUi on top of valgrind

[Jeffrey S. <fe...@xi...>]

nah, was not aware of them. thanks for the pointer.

Jeff

On Fri, 2003-04-04 at 03:05, Julian Seward wrote:
> You're aware of  valgui  and  gnogrind, both of which are GUI 
> projects for V, yes?  I think they are both at sourceforge.
> 
> J
> 
> On Friday 04 April 2003 4:16 am, Biswapesh Chattopadhyay wrote:
> > On Fri, 2003-04-04 at 00:14, Jeffrey Stedfast wrote:
> > > I've actually already started working on a valgrind frontend for Gtk.
> > >
> > > http://primates.ximian.com/~fejj/alleyoop-0.1.tar.gz
> > >
> > > I don't think that's the latest sources, but it should be close enough
> > > for you to get a feel for what I am doing.
> >
> > Cool ! Thanks for the pointer. That's almost exactly what I was looking
> > for.
> >
> > > --
> > > Biswa.
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: ValueWeb:
> > Dedicated Hosting for just $79/mo with 500 GB of bandwidth!
> > No other company gives more support or power for your dedicated server
> > http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
> > _______________________________________________
> > Valgrind-users mailing list
> > Val...@li...
> > https://lists.sourceforge.net/lists/listinfo/valgrind-users
-- 
Jeffrey Stedfast
Evolution Hacker - Ximian, Inc.
fe...@xi...  - www.ximian.com

Re: [Valgrind-users] GUi on top of valgrind

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

You're aware of  valgui  and  gnogrind, both of which are GUI 
projects for V, yes?  I think they are both at sourceforge.

J

On Friday 04 April 2003 4:16 am, Biswapesh Chattopadhyay wrote:
> On Fri, 2003-04-04 at 00:14, Jeffrey Stedfast wrote:
> > I've actually already started working on a valgrind frontend for Gtk.
> >
> > http://primates.ximian.com/~fejj/alleyoop-0.1.tar.gz
> >
> > I don't think that's the latest sources, but it should be close enough
> > for you to get a feel for what I am doing.
>
> Cool ! Thanks for the pointer. That's almost exactly what I was looking
> for.
>
> > --
> > Biswa.
>
> -------------------------------------------------------
> This SF.net email is sponsored by: ValueWeb:
> Dedicated Hosting for just $79/mo with 500 GB of bandwidth!
> No other company gives more support or power for your dedicated server
> http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] GUi on top of valgrind

[Biswapesh C. <bis...@tc...>]

On Fri, 2003-04-04 at 00:14, Jeffrey Stedfast wrote:
> I've actually already started working on a valgrind frontend for Gtk.
> 
> http://primates.ximian.com/~fejj/alleyoop-0.1.tar.gz
> 
> I don't think that's the latest sources, but it should be close enough
> for you to get a feel for what I am doing.

Cool ! Thanks for the pointer. That's almost exactly what I was looking
for.

> -- 
> Biswa.
> 

Re: [Valgrind-users] GUi on top of valgrind

[Jeffrey S. <fe...@xi...>]

I've actually already started working on a valgrind frontend for Gtk.

http://primates.ximian.com/~fejj/alleyoop-0.1.tar.gz

I don't think that's the latest sources, but it should be close enough
for you to get a feel for what I am doing.

On Thu, 2003-04-03 at 02:16, Biswapesh Chattopadhyay wrote:
> Hi
> 
> I was thinking of writing a GTK+ GUI on top of valgrind (mainly for the
> addrcheck skin for now) and integrating it with Anjuta. So, my questions
> are:
> 
> 1. What is the recommended method for writing a GUI on top of valgrind ?
> Should I just fork()/exec() the process and parse the output

this is how I did it :-)

however... speaking of front-ends for valgrind - would it be possible
for the valgrind developers to add a switch such as --full-src-path or
some such that would give the full path name for the src file in the
error log output?

currently it only gives the basename of the src file containing the
brokeness. I've taken a look at adding this myself (to 1.0.4) but got
lost in the valgrind sources for parsing ELF (symtab2.c or some such if
I recall correctly).

from my limited understanding of ELF (mostly from playing with libbfd),
the debugging symbols which would give what I want (full src path) lies
within the "text" section - but it appears that is not what valgrind
uses (probably for a good reason, just that I don't know what that
reason is).

the other path I was thinking of following was to use bfd myself, but
that means that I would have to figure out which .so each address was
in. it also means (logically) that I would have to open each of the
dependency .so's in libbfd so that I could extract the debugging symbols
I needed. kinda yuck, but ya gotta do what ya gotta do I guess :-)

>   Or, is it
> possible to use valgrind as a loadable library in some way ?

not that I know of.

> 
> 2. I'm having some problems while running large GTK+ programs (e.g.
> anjuta). For example, anjuta crashes on startup unless you pass the
> '--no-splash' flag. Then, some gconf errors occur only when running
> through valgrind. Are these known issues, and are they on the way to
> getting solved ?

are you using --alignment=8 ? I had to do this when valgrinding
evolution.

Jeff

> 
> FWIW, I'm using RH 8.0 with GNOME 2.2 CVS.
> 
> Thanks in advance.
-- 
Jeffrey Stedfast
Evolution Hacker - Ximian, Inc.
fe...@xi...  - www.ximian.com

[Valgrind-users] GUi on top of valgrind

[Biswapesh C. <bis...@tc...>]

Hi

I was thinking of writing a GTK+ GUI on top of valgrind (mainly for the
addrcheck skin for now) and integrating it with Anjuta. So, my questions
are:

1. What is the recommended method for writing a GUI on top of valgrind ?
Should I just fork()/exec() the process and parse the output  Or, is it
possible to use valgrind as a loadable library in some way ?

2. I'm having some problems while running large GTK+ programs (e.g.
anjuta). For example, anjuta crashes on startup unless you pass the
'--no-splash' flag. Then, some gconf errors occur only when running
through valgrind. Are these known issues, and are they on the way to
getting solved ?

FWIW, I'm using RH 8.0 with GNOME 2.2 CVS.

Thanks in advance.

-- 
Biswa.

Re: [Valgrind-users] valgrind and poll()

[<da...@2g...>]

Quoting Jeremy Fitzhardinge <je...@go...>:

> On Wed, 2003-04-02 at 10:28, David Eriksson wrote:
> 
> > Strace stops in poll, and if I attach to the server process with gdb I
> > get this stacktrace:
> > 
> > (gdb) bt
> > #0  0x40183272 in vgPlain_do_syscall () from
> > /usr/local/lib/valgrind/valgrind.so
> > #1  0x4023c4d0 in __JCR_LIST__ () from /usr/lib/libglib-1.2.so.0
> > #2  0x40170c97 in poll (__fds=0x4223bf3c, __nfds=0x2, __timeout=0xea60)
> > at vg_intercept.c:194
> > #3  0x4022a3cb in g_main_poll () from /usr/lib/libglib-1.2.so.0
> > #4  0x40229c95 in g_main_iterate () from /usr/lib/libglib-1.2.so.0
> > #5  0x4022a0f4 in g_main_run () from /usr/lib/libglib-1.2.so.0
> > #6  0x0804c671 in main (argc=0x0, argv=0xbfffe8e4) at smaccd.c:616
> > #7  0x403d3907 in __libc_start_main () from /lib/libc.so.6
> 
> Hm, looks like the vg_intercept stuff isn't working - it's catching
> poll, but it isn't passing it into the threads library properly.  What
> does ldd <your program> say?  What is in /proc/<pid>/maps when you run
> it?  What does the link command line look like?

ldd says this:

        libgthread-1.2.so.0 => /usr/lib/libgthread-1.2.so.0 (0x4002a000)
        libglib-1.2.so.0 => /usr/lib/libglib-1.2.so.0 (0x4002e000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x40054000)
        libldap_r.so.2 => /usr/lib/libldap_r.so.2 (0x400a6000)
        liblber.so.2 => /usr/lib/liblber.so.2 (0x400d4000)
        libradiusclient.so.0 => /usr/local/radiusclient/lib/libradiusclient.so.0
(0x400df000)
        libssl.so.2 => /lib/libssl.so.2 (0x400e8000)
        libcrypto.so.2 => /lib/libcrypto.so.2 (0x40119000)
        libresolv.so.2 => /lib/libresolv.so.2 (0x401ed000)
        libc.so.6 => /lib/libc.so.6 (0x401ff000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
        libsasl.so.7 => /usr/lib/libsasl.so.7 (0x4033c000)
        libdl.so.2 => /lib/libdl.so.2 (0x40347000)
        libgdbm.so.2 => /usr/lib/libgdbm.so.2 (0x4034a000)
        libcrypt.so.1 => /lib/libcrypt.so.1 (0x40352000)
        libpam.so.0 => /lib/libpam.so.0 (0x4037f000)

The output from /proc/<pid>/maps is attached.

The (short version) of the linking is simply like this:

gcc  -o server  <OBJECTS> `glib-config --libs gthread` <LIBRARIES>

> Did you manage to get a small standalone program to reproduce the
> problem?

Not yet.

\David

Re: [Valgrind-users] valgrind and poll()

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

On Wed, 2003-04-02 at 10:28, David Eriksson wrote:

> Strace stops in poll, and if I attach to the server process with gdb I
> get this stacktrace:
> 
> (gdb) bt
> #0  0x40183272 in vgPlain_do_syscall () from
> /usr/local/lib/valgrind/valgrind.so
> #1  0x4023c4d0 in __JCR_LIST__ () from /usr/lib/libglib-1.2.so.0
> #2  0x40170c97 in poll (__fds=0x4223bf3c, __nfds=0x2, __timeout=0xea60)
> at vg_intercept.c:194
> #3  0x4022a3cb in g_main_poll () from /usr/lib/libglib-1.2.so.0
> #4  0x40229c95 in g_main_iterate () from /usr/lib/libglib-1.2.so.0
> #5  0x4022a0f4 in g_main_run () from /usr/lib/libglib-1.2.so.0
> #6  0x0804c671 in main (argc=0x0, argv=0xbfffe8e4) at smaccd.c:616
> #7  0x403d3907 in __libc_start_main () from /lib/libc.so.6

Hm, looks like the vg_intercept stuff isn't working - it's catching
poll, but it isn't passing it into the threads library properly.  What
does ldd <your program> say?  What is in /proc/<pid>/maps when you run
it?  What does the link command line look like?

Did you manage to get a small standalone program to reproduce the
problem?

    J

Re: [Valgrind-users] valgrind and poll()

[David E. <da...@2g...>]

On Wed, 2003-04-02 at 19:53, Jeremy Fitzhardinge wrote:
> On Wed, 2003-04-02 at 09:02, David Eriksson wrote: 
> > For the fun of it, I tried to send a SIGHUP to my process. There is
> > singal handler installed with signal() for SIGHUP, which gets executed
> > properly. What also happens is that all threads (one for each connection
> > that have been made to the server) get to run!
> > 
> > Do you have any ideas?
> > 
> > I will happily provide any more information that may be of interest.
> What does strace have to say about your running process?  Is it
> blocked in a a system call, or does it seem to be spinning away
> happily?
> 
> It's possible that the libc poll (or some other blocking system call)
> is somehow getting called without being intercepted by Valgrind. 

Strace stops in poll, and if I attach to the server process with gdb I
get this stacktrace:

(gdb) bt
#0  0x40183272 in vgPlain_do_syscall () from
/usr/local/lib/valgrind/valgrind.so
#1  0x4023c4d0 in __JCR_LIST__ () from /usr/lib/libglib-1.2.so.0
#2  0x40170c97 in poll (__fds=0x4223bf3c, __nfds=0x2, __timeout=0xea60)
at vg_intercept.c:194
#3  0x4022a3cb in g_main_poll () from /usr/lib/libglib-1.2.so.0
#4  0x40229c95 in g_main_iterate () from /usr/lib/libglib-1.2.so.0
#5  0x4022a0f4 in g_main_run () from /usr/lib/libglib-1.2.so.0
#6  0x0804c671 in main (argc=0x0, argv=0xbfffe8e4) at smaccd.c:616
#7  0x403d3907 in __libc_start_main () from /lib/libc.so.6

-- 
-\- David Eriksson -/-                              www.2GooD.nu
 
"I personally refuse to use inferior tools because of ideology."
                                                - Linus Torvalds

Re: [Valgrind-users] valgrind and poll()

[David E. <da...@2g...>]

On Wed, 2003-04-02 at 19:41, Jeff Johnson wrote:
> On Wed, Apr 02, 2003 at 07:02:19PM +0200, David Eriksson wrote:
> > Hello,
> > 
> > First, the obligatory credits: Thank you very much for writing valgrind!
> > 
> > When I recently subscribed to this mailing list I read a message from
> > Nicholas Nethercote where he said that 1.9.4 was more stable and worked
> > better than 1.0.4 so I thought I'd give it a try.
> > 
> > However, it seems to me like something has changed between the two
> > versions, maybe regarding the combination threads and sockets.
> > 
> > I am running RedHat 8.0, with the latest updates installed:
> > 
> >   kernel-2.4.18-27.8.0
> >   glibc-2.3.2-4.80
> >   gcc-3.2-7
> > 
> > The application I'm examining with valgrind is a threaded server
> > application written in C that uses glib. It is quite large and
> > complicated to install, so there is no point in providing it.
> > 
> > I have tried to make a scaled-down example to reproduce my problem. It
> > is not finished yet, but I thought that I'll try to describe the problem
> > in case anyone has any suggestions:
> > 
> > The server creates a unix socket and makes glib poll() the socket for
> > events. A client connects to the server, which accept() the connection
> > and creates a new thread for handling the connection.
> > 
> > By using simple "printf debugging" it seems like the the new thread
> > never gets scheduled to run in valgrind 1.9.4.
> > 
> > For the fun of it, I tried to send a SIGHUP to my process. There is
> > singal handler installed with signal() for SIGHUP, which gets executed
> > properly. What also happens is that all threads (one for each connection
> > that have been made to the server) get to run!
> > 
> > Do you have any ideas?
> 
> FYI: You're running a NPTL capable library with a NPTL deprived kernel.
> 
> Meanwhile, prefix your valgrind command with
> 	LD_ASSUME_KERNEL=2.2.5 valgrind ...
> to force use of Good Old libpthread.

Well, pthread is never loaded when using valgrind as valgrind maintains
its own thread scheduling:

...
==29456== Reading syms from /usr/local/lib/valgrind/libpthread.so
...

-- 
-\- David Eriksson -/-                              www.2GooD.nu
 
"I personally refuse to use inferior tools because of ideology."
                                                - Linus Torvalds

[Valgrind-users] unable to build rpm from valgrind-1.0.4 on RedHat 8.0

[Brian W. <bri...@av...>]

Hello all,
I have downloaded valgrind-1.0.4 on a RedHat 8.0 with a 2.4.18-14smp kernel
and did the ./configure, make and make install without a problem. I then
tried to build a rpm package using the valgrind.spec file which create the
valgrind-1.0.4 using rpmbuild -ba valgrind.spec and everything looked good
until I tried to install the rpm I got the following failed dependency
error.
error: Failed dependencies:
        libc.so.6(GLIBC_PRIVATE) is needed by valgrind-1.0.4-1
I did a strings /lib/libc.so.6 |grep -i private and it did return
GLIBC_PRIVATE.
Has anyone got this to work?

Brian S. Wince 
Sr. Unix/Linux Administrator 
Information Technology
AltaVista
bri...@av... 
650.320.6485 

 

Re: [Valgrind-users] "still reachable" memory from g++'sstd::string

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

On Wed, Apr 02, 2003 at 09:49:46AM -0800, Jeremy Fitzhardinge wrote:
> On Wed, 2003-04-02 at 08:34, Olly Betts wrote: 
> 
> > On Wed, Apr 02, 2003 at 11:23:34AM -0500, Maarten Ballintijn wrote:
> > > >         >           {
> > > >         >             std::string s;
> > > >         >             s += '0';
> > > >         >           }
> > > >         >           exit(0);
> > 
> > > Just out of curiosity, why would s be destructed if you call exit()?
> > 
> > s is destructed at the end of the block where it's defined - i.e. the
> > line before exit is called.
> 
> Do you mean the compiler is treating exit specially?

No.  Look at the code.  s is destructed at the end of the block it is
defined in.  That's how C++ works.  What happens after the block is
irrelevant to that destruction.

> Is that because
> its a noreturn function?  That still can't be right: if it were a
> noreturn function which takes a std::string argument, then it would be
> wrong to destruct the string before passing it.

But it couldn't take s as an argument, as s isn't in scope at that
point!

Cheers,
    Olly

Re: [Valgrind-users] "still reachable" memory from g++'sstd::string

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

On Wed, 2003-04-02 at 09:10, Maarten Ballintijn wrote:

> Thanks! Silly me, completely missed the extra braces :-/

Oh, yeah.  Mass silliness.

        J

Re: [Valgrind-users] valgrind and poll()

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

On Wed, 2003-04-02 at 09:02, David Eriksson wrote:

> For the fun of it, I tried to send a SIGHUP to my process. There is
> singal handler installed with signal() for SIGHUP, which gets executed
> properly. What also happens is that all threads (one for each connection
> that have been made to the server) get to run!
> 
> Do you have any ideas?
> 
> I will happily provide any more information that may be of interest.

What does strace have to say about your running process?  Is it blocked
in a a system call, or does it seem to be spinning away happily?

It's possible that the libc poll (or some other blocking system call) is
somehow getting called without being intercepted by Valgrind.

        J

Re: [Valgrind-users] valgrind and poll()

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

On Wed, 2003-04-02 at 09:41, Jeff Johnson wrote:

> FYI: You're running a NPTL capable library with a NPTL deprived kernel.
> 
> Meanwhile, prefix your valgrind command with
> 	LD_ASSUME_KERNEL=2.2.5 valgrind ...
> to force use of Good Old libpthread.

Are you sure?  There's only one libpthread in that glibc package; can
the one library do both NPTL and linuxthreads?

        J

Re: [Valgrind-users] "still reachable" memory from g++'sstd::string

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

On Wed, 2003-04-02 at 08:34, Olly Betts wrote: 

> On Wed, Apr 02, 2003 at 11:23:34AM -0500, Maarten Ballintijn wrote:
> > >         >           {
> > >         >             std::string s;
> > >         >             s += '0';
> > >         >           }
> > >         >           exit(0);
> 
> > Just out of curiosity, why would s be destructed if you call exit()?
> 
> s is destructed at the end of the block where it's defined - i.e. the
> line before exit is called.

Do you mean the compiler is treating exit specially?  Is that because
its a noreturn function?  That still can't be right: if it were a
noreturn function which takes a std::string argument, then it would be
wrong to destruct the string before passing it.

    J

Re: [Valgrind-users] valgrind and poll()

[Jeff J. <jb...@re...>]

On Wed, Apr 02, 2003 at 07:02:19PM +0200, David Eriksson wrote:
> Hello,
> 
> First, the obligatory credits: Thank you very much for writing valgrind!
> 
> When I recently subscribed to this mailing list I read a message from
> Nicholas Nethercote where he said that 1.9.4 was more stable and worked
> better than 1.0.4 so I thought I'd give it a try.
> 
> However, it seems to me like something has changed between the two
> versions, maybe regarding the combination threads and sockets.
> 
> I am running RedHat 8.0, with the latest updates installed:
> 
>   kernel-2.4.18-27.8.0
>   glibc-2.3.2-4.80
>   gcc-3.2-7
> 
> The application I'm examining with valgrind is a threaded server
> application written in C that uses glib. It is quite large and
> complicated to install, so there is no point in providing it.
> 
> I have tried to make a scaled-down example to reproduce my problem. It
> is not finished yet, but I thought that I'll try to describe the problem
> in case anyone has any suggestions:
> 
> The server creates a unix socket and makes glib poll() the socket for
> events. A client connects to the server, which accept() the connection
> and creates a new thread for handling the connection.
> 
> By using simple "printf debugging" it seems like the the new thread
> never gets scheduled to run in valgrind 1.9.4.
> 
> For the fun of it, I tried to send a SIGHUP to my process. There is
> singal handler installed with signal() for SIGHUP, which gets executed
> properly. What also happens is that all threads (one for each connection
> that have been made to the server) get to run!
> 
> Do you have any ideas?

FYI: You're running a NPTL capable library with a NPTL deprived kernel.

Meanwhile, prefix your valgrind command with
	LD_ASSUME_KERNEL=2.2.5 valgrind ...
to force use of Good Old libpthread.

73 de Jeff

-- 
Jeff Johnson	ARS N3NPQ
jb...@re... (jb...@jb...)
Chapel Hill, NC

[Valgrind-users] valgrind and poll()

[David E. <da...@2g...>]

Hello,

First, the obligatory credits: Thank you very much for writing valgrind!

When I recently subscribed to this mailing list I read a message from
Nicholas Nethercote where he said that 1.9.4 was more stable and worked
better than 1.0.4 so I thought I'd give it a try.

However, it seems to me like something has changed between the two
versions, maybe regarding the combination threads and sockets.

I am running RedHat 8.0, with the latest updates installed:

  kernel-2.4.18-27.8.0
  glibc-2.3.2-4.80
  gcc-3.2-7

The application I'm examining with valgrind is a threaded server
application written in C that uses glib. It is quite large and
complicated to install, so there is no point in providing it.

I have tried to make a scaled-down example to reproduce my problem. It
is not finished yet, but I thought that I'll try to describe the problem
in case anyone has any suggestions:

The server creates a unix socket and makes glib poll() the socket for
events. A client connects to the server, which accept() the connection
and creates a new thread for handling the connection.

By using simple "printf debugging" it seems like the the new thread
never gets scheduled to run in valgrind 1.9.4.

For the fun of it, I tried to send a SIGHUP to my process. There is
singal handler installed with signal() for SIGHUP, which gets executed
properly. What also happens is that all threads (one for each connection
that have been made to the server) get to run!

Do you have any ideas?

I will happily provide any more information that may be of interest.

Regards,
 
-\- David Eriksson -/-                              www.2GooD.nu
 
"I personally refuse to use inferior tools because of ideology."
                                                - Linus Torvalds