valgrind-users — General discussion list for Valgrind users

[Valgrind-users] Valgind threading issue

[Igmar P. <mai...@jd...>]

Hi,

I've run into a problem that can be explained, but I can't determine if it 
can be solved.

The multithreaded application has 2 thread that communicate with each 
other, one writing to a fd, one reading from a fd.

Both fd's are the result of an openpty(), so simply using some variable to 
do won't work. The problem lies that Valgrind is waiting for one thread 
to finish the read, which never happens because there is no thread active 
writing.

Is there any way around the above that makes the application valgrindable 
?? I ATM just comment out the communication functions, which makes the 
other thread deallocate the pty(), so I can still see the rest of the 
application's memleaks.

Clues and hint are more then welcome :)




	Regards,


		Igmar

Re: [Valgrind-users] valgrind and dns queries

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

Julian Seward wrote:
> I guess the only advice I can offer is to avoid glibc-2.3.2 based systems
> at the moment, and to ask the glibc people to fix this bug (never do 
> PLT bypassing for calls to __errno_location, __h_errno_location or
>  __res_state).

Did you get no response to your earlier message,
http://sources.redhat.com/ml/libc-alpha/2003-05/msg00145.html
?

- Dan

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

Re: [Valgrind-users] valgrind and dns queries

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

On Wednesday 25 June 2003 10:30, Dirk Mueller wrote:
> On Mit, 25 Jun 2003, Vijay Kamath wrote:
> > Any updates on this?
>
> I can reproduce the problem. I don't know what the exact problem is though
> or how to fix it.

The problem doesn't occur on glibc-2.2.X systems, according to my
regression tests.  So far I have only confirmation of it on glibc-2.3.2
(SuSE 8.2).  And the failure only occurs if the call to res_search happens
in a thread which is not the main thread.

In vg_libpthread.c, see the function __res_state() (line 1640 in cvs).
If it is modified to always return & _res regardless of tid, the failure
no longer occurs.  This is not however a good fix.

I have seen this kind of problem before with glibc-2.3.2, when
handling errno.  (The Wine people also got hit by errno problems).
The resolver depends on some thread-specific state.  Usually it
obtains a pointer to the thread's state block, by calling __res_state().
Problem occurs (probably) because somewhere in libc or libresolv,
this mechanism is bypassed, and _res, which holds the resolver state
for the root thread, is incorrectly used regardless of the thread id.

This might be due to over-enthusiastic PLT bypassing.  Certainly it
makes it impossible for valgrind to make the resolver work correctly
in threaded programs on glibc-2.3.2 based systems.

As a point of reference, we have confirmed that the same problem
happens with handling of errno on glibc-2.3.2: references to errno
should turn into *__errno_location(), and it would all work fine if it
always did consistently, but in glibc-2.3.2 it doesn't.

I guess the only advice I can offer is to avoid glibc-2.3.2 based systems
at the moment, and to ask the glibc people to fix this bug (never do 
PLT bypassing for calls to __errno_location, __h_errno_location or
 __res_state).

If anyone has any further clarifications/insights into this I would be
grateful to hear them.

J

[Valgrind-users] README_MISSING_SYSCALL_OR_IOCTL out of date with V 1.9.6

[Anne D. <an...@ma...>]

Very very small point but could be important for someone new to
Valgrind -- I had to do some hunting to figure out how to change my
personalized IOCTLs from 1.0.x. (I use Valgrind on click, which is
custom packet handling software with a Linux kernel-loadable module
that defines several of its own IOCTLs.)

"README_MISSING_SYSCALL_OR_IOCTL" still talks about calling
"must_be_readable" and "must_be_writable". It looks like these should
be changed to SYSCALL_TRACK(pre_mem_read, ...) and
SYSCALL_TRACK(pre_mem_write, ...).

One question: What's the difference between 'pre_mem_read' and
'pre_mem_read_asciiz'?

-Anne

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

[Byrial J. <bj...@pr...>]

Someone wrote:
> 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.

Igmar Palsenberg wrote:
> I don't look at them anymore, I mainly use FreeBSD's manpage. There tons 
> of functions (ttyname() is a recent one I ran into) that return static 
> memory, but that isn't mentioned.

