valgrind-users — General discussion list for Valgrind users

Re: [Valgrind-users] OpenMP and Valgrind

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

Charles De Lean wrote:
> Has anyone tried using Valgrind on a program using the Intel
> implementation of OpenMP on Linux?

99.9% of us hackers haven't paid any attention to OpenMP,
since OpenMP's whole goal is to shield programmers from the
kind of details us hackers love.  (It's for C or Fortran programmers
trying to use more than one CPU on their dusty decks of
punchcards by sprinkling a few pragmas around the loops they
want parallelized.)
And I suspect Intel's OpenMP implementation isn't free,
so that makes it even less likely anyone here's tried it.

There is one free C compiler that implements OpenMP,
OdinMP.  It lives at http://odinmp.imit.kth.se/ and looks
like it'd be easy to try.
See also http://savannah.nongnu.org/projects/gomp/
- Dan

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

Re: [Valgrind-users] pthread_mutexattr_setpshared

[Matt P. <uri...@ya...>]

I was getting this before I applied the patch (that's why I installed valgrind from the rpm).
 
I'm using gcc 3.2.2 on Redhat 9.
 
I changed extern void to extern int, but I still get a bunch of compile errors.

Nicholas Nethercote <nj...@ca...> wrote:
On Thu, 3 Jul 2003, Matt Peebles wrote:

> I changed the code in vg_libpthread.c and vg_libpthread_unimp.c, but
> when I compile it I get the following:
>
> make all-recursive
> make[1]: Entering directory `/usr/src/valgrind-1.9.6'
> Making all in coregrind
> make[2]: Entering directory `/usr/src/valgrind-1.9.6/coregrind'
> Making all in demangle
> make[3]: Entering directory `/usr/src/valgrind-1.9.6/coregrind/demangle'
> g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I../../coregrind -I../../include -Winline -Wall -Wshadow -O -fomit-frame-pointer -g -Wno-unused -Wno-shadow -c cp-demangle.c -UHAVE_CONFIG_H
> In file included from cp-demangle.c:43:
> ../../coregrind/vg_include.h:1545: variable or field `vgPlain_helper_idiv_64_32
> ' declared void
> ../../coregrind/vg_include.h:1546: variable or field `vgPlain_helper_div_64_32'
> declared void

That's odd. What version of gcc are you using? Not that knowing that
would help me work out the problem. Did the same problem occur before you
applied the patch?

I assume that the 'void' errors are causing all the ones that follow.
Maybe try changing the troublesome declarations in vg_include.h from
"extern void" to "extern Int"? Sure it's a hack, but I can't think what
else to do...

N




-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01
_______________________________________________
Valgrind-users mailing list
Val...@li...
https://lists.sourceforge.net/lists/listinfo/valgrind-users


---------------------------------
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!

[Valgrind-users] OpenMP and Valgrind

[Charles De L. <ch...@dn...>]

Hello All

After looking through the archive and FAQ, I was not able to find the
answer to my question.
So here it is.

Has anyone tried using Valgrind on a program using the Intel
implementation of OpenMP
on Linux? If so, I would like to know it it behaves correctly. If
doesn't behave correctly,
I would like to know what may go wrong.

OpenMP is a standard for multithread programming which takes special
care of data
sharing between threads. Looks pretty neat. On Linux, the Intel
implementation
of this standard uses pthreads. At first view, this should be ok with
valgrind, but
since I don't know exactly how the implementation works (i.e. the code
that
gets inserted by some #pragma instructions) , I might yet miss
something.

Thank you

Charles

Re: [Valgrind-users] pthread_mutexattr_setpshared

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

On Thu, 3 Jul 2003, Matt Peebles wrote:

> I changed the code in vg_libpthread.c and vg_libpthread_unimp.c, but
> when I compile it I get the following:
>
> make  all-recursive
> make[1]: Entering directory `/usr/src/valgrind-1.9.6'
> Making all in coregrind
> make[2]: Entering directory `/usr/src/valgrind-1.9.6/coregrind'
> Making all in demangle
> make[3]: Entering directory `/usr/src/valgrind-1.9.6/coregrind/demangle'
> g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I../../coregrind -I../../include     -Winline -Wall -Wshadow -O -fomit-frame-pointer -g -Wno-unused -Wno-shadow -c cp-demangle.c -UHAVE_CONFIG_H
> In file included from cp-demangle.c:43:
> ../../coregrind/vg_include.h:1545: variable or field `vgPlain_helper_idiv_64_32
>    ' declared void
> ../../coregrind/vg_include.h:1546: variable or field `vgPlain_helper_div_64_32'
>    declared void

That's odd.  What version of gcc are you using?  Not that knowing that
would help me work out the problem.  Did the same problem occur before you
applied the patch?

I assume that the 'void' errors are causing all the ones that follow.
Maybe try changing the troublesome declarations in vg_include.h from
"extern void" to "extern Int"?  Sure it's a hack, but I can't think what
else to do...

N

Re: [Valgrind-users] New experimental skin: signal handler checker

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

On Thu, 3 Jul 2003, Dan Kegel wrote:

> > But that would be fine, a static checker would be better.
>
> We need both!
>
> Consider the case where you're doing QA on an open source
> project which is huge and hard to compile, and the developers haven't
> seen fit to run the static checker on the whole source base yet.
> Or consider a closed-source app.  In both cases, the dynamic
> checker will work, and the static one won't (because the source is
> hard to get or configure).