Please note that the real glibc documentation is *not* in man pages, but
can be found in info files. Any existing man pages are not officially part
of glibc and may not be accurate.

And in fact the glibc manual mentions that getnetent is not reentrant,
and that ttyname returns a statically-allocated string.

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

[Igmar P. <mai...@jd...>]

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

I don't look at them anymore, I mainly use FreeBSD's manpage. There tons 
of functions (ttyname() is a recent one I ran into) that return static 
memory, but that isn't mentioned.



	Igmar

Re: [Valgrind-users] Chaperon from Parasoft

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

On Mon, 7 Jul 2003, Denis Perchine wrote:

> It seems like Parasoft (parasoft.com) has a tool Chaperon similar to valgrind.
> It is a part of Insure++. And available only for i386.
> Does anyone tried it? Does it have something interesting valgrind lacks?

A price tag of $1595 for a single copy?  A non-GPL licence? :)

The feature list looked pretty similar, once you filter out the marketing
hype.

> Could it be that it is a changed version of valgrind?
>
> Actually there are lot of questions arises when you see a tool which is
> similar to what we have. :-))

Such as?  [if that sounds terse, it's not meant to be, I'm curious]

N

RE: [Valgrind-users] Chaperon from Parasoft

[Greg H. <ho...@lu...>]

On 07-Jul-2003 Denis Perchine wrote:
> Hello,
> 
> It seems like Parasoft (parasoft.com) has a tool Chaperon similar to
> valgrind.
> It is a part of Insure++. And available only for i386.
> Does anyone tried it? Does it have something interesting valgrind lacks?
> Could it be that it is a changed version of valgrind?
> 
> Actually there are lot of questions arises when you see a tool which is 
> similar to what we have. :-))

I'm fairly certain that Chaperon predates valgrind.

best rgds,

-Greg

+---------------------------------------------------------------------+
   You can release software that's good, software that's inexpensive, or
   software that's available on time.  You can usually release software
   that has 2 of these 3 attributes -- but not all 3.
| Greg Hosler                                   ho...@lu...    |
+---------------------------------------------------------------------+

[Valgrind-users] Re: [PATCH] JSIOCGNAME support [anniversary]

[Melchior F. <mf...@kd...>]

* Julian Seward -- Sunday 06 July 2003 14:57:
> As I remember, this patch
> requires #including a new file into coregrind/vg_unsafe.h, and 
> I am pretty paranoid about doing that because in the past such
> patches have caused compilation failures on some Linux distros
> and not others.

Well, that's of course a problem. But would it decide whether some
Linux ioctl will be supported or not? ("We don't support new ioctls,
if this means to include yet another Linux kernel header." ?)
As of now, valgrind false-positively reports "use of uninitialized
memory" and it took me hours to find out that the bug was actually
in valgrind, not in FlightGear. (I could have found out faster, but
my trust in valgrind was unlimited. ;-) It would be nice if others
wouldn't have to repeat this experience. It's not for =me=, because
I =do= have this fixed in my version.

m.  :-)

[Valgrind-users] Chaperon from Parasoft

[Denis P. <dy...@pe...>]

Hello,

It seems like Parasoft (parasoft.com) has a tool Chaperon similar to valgrind.
It is a part of Insure++. And available only for i386.
Does anyone tried it? Does it have something interesting valgrind lacks?
Could it be that it is a changed version of valgrind?

Actually there are lot of questions arises when you see a tool which is 
similar to what we have. :-))

--
Denis

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

[John R. <jr...@Bi...>]

On Wed, 2003-07-02 at 03:05, Nicholas Nethercote wrote:
> Many
> functions are non-reentrant, including lots of common ones like printf()
> (most standard I/O functions, in fact) and malloc().