Good point.  Three cheers for dynamic binary translation! :)

N

Re: [Valgrind-users] New experimental skin: signal handler checker

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

>I had thought that this signal handler checking would 
>be much better done statically.  Crocus may be put out
>of business before it's even started! 

Doing it at compile time would be
better...however...there's many times I'm helping someone
and out of curiousity we run valgrind, libsafe, or electric
fence to see what's going on with the binary.

There will always be a need for tools that do not require
getting the source code just to check out a misbehaving
application. You also may not have the source code if its a
commercial app. You could still check it out and send a
better bug report.

-Steve Grubb

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

Re: [Valgrind-users] New experimental skin: signal handler checker

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

Nicholas Nethercote wrote:
> On Thu, 3 Jul 2003, Dan Kegel wrote:
>>BTW, this tool of yours is pretty cool.  I bet a similar
>>test could be applied at compile time using smatch
>>http://smatch.sourceforge.net/
>>That'd be quite a combination -- catch a bunch of them statically,
>>and then use your dynamic tool to find some the static checker missed...
> 
> 
> Ah, I was aware of the Stanford checking project but not smatch.  That's
> cool.  I had thought that this signal handler checking would be much
> better done statically.  Crocus may be put out of business before it's
> even started!  But that would be fine, a static checker would be better.

We need both!

> You mention using the dynamic tool for the ones the static tool misses,
> have you used smatch and know that static misses are common, or is this
> just a guess?  I imagine that signal handler checking would be pretty
> straightforward to do statically.  And once people know they shouldn't
> call these function from signal handlers, it's not a problem that's hard
> to fix, it's more just a case of knowing about it in the first place.  As
> opposed to eg. memory errors, where a dynamic automated tool is very
> useful for finding obscure bugs.

Consider the case where you're doing QA on an open source
project which is huge and hard to compile, and the developers haven't
seen fit to run the static checker on the whole source base yet.
Or consider a closed-source app.  In both cases, the dynamic
checker will work, and the static one won't (because the source is
hard to get or configure).

- Dan

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

Re: [Valgrind-users] New experimental skin: signal handler checker

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

On Thu, 3 Jul 2003, Dan Kegel wrote:

> BTW, this tool of yours is pretty cool.  I bet a similar
> test could be applied at compile time using smatch
> http://smatch.sourceforge.net/
> That'd be quite a combination -- catch a bunch of them statically,
> and then use your dynamic tool to find some the static checker missed...

Ah, I was aware of the Stanford checking project but not smatch.  That's
cool.  I had thought that this signal handler checking would be much
better done statically.  Crocus may be put out of business before it's
even started!  But that would be fine, a static checker would be better.

You mention using the dynamic tool for the ones the static tool misses,
have you used smatch and know that static misses are common, or is this
just a guess?  I imagine that signal handler checking would be pretty
straightforward to do statically.  And once people know they shouldn't
call these function from signal handlers, it's not a problem that's hard
to fix, it's more just a case of knowing about it in the first place.  As
opposed to eg. memory errors, where a dynamic automated tool is very
useful for finding obscure bugs.

N

Re: [Valgrind-users] New experimental skin: signal handler checker

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

Nicholas Nethercote wrote:
> Doing the same on my system, I also got these ones (that weren't on the
> original blacklist):
> 
>  ether_ntoa ether_aton
>  nis_leaf_of nis_name_of nis_domain_of nis_sperror
>  getaliasent getaliasbyname gethostbyname2 getservbyname
>  getnetgrent getpwnam getspent getspnam
>  sgetspent fgetspent
>  rand
>  ptsname getdate getutent getutid getutline
>  BIO_gethostbyname
> 
> Should they go in too?

You can check SuSv3 for each standard function; it's pretty good about
telling you what's threadsafe/reentrant and what isn't.
e.g. http://www.opengroup.org/onlinepubs/007904975/functions/rand.html
says
   "[CX]  The rand() function need not be reentrant.
    A function that is not required to be reentrant is not required to be thread-safe. "

BTW, this tool of yours is pretty cool.  I bet a similar
test could be applied at compile time using smatch
http://smatch.sourceforge.net/
That'd be quite a combination -- catch a bunch of them statically,
and then use your dynamic tool to find some the static checker missed...
- Dan

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

Re: [Valgrind-users] New experimental skin: signal handler checker

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

In message <200...@we...>
        Steve G. <lin...@ya...> wrote:

> nis_*, BIO_*, pts*, getut*, ?getspent, getsp* are
> undocumented (no man page). I suppose we can err on the
> side of caution by adding all of them and wait for someone
> to prove it otherwise.

ptsname is documented in SUS:

  http://www.opengroup.org/onlinepubs/007904975/functions/ptsname.html

Most of BIO_* has manual pages, just not that one routine as far 
as I can see. I haven't checked openssl.org to see if there is any
doco there for it.

Tom

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

Re: [Valgrind-users] New experimental skin: signal handler checker

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

> ether_ntoa ether_aton
> nis_leaf_of nis_name_of nis_domain_of nis_sperror
> getaliasent getaliasbyname gethostbyname2 getservbyname
> getnetgrent getpwnam getspent getspnam
> sgetspent fgetspent
> rand
> ptsname getdate getutent getutid getutline
> BIO_gethostbyname
>
>Should they go in too?

Some of these are esoteric and/or undocumented. For
example, getaliasent has no man page. What does it do? Is
it a public API? With no man page, I have no idea what its
doing or if its safe.

The ether functions page says it uses static buffers, so
adding this would be good.

nis_*, BIO_*, pts*, getut*, ?getspent, getsp* are
undocumented (no man page). I suppose we can err on the
side of caution by adding all of them and wait for someone
to prove it otherwise.

-Steve Grubb

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

Re: [Valgrind-users] New experimental skin: signal handler checker

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

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

> Doing the same on my system, I also got these ones (that weren't on the
> original blacklist):
>
>  ether_ntoa ether_aton

These look like they need to go it.

>  nis_leaf_of nis_name_of nis_domain_of nis_sperror
>  getaliasent getaliasbyname

I can't see any documentation for these, so it's difficult to say.

>  gethostbyname2 getservbyname

These look like they need to go it.

>  getnetgrent