Yes, but in practice the glibc implementation of printf/fprintf can be
used safely from a signal handler under restricted circumstances.  The
first is that malloc() must not be called [indirectly] from the signal
handler.  The reason why printf/fprintf would call malloc() is to
allocate a buffer for the output characters.  If the stream defaults to
non-buffered, or if the buffer has been allocated already, then
printf/fprintf does not call malloc.  So, if there has been a
[completed] call to printf/fprintf before the signal handler is invoked
[this will allocate a buffer], or if the stream defaults to non-buffered
[such as for fprintf(stderr, ...)], or if the program calls setvbuf() on
the stream before the signal handler is invoked, then printf/fprintf
need not call malloc().  Secondly, the usage from the handler must not
collide with usage of the same stream from non-signal level.  The
easiest way is to segregate entirely the signal-level streams from the
non-signal level streams, although a protocol for sharing a stream
between signal level and non-signal level also is possible.  You can
also fdopen(dup(fileno(stream)), ...) [needs error checking] to obtain a
separate stream "that goes to the same place" for use by a signal
handler.  [Output from the two streams will be intermixed.]

Of course, this is not necessarily portable to non-glibc
implementations.  But it may be useful.

Re: [Valgrind-users] Suggested changes to corecheck/tests/sigkill.c

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

On Fre, 04 Jul 2003, Matthew Emmerton wrote:

> The following patch addresses these issues and preserves the existing
> behaviour of the sigkill.c code.

Committed, thanks. 


-- 
Dirk

Re: [Valgrind-users] Yet more bugs found in OpenOffice thanks to V!

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

Julian Seward wrote:
> Dan
> 
> Great that you're working on OO.  It's an important project.  I used
> 1.1beta2 recently to make a couple of presentations and think it a great
> improvement on the 1.0.X series.
> 
> A couple of comments:
 >
> 1.  ==5982== pthread_mutex_destroy: mutex is still in use
>     ==5982==    at 0x410D2D2D: pthread_error (vg_libpthread.c:292)
>     ==5982==    by 0x410D3BEB: __pthread_mutex_destroy (vg_libpthread.c:1002)
>     ==5982==    by 0x412EA2AE: closedir (in /lib/libc-2.2.93.so)
> 
>     I believe this to be a glibc thing, in that glibc thinks that destroying a
>     mutex implicitly unlocks it.  I don't think this is a sign of trouble in
>     OO.

Right.  It's fixed in glibc-2.3.2 or so.  Similarly, there are a couple
STL errors V always finds on startup of OOo that are probably gcc bugs.
I always remove all of those from any valgrind logs I send to the OOo developers,

> 2.  Comparing runs of 1.1beta2 vs 1.0.3 on Valgrind, I get the impression
>      that 1.1 allocates many fewer blocks than 1.0.3 does (perhaps a 1/3 the
>      number).  I'm not sure that this is accurate.  However, it did make me
>      wonder if OO is using some internal memory manager that V does
>      not understand, rather than the standard malloc/new/new[] and
>      free/delete/delete[] ones?  If so, that will hinder V's ability to 
>      detect problems.

Er, I dunno... maybe when some real OOo developers start using V more heavily,
they can look at this and comment.

> 3.  Does OO (or at least some of its components) have some automated 
>      testsuite which could be run under V ?  Running regression tests on V
>      seems to have been an effective way to look for problems in other
>      projects.  It would be nice to know that OO ran all its regression tests
>      (etc, assuming there are such) in a V-clean way.

OOo does have an automated testsuite, and I proposed last night
on the de...@qa... list that we should require OOo
pass that test under Valgrind before release.  No reaction yet.
- Dan

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

Re: [Valgrind-users] Re: [PATCH] JSIOCGNAME support [anniversary]

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

On Monday 02 June 2003 09:35, Melchior FRANZ wrote:
> * Melchior FRANZ -- Friday 02 May 2003 18:33:
> > [...] I suggest the following patch.
>
> This patch has now been ignored for exactly one month. Do I have
> to consider it rejected? Because it deals with joysticks, which is
> children stuff and not taken seriously? Other reasons?   :-)

Sorry, should have replied to this earlier.  As I remember, this patch
requires #including a new file into coregrind/vg_unsafe.h, and 
I am pretty paranoid about doing that because in the past such
patches have caused compilation failures on some Linux distros
and not others.  But you're right, I should have said something
earlier about it.

J

Re: [Valgrind-users] Yet more bugs found in OpenOffice thanks to V!

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

Dan

Great that you're working on OO.  It's an important project.  I used
1.1beta2 recently to make a couple of presentations and think it a great
improvement on the 1.0.X series.

A couple of comments:

1.  ==5982== pthread_mutex_destroy: mutex is still in use
    ==5982==    at 0x410D2D2D: pthread_error (vg_libpthread.c:292)
    ==5982==    by 0x410D3BEB: __pthread_mutex_destroy (vg_libpthread.c:1002)
    ==5982==    by 0x412EA2AE: closedir (in /lib/libc-2.2.93.so)

    I believe this to be a glibc thing, in that glibc thinks that destroying a
    mutex implicitly unlocks it.  I don't think this is a sign of trouble in
    OO.

2.  Comparing runs of 1.1beta2 vs 1.0.3 on Valgrind, I get the impression
     that 1.1 allocates many fewer blocks than 1.0.3 does (perhaps a 1/3 the
     number).  I'm not sure that this is accurate.  However, it did make me
     wonder if OO is using some internal memory manager that V does
     not understand, rather than the standard malloc/new/new[] and
     free/delete/delete[] ones?  If so, that will hinder V's ability to 
     detect problems.

3.  Does OO (or at least some of its components) have some automated 
     testsuite which could be run under V ?  Running regression tests on V
     seems to have been an effective way to look for problems in other
     projects.  It would be nice to know that OO ran all its regression tests
     (etc, assuming there are such) in a V-clean way.

Promoting V use in the OO developer community can only be a good 
thing, I reckon.

J

[Valgrind-users] Yet more bugs found in OpenOffice thanks to V!

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

I've been getting more and more use out of Valgrind
while trying to reproduce bugs reported by others in OpenOffice.

The curious can search the OpenOffice bug tracking database for
mentions of Valgrind here:
http://www.openoffice.org/project/www/issues/buglist.cgi?issue_type=DEFECT&long_desc=valgrind&long_desc_type=substring

So far it's mentioned in 16 bugs, and has been crucial to reproducing
about half of them.   I needed it twice today, nothing else would do.

Thanks, guys!
- Dan

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

Re: [Valgrind-users] Suggested changes to corecheck/tests/sigkill.c

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

Matthew Emmerton wrote:
> No, we're porting to an almost-SUSv3 compliant system (FreeBSD) where
> strerror/perror does not return "Success" for errno 0, since errno 0 is
> technically not an error and the use of strerror/perror in that situation is
> undefined.

The patch looks good.  I have no objection to it, in fact, it's an improvement
regardless of which OS you run it on.  Apps should not set errno unless
they have a good reason, since at least one earlier version of some standard
didn't allow it... can't recall which...
- Dan

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

[Valgrind-users] cry for assistanse

[. <la...@ne...>]

FROM: AMSTERDAM-NETHERLANDS

Dear friend,

You may be surprised to receive this letter from me since 
you do not know me personally. I am the first son of the 
most popular black farmer in Zimbabwe who was 
murdered in the land dispute in my country. I got your 
contact through network online hence decided to write 
you. Before the death of my father, he had taken me to 
Johannesburg to deposit the sum of USD5.Million (Five 
million United States dollars), in one of the private 
security company, as he foresaw the looming danger in 
Zimbabwe. This money was deposited in a box as gem 
stones to avoid much demurrage from Security Company.

This amount was meant for the purchase of new machines 
and chemicals for the Farms and establishment of new 
farms in Swaziland. This land problem came when 
Zimbabwean President Mr. Robert Mugabe when he 
introduced a new Land Act Reform wholly affecting the 
rich white farmers and some few black farmers, and this 
resulted to the killing and mob action by Zimbabwean 
war veterans and some lunatics in the society. In fact a lot 
of people were killed because of this Land reform Act for 
which my father was one of the victims. it is against this 
background that I and my family fled Zimbabwe to South 
Africa for fear of our lives.

After which I traveled to the Netherlands and I am 
currently staying in the Netherlands where i am seeking 
political asylum and more so have decided to transfer my 
father's money to a more reliable foreign account. Since 
the law of Europe prohibits a refugee (asylum seeker) to 
open any bank account or to be involved in any financial 
transaction throughout the territorial zone of European 
Union. As the eldest child of my father, I am saddled with 
the responsibility of seeking a genuine foreign account 
where this money could be transferred without the 
knowledge of my government who are bent on taking 
everything we have got. 