Probably, although it doesn't seem to have a manual page.

>  getpwnam

I think this is already in isn't it? If it isn't then it needs to go in.

>  getspent getspnam
>  sgetspent fgetspent

These are for the shadow file, and probably need to go in although
they don't seem to have manual pages...

>  rand

Yes, along with srand if it isn't in the other list.

>  ptsname

Probably, although it doesn't seem to have a manual page.

>  getdate getutent getutid getutline

Yes, along with pututline I think.

>  BIO_gethostbyname

That's an openssl routine. It may need to go in though, but I was
mainly looking at C library routines.

Tom

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

Re: [Valgrind-users] New experimental skin: signal handler checker

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

On Thu, 3 Jul 2003, Tom Hughes wrote:

> Well "find /usr/include -name *.h -print0 | xargs -0 grep '_r *('" suggests
> quite a lot, including:
>
> gethostent
> getnetent getnetbyname getnetbyaddr
> getservent getservbyport
> getprotoent getprotobyname getprotobynumber
> getrpcent getrpcbyname getrpcbynumber
> getmntent
> fgetpwent fgetgrent
> tmpnam
> random srandom initstate setstate
> drand48 erand48 lrand48 nrand48 mrand48 jrand48 srand48 seed48 lcong48
> ecvt fcvt qecvt qfcvt
> strerror
> crypt
> setkey encrypt
> hcreate hsearch hdestroy

Ok, I'll add them.

Doing the same on my system, I also got these ones (that weren't on the
original blacklist):

 ether_ntoa ether_aton
 nis_leaf_of nis_name_of nis_domain_of nis_sperror
 getaliasent getaliasbyname gethostbyname2 getservbyname
 getnetgrent getpwnam getspent getspnam
 sgetspent fgetspent
 rand
 ptsname getdate getutent getutid getutline
 BIO_gethostbyname

Should they go in too?

Thanks very much for the help.

N

Re: [Valgrind-users] New experimental skin: signal handler checker

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

>Well "find /usr/include -name *.h -print0 | xargs -0 grep
'_r
>*('" suggests quite a lot, including:

Yup. It also seems that the glibc documentation is not
complete either. Looking at the getnetent function man
page, it doesn't mention the word re-entrant anywhere. It
also doesn't mention where the returned data structure came
from and whether or not you are supposed to free it. Glibc
man pages needs patching, too.

-Steve Grubb

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

RE: [Valgrind-users] New experimental skin: signal handler checker

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

>And maybe I should use the term "signal safe" when talking

>about functions that can be called from signal handlers,
>rather than "reentrant"? Or are they the same thing?

They are different. A function that is re-entrant is one
that may be called by a different thread of execution
concurrently and it won't cause any ill effects. 

Signal safe means that the function is not using static
data buffers, not using library data structures that may be
in unsafe state, and only calling functions that are in the
whitelist or functions composed of those on the whitelist.

Signal handlers should be both signal-safe and re-entrant.
Common functions in a Pthreads program should be
re-entrant.

Glad to see other people finding bugs in signal handlers.
This was the area of most problems in a lot of code reviews
I've been doing. I'm reviewing some code from freeradius
right now and its sigchld signal handler does bad
things...which might explain why it crashes after 6-7 days
of heavy use. Fixing signal handlers is simple once you are
aware of a problem. It seems people were not aware.

-Steve Grubb

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

Re: [Valgrind-users] New experimental skin: signal handler checker

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

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

>    Char* bad_funcs[] = {
>       "_IO_printf", "_IO_puts",
>       "syslog", "strdup",
>       "__libc_malloc", "__libc_calloc", "__libc_realloc", "__libc_free",
>       "inet_ntoa", "gethostbyname", "gethostbyaddr", "getservbynam",
>       "readdir", "__readdir", "__readdir64", "strtok",
>       "ttyname", "getttyname", "getlogin", "cuserid",
>       "getpwent", "getpwnam", "getpwuid",
>       "getgrent", "getgrnam", "getgrgid",
>       "asctime", "ctime", "gmtime", "localtime",
>       "fclose", "fflush", "fflush_unlocked", "fopen", "freopen",
>       "fdopen", "fopencookie", "fmemopen", "open_memstream",
>       "fprintf", "vfprintf", "fscanf", "vfscanf", "fgetc", "getc",
>       "getc_unlocked", "fgetc_unlocked", "fputc", "putc", "fputc_unlocked",
>       "putc_unlocked", "getw", "putw", "fgets", "fputs", "ungetc", "fseek",
>       "rewind",
>       "__pthread_mutex_lock", "__pthread_mutex_unlock",
>       "__pthread_mutex_trylock",
>       NULL
>    };
>
> I'd welcome suggestions for new ones, or any corrections.

Well "find /usr/include -name *.h -print0 | xargs -0 grep '_r *('" suggests
quite a lot, including:

gethostent
getnetent getnetbyname getnetbyaddr
getservent getservbyport
getprotoent getprotobyname getprotobynumber
getrpcent getrpcbyname getrpcbynumber
getmntent
fgetpwent fgetgrent
tmpnam
random srandom initstate setstate
drand48 erand48 lrand48 nrand48 mrand48 jrand48 srand48 seed48 lcong48
ecvt fcvt qecvt qfcvt
strerror
crypt
setkey encrypt
hcreate hsearch hdestroy

Tom

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

RE: [Valgrind-users] New experimental skin: signal handler checker

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

On Thu, 3 Jul 2003, Troels Walsted Hansen wrote:

> I tried your skin on RH8 + all current updates.
>
> It seems to work great and identified a potential deadlock (calling
> pthread_mutex_unlock() in a SIGINT/SIGTERM handler) in one of the
> applications I tried it with.
>
> Didn't encounter any problems.
>
> Definitely a nice addition to Valgrind's skin arsenal.

Great, thanks for the feedback, I'm glad it worked well for you.

----

Warning: here be Technical mumbo-jumbo...

In practice, I don't know how likely deadlock is if you call
pthread_mutex_unlock() from a signal handler, but the LinuxThreads
pthread_mutex_lock() man page says this:

  ASYNC-SIGNAL SAFETY
     The mutex functions are not async-signal safe. What this means is  that
     they should not be called from a signal handler. In particular, calling
     pthread_mutex_lock or pthread_mutex_unlock from a  signal  handler  may
     deadlock the calling thread.

Similar advice is given at www.burningvoid.com/iaq/posix-signals.html:

     One important safety tip is that pthreads constructs like mutexes,
     condition variables, etc. do not have defined behavior inside signal
     handlers. So you cannot use pthreads calls or synchronize with other
     threads while inside a signal handler.

Currently the only pthread functions in the blacklist are
pthread_mutex_{lock,unlock,trylock}, maybe others (eg.  condition variable
ones) should be too.  The blacklist currently looks like this:

   Char* bad_funcs[] = {
      "_IO_printf", "_IO_puts",
      "syslog", "strdup",
      "__libc_malloc", "__libc_calloc", "__libc_realloc", "__libc_free",
      "inet_ntoa", "gethostbyname", "gethostbyaddr", "getservbynam",
      "readdir", "__readdir", "__readdir64", "strtok",
      "ttyname", "getttyname", "getlogin", "cuserid",
      "getpwent", "getpwnam", "getpwuid",
      "getgrent", "getgrnam", "getgrgid",
      "asctime", "ctime", "gmtime", "localtime",
      "fclose", "fflush", "fflush_unlocked", "fopen", "freopen",
      "fdopen", "fopencookie", "fmemopen", "open_memstream",
      "fprintf", "vfprintf", "fscanf", "vfscanf", "fgetc", "getc",
      "getc_unlocked", "fgetc_unlocked", "fputc", "putc", "fputc_unlocked",
      "putc_unlocked", "getw", "putw", "fgets", "fputs", "ungetc", "fseek",
      "rewind",
      "__pthread_mutex_lock", "__pthread_mutex_unlock",
      "__pthread_mutex_trylock",
      NULL
   };

I'd welcome suggestions for new ones, or any corrections.

Crocus also has a --strict option, which uses a whitelist instead of a
blacklist;  any function called from a signal handler that's not on the
whitelist causes a warning.  Unfortunately, user-defined functions can be
reentrant so that's not such a good approach.  For completeness, and in
case you're having trouble sleeping, here's the current whitelist:

   /* From "Advanced Programming in the UNIX Environment", Stevens, p278.
      Those marked with a "+" are not specified by POSIX.1 as reentrant,
      but are listed in the SVR4 SVID. */
   Char* good_funcs[] = {
      "_exit", "abort"/*+*/, "access", "alarm",
      "cfgetispeed", "cfgetospeed", "cfsetispeed", "cfsetospeed",
      "chdir", "chmod", "chown", "close", "creat", "dup", "dup2", "execle",
      "execve", "exit"/*+*/, "fcntl", "fork", "fstat",
      "getegid", "geteuid", "getgid", "getgroups", "getpgrp", "getpid",
      "getppid", "getuid",
      "kill", "link", "longjmp"/*+*/, "lseek", "mkdir", "mkfifo", "open",
      "pathconf", "pause", "pipe", "read", "rename", "rmdir",
      "setgid", "setpgid", "setsid", "setuid",
      "__sigaction", "__libc_sigaction",
      "sigaddset", "sigdelset", "sigemptyset", "sigfillset",
      "sigismember", "signal"/*+*/, "sigpending",
      "__sigprocmask",
      "sigsuspend",
      "sleep", "stat", "sysconf",
      "tcdrain", "tcflow", "tcflush", "tcgetattr", "tcgetpgrp", "tcsendbreak",
      "tcsetattr", "tcsetpgrp", "time", "times", "umask", "uname", "unlink",
      "utime", "wait", "waitpid", "write",
      NULL
   };

And maybe I should use the term "signal safe" when talking about functions
that can be called from signal handlers, rather than "reentrant"?  Or are
they the same thing?  I haven't quite worked out the exact differences
between "signal safe", "thread safe", and "reentrant".  AFAICT, they're
all pretty similar, but there might be some functions that satisfy one but
not all the definitions?

N

RE: [Valgrind-users] New experimental skin: signal handler checker

[Troels W. H. <tr...@th...>]

Hi Nicholas,

I tried your skin on RH8 + all current updates.

It seems to work great and identified a potential deadlock (calling
pthread_mutex_unlock() in a SIGINT/SIGTERM handler) in one of the
applications I tried it with.

Didn't encounter any problems.

Definitely a nice addition to Valgrind's skin arsenal.

Troels

> -----Original Message-----
> From: val...@li... 
> [mailto:val...@li...] On Behalf 
> Of Nicholas Nethercote
> Sent: 2. juli 2003 12:06
> To: Valgrind Users
> Subject: [Valgrind-users] New experimental skin: signal 
> handler checker
> 
> 
> Hi,
> 
> I've written a new skin for Valgrind.  It's called Crocus, 
> and it searches
> for problems in signal handlers.
> 
> Because signal handlers can be called at any time, they 
> shouldn't call any
> functions that are non-reentrant, ie. functions that will 
> screw up if they
> are interrupted by another call to themselves, usually 
> because some shared
> or global data structure could be corrupted or overwritten.  Many
> functions are non-reentrant, including lots of common ones 
> like printf()
> (most standard I/O functions, in fact) and malloc().  You also aren't
> supposed to call any pthread functions from signal handlers, 
> as this can
> cause deadlock.
> 
> Lots of programs don't get this right;  Vim, for example.  Crocus
> identifies when a program's interrupt handler calls one of a number of
> common non-reentrant functions.  It also identifies when an interrupt
> handler doesn't preserve errno as it should.  To run this skin,
> download valgrind-CROCUS.tar.bz2 from:
> 
  www.cl.cam.ac.uk/~njn25/valgrind.html

install as normal, and run it with the --skin=crocus option. It's a
little
bit experimental, but has been tested reasonably well.   Thanks to Steve
Grubb for the original idea and testing it on a variety of programs.

I welcome any feedback.

N



-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01
_______________________________________________
Valgrind-users mailing list
Val...@li...
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] pthread_mutexattr_setpshared

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