The South African government seems to be playing along 
with them. I am faced with the dilemma of moving this 
amount of money out of South Africa for fear of going 
through the same experience in future. Both countries 
have similar political history. I am seeking for a partner 
who I have to entrust my future and that of my family in 
his hands, I must let you know that this transaction is risk 
free. If you accept to assist me and my family, all I want 
you to do for me, is to make arrangements with the 
security company to clear the Consignment (funds) from 
their affiliate office here in the Netherlands as i have 
already given directives for the consignment to be brought 
to the Netherlands from South Africa.

But before then all modalities will have to be put in place 
like change of ownership to the consignment. I have two 
options for you. Firstly you can choose to have certain 
percentage of the money for nominating your account for 
this transaction. Or you can go into partnership with me 
for the proper profitable investment of the money in your 
country. Whichever the option you want, feel free to 
notify me. I have also mapped out 2% of this money for 
all kinds of expenses incurred in the process of this 
transaction. If you do not prefer a partnership I am willing 
to give you 10% of the money while the remaining 88% 
will be for my investment in your country. Contact with 
me immediately while I implore you to maintain the 
absolute secrecy required in this transaction. 

Thanks, GOD BLESS YOU 

Best regards,


NOTE: 
ON YOUR INABILITY TO HANDLE THIS 
TRANSACTION RESPOND TO ME AND INFORM 
ME SO I CAN LOOK FOR SOMEONE ELSE.

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

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

Nicholas,

  I ran across a function that should be on the good_funcs
list, sem_post(). According to the man page, it has the
distinction of being the ONLY pthreads synchronization
function that is async-signal safe.

-Steve Grubb

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

Re: [Valgrind-users] Suggested changes to corecheck/tests/sigkill.c

[Matthew E. <ma...@co...>]

> Matthew Emmerton wrote:
> > However, sigaction() will return a negative error code should an error
> > occur.  Thus, setting errno = 0 prior to calling sigaction() is
unneccessary
> > since the return code (not errno) is what that application should be
> > checking to determine if an error has occurred.
>
> If you're saying "we don't need to set errno to zero", that's fine.
> All I'm pointing out is that your earlier statement, "SuSv3 says
> it's illegal to set errno to zero", is false.

Yes.  Touche.

> > Small details like this are very important for some of the non-Linux
porting
> > that is underway for valgrind.
>
> Ah, are we porting valgrind to non-Posix-compliant systems
> where it's illegal to set errno to zero?

No, we're porting to an almost-SUSv3 compliant system (FreeBSD) where
strerror/perror does not return "Success" for errno 0, since errno 0 is
technically not an error and the use of strerror/perror in that situation is
undefined.

--
Matt Emmerton

Re: [Valgrind-users] Suggested changes to corecheck/tests/sigkill.c

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

Matthew Emmerton wrote:
> However, sigaction() will return a negative error code should an error
> occur.  Thus, setting errno = 0 prior to calling sigaction() is unneccessary
> since the return code (not errno) is what that application should be
> checking to determine if an error has occurred.

If you're saying "we don't need to set errno to zero", that's fine.
All I'm pointing out is that your earlier statement, "SuSv3 says
it's illegal to set errno to zero", is false.

> Small details like this are very important for some of the non-Linux porting
> that is underway for valgrind.

Ah, are we porting valgrind to non-Posix-compliant systems
where it's illegal to set errno to zero?
- Dan

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

Re: [Valgrind-users] Suggested changes to corecheck/tests/sigkill.c

[Matthew E. <ma...@co...>]

----- Original Message ----- 
From: "Dan Kegel" <da...@ke...>
To: "Matthew Emmerton" <ma...@gs...>
Cc: <val...@li...>
Sent: Friday, July 04, 2003 6:36 PM
Subject: Re: [Valgrind-users] Suggested changes to corecheck/tests/sigkill.c


> Matthew Emmerton wrote:
> > I was reviewing the source to corecheck/tests/sigkill.c the other day
and
> > noticed some questionable code, namely:
> >
> > a) setting errno = 0.  errno should never be set by user applications
(as
> > per SUSv3)
>
> You may have misread the standard.  I just checked
> http://www.opengroup.org/onlinepubs/007904975/functions/errno.html
> and it says that no Unix library or system call will clear errno;
> it doesn't say the app can't.  In fact, it suggests it's ok for
> the app to:
>
> "An application that needs to examine the value of errno to determine the
error should
> set it to 0 before a function call, then inspect it before a subsequent
function call."