On Wed, 2 Jul 2003, Matt Peebles wrote:

> I'm using a valgrind 1.9.6 binary on RedHat 9 that I downloaded from
> http://dag.wieers.com/packages/valgrind/
>
> and my program stops after the following message is displayed:
>
> ==14694== valgrind's libpthread.so: UNIMPLEMENTED FUNCTION: pthread_mutexattr_setpshared
>
> Do I need to compile my own binary to get around this problem?

No, the problem is that Valgrind's implementation of pthreads doesn't
support this function.

You might be able to get things working by adding a partial implementation
of pthread_mutexattr_setpshared.  Try the patch below... if the 'pshared'
attribute is PTHREAD_PROCESS_PRIVATE it will succeed, and do nothing,
which should be ok, since Valgrind's mutexes are 'private' by default.
If the 'pshared' attribute is PTHREAD_PROCESS_SHARED, it will fail with
ENOSYS, meaning "can't handle this request".  This might get things
working if your program doesn't rely on having process-shared mutexes.

I'd like to know if this works for you;  if so it should probably be
folded into the main branch.  Thanks.

N




Index: coregrind/vg_libpthread.c
===================================================================
RCS file: /cvsroot/valgrind/valgrind/coregrind/vg_libpthread.c,v
retrieving revision 1.127
diff -u -3 -p -r1.127 vg_libpthread.c
--- coregrind/vg_libpthread.c   13 Jun 2003 12:24:41 -0000      1.127
+++ coregrind/vg_libpthread.c   3 Jul 2003 08:13:22 -0000
@@ -906,6 +906,10 @@ int __pthread_mutexattr_destroy(pthread_
    return 0;
 }

+int pthread_mutexattr_setpshared ( pthread_mutexattr_t* attr, int pshared)
+{
+   return ENOSYS;
+}

 /* ---------------------------------------------------
    MUTEXes
Index: coregrind/vg_libpthread_unimp.c
===================================================================
RCS file: /cvsroot/valgrind/valgrind/coregrind/vg_libpthread_unimp.c,v
retrieving revision 1.40
diff -u -3 -p -r1.40 vg_libpthread_unimp.c
--- coregrind/vg_libpthread_unimp.c     26 Apr 2003 21:19:53 -0000
1.40
+++ coregrind/vg_libpthread_unimp.c     3 Jul 2003 08:13:22 -0000
@@ -251,8 +251,8 @@ __attribute__((weak)) void pthread_mutex
                       { vgPlain_unimp("pthread_mutexattr_gettype"); }
 __attribute__((weak)) void pthread_mutexattr_setkind_np ( void )
                       { vgPlain_unimp("pthread_mutexattr_setkind_np"); }
-__attribute__((weak)) void pthread_mutexattr_setpshared ( void )
-                      { vgPlain_unimp("pthread_mutexattr_setpshared"); }
+//__attribute__((weak)) void pthread_mutexattr_setpshared ( void )
+//                      { vgPlain_unimp("pthread_mutexattr_setpshared"); }
 //__attribute__((weak)) void pthread_setconcurrency ( void )
 //                      { vgPlain_unimp("pthread_setconcurrency"); }
 __attribute__((weak)) void pthread_spin_destroy ( void )

[Valgrind-users] pthread_mutexattr_setpshared

[Matt P. <uri...@ya...>]

I'm using a valgrind 1.9.6 binary on RedHat 9 that I downloaded from http://dag.wieers.com/packages/valgrind/
 
and my program stops after the following message is displayed:
 
==14694== valgrind's libpthread.so: UNIMPLEMENTED FUNCTION: pthread_mutexattr_setpshared

Do I need to compile my own binary to get around this problem?
 
Thanks


---------------------------------
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!

[Valgrind-users] New experimental skin: signal handler checker

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

Hi,

I've written a new skin for Valgrind.  It's called Crocus, and it searches
for problems in signal handlers.

Because signal handlers can be called at any time, they shouldn't call any
functions that are non-reentrant, ie. functions that will screw up if they
are interrupted by another call to themselves, usually because some shared
or global data structure could be corrupted or overwritten.  Many
functions are non-reentrant, including lots of common ones like printf()
(most standard I/O functions, in fact) and malloc().  You also aren't
supposed to call any pthread functions from signal handlers, as this can
cause deadlock.

Lots of programs don't get this right;  Vim, for example.  Crocus
identifies when a program's interrupt handler calls one of a number of
common non-reentrant functions.  It also identifies when an interrupt
handler doesn't preserve errno as it should.  To run this skin,
download valgrind-CROCUS.tar.bz2 from:

  www.cl.cam.ac.uk/~njn25/valgrind.html

install as normal, and run it with the --skin=crocus option. It's a little
bit experimental, but has been tested reasonably well.   Thanks to Steve
Grubb for the original idea and testing it on a variety of programs.

I welcome any feedback.

N

Re: [Valgrind-users] Nontrival bug in OpenOffice caught by Valgrind?

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

On Tue, 2003-07-01 at 02:03, Dan Kegel wrote:
> http://www.openoffice.org/issues/show_bug.cgi?id=16270
> Valgrind caught OpenOffice unlocking a mutex
> with a different thread than created it... tsk.
> 
> Any chance this is a false positive?  It'd be pretty cool
> if Valgrind was right here; this would explain some
> strange problems I've seen reported in OpenOffice.

Valgrind keeps that kind of mutex metadata in the mutex_t itself, so it
could get a false positive if what actually happened was that the mutex
was trashed.  So something bad happened.

	J

Re: [Valgrind-users] Nontrival bug in OpenOffice caught by Valgrind?

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

On Tue, 1 Jul 2003, Dan Kegel wrote:

> http://www.openoffice.org/issues/show_bug.cgi?id=16270
> Valgrind caught OpenOffice unlocking a mutex
> with a different thread than created it... tsk.
>
> Any chance this is a false positive?  It'd be pretty cool
> if Valgrind was right here; this would explain some
> strange problems I've seen reported in OpenOffice.

Well, there's always a chance it's a bug in Valgrind... but tracking which
thread locks/unlocks a mutex isn't very hard, ie. it's not, AFAIK, a dark
corner of Valgrind that is difficult to get right.

N

[Valgrind-users] Nontrival bug in OpenOffice caught by Valgrind?

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

http://www.openoffice.org/issues/show_bug.cgi?id=16270
Valgrind caught OpenOffice unlocking a mutex
with a different thread than created it... tsk.

Any chance this is a false positive?  It'd be pretty cool
if Valgrind was right here; this would explain some
strange problems I've seen reported in OpenOffice.
- Dan

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

Re: [Valgrind-users] Problem with pthread_once

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

On Mon, 30 Jun 2003, Steve G wrote:

> This is a bug in valgrind. I reported it here:
> http://sourceforge.net/mailarchive/forum.php?thread_id=2573351&forum_id=32038
>
> I think it was fixed in cvs, but the cvs server rejects all
> my attempts to download...so I don't know what the final
> status is.

A change was made, I don't know if it should be called a "fix", because it
was broken in one way and is now broken in another.  However, hopefully it
will now work with you program.

N