However, sigaction() will return a negative error code should an error
occur.  Thus, setting errno = 0 prior to calling sigaction() is unneccessary
since the return code (not errno) is what that application should be
checking to determine if an error has occurred.

Small details like this are very important for some of the non-Linux porting
that is underway for valgrind.

--
Matt Emmerton

Re: [Valgrind-users] Suggested changes to corecheck/tests/sigkill.c

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

Matthew Emmerton wrote:
> I was reviewing the source to corecheck/tests/sigkill.c the other day and
> noticed some questionable code, namely:
> 
> a) setting errno = 0.  errno should never be set by user applications (as
> per SUSv3)

You may have misread the standard.  I just checked
http://www.opengroup.org/onlinepubs/007904975/functions/errno.html
and it says that no Unix library or system call will clear errno;
it doesn't say the app can't.  In fact, it suggests it's ok for
the app to:

"An application that needs to examine the value of errno to determine the error should
set it to 0 before a function call, then inspect it before a subsequent function call."

- Dan

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

[Valgrind-users] Suggested changes to corecheck/tests/sigkill.c

[Matthew E. <ma...@gs...>]

I was reviewing the source to corecheck/tests/sigkill.c the other day and
noticed some questionable code, namely:

a) setting errno = 0.  errno should never be set by user applications (as
per SUSv3)
b) calling perror() without checking the return code of a library function
first (as per SUSv3)

The following patch addresses these issues and preserves the existing
behaviour of the sigkill.c code.

Comments welcome.

--- corecheck/tests/sigkill.c.orig      Fri Jul  4 16:25:28 2003
+++ corecheck/tests/sigkill.c   Fri Jul  4 16:41:30 2003
@@ -17,18 +17,19 @@
   struct sigaction  sa;

   int i;
+  int rc;
   for (i = 1; i <= 65; i++) {
      sa.sa_flags   = 0;
      sigemptyset( &sa.sa_mask );
      sa.sa_handler = abend;
-     errno = 0;
      fprintf(stderr,"setting signal %d: ", i);
-     sigaction (i /*SIGKILL*/, &sa, NULL);
-     perror ("");
-     errno = 0;
+     rc = sigaction (i /*SIGKILL*/, &sa, NULL);
+     if (rc) perror ("");
+     else fprintf(stderr,"Success\n");
      fprintf(stderr,"getting signal %d: ", i);
-     sigaction (i /*SIGKILL*/, NULL, &sa);
-     perror ("");
+     rc = sigaction (i /*SIGKILL*/, NULL, &sa);
+     if (rc) perror ("");
+     else fprintf(stderr,"Success\n");
      fprintf(stderr,"\n");
   }
   return 0;

--
Matt Emmerton

Re: [Valgrind-users] OpenMP and Valgrind

[Charles S. <sh...@ll...>]

 From what I've seen Valgrind does work for OpenMP codes built with the 
Intel compilers, with the (minor) exception that a couple of pthreads calls 
used by OpenMP are ignored or kludged, for instance:

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

==18243== valgrind's libpthread.so: KLUDGED call to: pthread_cond_destroy

This doesn't hinder the app's progress, though I wonder whether leaks will 
be misreported since pthread_attr_destroy is ignored.  Maybe this is 
documented somewhere and I just am unaware of it.

Also, in my experience a code that originally ran with 2 threads on 2 cpus 
is about 450x slower under valgrind, so it would be tough applying valgrind 
to a long-running code.

BTW, I wouldn't say that OpenMP or the codes it's used in are by definition 
dusty -- it's a big SMP parallelization timesaver and is in wide use here 
at LLNL and at other facilities that have compute-intensive scientific 
codes.  Physicists would much prefer to sprinkle pragmas rather than having 
to fuss with mutexes and semaphores and attribute objects.  It's true that 
it's an additional layer of abstraction, but so is C over assembler.

Regards-
Charles
______________________________
Charles Shereda
Computation Department
Lawrence Livermore National Lab

At 11:28 AM 7/3/2003 -0700, Dan Kegel wrote:
>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
>
>
>
>-------------------------------------------------------
>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