|
From: Bart V. A. <bar...@gm...> - 2008-02-28 10:14:21
|
[ Just subscribed to the valgrind-users mailing list ] Regarding DRD and linuxthreads: of course DRD should compile with the linuxthreads header files. The compilation issue should be fixed by this time (can't retest that right now). Currently neither DRD nor Helgrind work reasonably with linuxthreads. Both tools can be ported to linuxthreads, but this would take considerable work (at least for DRD). Bart Van Assche. On Wed, Feb 27, 2008 at 9:53 PM, Julian Seward <js...@ac...> wrote: > > Bart, are you subscribed to @users ? > > J > > ---------- Forwarded Message ---------- > > Subject: [Valgrind-users] Compile error with current svn version > Date: Wednesday 27 February 2008 20:38 > From: "Maarten Lankhorst" <m.b...@gm...> > To: val...@li... > > Hi all, > > I wanted to try the subversion version of valgrind, but it gives me a > compile error (glibc v2.3.6, gcc v4.0.3) > > drd_intercepts.c: In function 'mutex_type': > drd_intercepts.c:119: error: 'struct <anonymous>' has no member named > '__data' > > Does anyone know how to fix this? |
|
From: Nicholas N. <nj...@cs...> - 2008-02-29 09:05:09
|
On Thu, 28 Feb 2008, Bart Van Assche wrote: > [ Just subscribed to the valgrind-users mailing list ] > > Regarding DRD and linuxthreads: of course DRD should compile with the > linuxthreads header files. The compilation issue should be fixed by > this time (can't retest that right now). > > Currently neither DRD nor Helgrind work reasonably with linuxthreads. > Both tools can be ported to linuxthreads, but this would take > considerable work (at least for DRD). Is it worth just aborting immediately, with a message "sorry, DRD doesn't work on LinuxThreads matches". If it doesn't work "reasonably", don't try to work at all -- otherwise people may try it, not realise that it doesn't work well with LinuxThreads, and conclude (erroneously) that it's no good. N |
|
From: Bart V. A. <bar...@gm...> - 2008-02-29 10:38:44
|
On Fri, Feb 29, 2008 at 10:05 AM, Nicholas Nethercote <nj...@cs...> wrote: > On Thu, 28 Feb 2008, Bart Van Assche wrote: > > > [ Just subscribed to the valgrind-users mailing list ] > > > > Regarding DRD and linuxthreads: of course DRD should compile with the > > linuxthreads header files. The compilation issue should be fixed by > > this time (can't retest that right now). > > > > Currently neither DRD nor Helgrind work reasonably with linuxthreads. > > Both tools can be ported to linuxthreads, but this would take > > considerable work (at least for DRD). > > Is it worth just aborting immediately, with a message "sorry, DRD doesn't > work on LinuxThreads matches". If it doesn't work "reasonably", don't try > to work at all -- otherwise people may try it, not realise that it doesn't > work well with LinuxThreads, and conclude (erroneously) that it's no good. Good idea, but how to test which threading library is in use ? Some Linux distributions distribute both linuxthreads and the NPTL with their version of glibc, make one library the default, and allow to select the other library via LD_LIBRARY_PATH=... So the only reliable way to detect which threading library is in use is to test this at run time. The only run-time test I know of is to create a thread that calls getpid(), and to compare the result with the getpid() result in the creator thread. For linuxthreads both PID's will be different, for NPTL these will be identical. Such a test has to run as client code. But adding such a test in DRD's or Helgrind's client code would be difficult since both tools already intercept pthread_create() and pthread_join(). This is why DRD does not yet try to find out which threading library is in use. Bart. |
|
From: Nicholas N. <nj...@cs...> - 2008-02-29 23:34:50
|
On Fri, 29 Feb 2008, Bart Van Assche wrote: >> Is it worth just aborting immediately, with a message "sorry, DRD doesn't >> work on LinuxThreads matches". If it doesn't work "reasonably", don't try >> to work at all -- otherwise people may try it, not realise that it doesn't >> work well with LinuxThreads, and conclude (erroneously) that it's no good. > > Good idea, but how to test which threading library is in use ? Some > Linux distributions distribute both linuxthreads and the NPTL with > their version of glibc, make one library the default, and allow to > select the other library via LD_LIBRARY_PATH=... So the only reliable > way to detect which threading library is in use is to test this at run > time. The only run-time test I know of is to create a thread that > calls getpid(), and to compare the result with the getpid() result in > the creator thread. For linuxthreads both PID's will be different, for > NPTL these will be identical. Such a test has to run as client code. > But adding such a test in DRD's or Helgrind's client code would be > difficult since both tools already intercept pthread_create() and > pthread_join(). > > This is why DRD does not yet try to find out which threading library is in > use. Ok, fair enough. Does the documentation mention that LinuxThreads doesn't work well with DRD? N |
|
From: Bart V. A. <bar...@gm...> - 2008-03-01 07:33:21
|
On Fri, Feb 29, 2008 at 10:05 AM, Nicholas Nethercote <nj...@cs...> wrote: > Is it worth just aborting immediately, with a message "sorry, DRD doesn't > work on LinuxThreads matches". If it doesn't work "reasonably", don't try > to work at all -- otherwise people may try it, not realise that it doesn't > work well with LinuxThreads, and conclude (erroneously) that it's no good. I just committed a patch that makes DRD stop on linuxthreads systems as soon as the first thread is created. Can you please have a look at it ? Bart. |
|
From: Nicholas N. <nj...@cs...> - 2008-03-01 20:33:04
|
On Sat, 1 Mar 2008, Bart Van Assche wrote: > On Fri, Feb 29, 2008 at 10:05 AM, Nicholas Nethercote > <nj...@cs...> wrote: >> Is it worth just aborting immediately, with a message "sorry, DRD doesn't >> work on LinuxThreads matches". If it doesn't work "reasonably", don't try >> to work at all -- otherwise people may try it, not realise that it doesn't >> work well with LinuxThreads, and conclude (erroneously) that it's no good. > > I just committed a patch that makes DRD stop on linuxthreads systems > as soon as the first thread is created. Can you please have a look at > it ? It seems pretty good. I don't know much about threading libraries so I don't know if the test is robust. The message printed could be slightly more informative -- think about a user who has no idea that there have been two different pthread libraries on Linux. Something about linuxthreads being older and NPTL being newer might be useful. But it's pretty good :) N |
|
From: Igmar P. <mai...@jd...> - 2008-03-02 14:47:29
|
> Good idea, but how to test which threading library is in use ? Some
> Linux distributions distribute both linuxthreads and the NPTL with
> their version of glibc, make one library the default, and allow to
> select the other library via LD_LIBRARY_PATH=... So the only reliable
> way to detect which threading library is in use is to test this at run
> time.
Use confstr() in this case. Creating a thread for this case might create
unwanted sideaffects.
This should work :
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
int main(int argc, char **argv)
{
size_t len;
char buffer[81];
confstr(_CS_GNU_LIBPTHREAD_VERSION, buffer, sizeof(buffer));
fprintf(stderr, "%.80s\n", buffer);
return 0;
}
The result should start with either NPTL or LinuxThreads.
Regards,
Igmar
|
|
From: Bart V. A. <bar...@gm...> - 2008-03-02 16:52:57
|
On Sun, Mar 2, 2008 at 3:20 PM, Igmar Palsenberg <mai...@jd...> wrote: > > > Good idea, but how to test which threading library is in use ? Some > > Linux distributions distribute both linuxthreads and the NPTL with > > their version of glibc, make one library the default, and allow to > > select the other library via LD_LIBRARY_PATH=... So the only reliable > > way to detect which threading library is in use is to test this at run > > time. > > Use confstr() in this case. Creating a thread for this case might create > unwanted sideaffects. Do you know which value is returned by confstr() on systems where both NPTL and linuxthreads are installed ? Bart. |
|
From: Igmar P. <mai...@jd...> - 2008-03-03 08:13:14
|
>> unwanted sideaffects. > > Do you know which value is returned by confstr() on systems where both > NPTL and linuxthreads are installed ? confstr() returns the value that is actually used at that moment. It either returns NTPL <version> or linuxthreads-<version> Igmar |
|
From: Bart V. A. <bar...@gm...> - 2008-03-02 18:40:47
|
On Sat, Mar 1, 2008 at 9:32 PM, Nicholas Nethercote <nj...@cs...> wrote: > > On Sat, 1 Mar 2008, Bart Van Assche wrote: > > I just committed a patch that makes DRD stop on linuxthreads systems > > as soon as the first thread is created. Can you please have a look at > > it ? > > It seems pretty good. I don't know much about threading libraries so I > don't know if the test is robust. The message printed could be slightly > more informative -- think about a user who has no idea that there have been > two different pthread libraries on Linux. Something about linuxthreads > being older and NPTL being newer might be useful. But it's pretty good :) By this time I have changed the error message into the following: * When DRD is started with LinuxThreads and the environment variable LD_ASSUME_KERNEL is not set: Detected the LinuxThreads threading library. Sorry, but DRD only supports the newer NPTL (Native POSIX Threads Library). Please try to rerun DRD after having upgraded to a newer version of your Linux distribution. Giving up. * When DRD is started with LinuxThreads and the environment variable LD_ASSUME_KERNEL is set (this environment variable has to be set in order to use LinuxThreads on a system where both NPTL and LinuxThreads are installed): Detected the LinuxThreads threading library. Sorry, but DRD only supports the newer NPTL (Native POSIX Threads Library). Please try to rerun DRD after having unset the environment variable LD_ASSUME_KERNEL. Giving up. Bart. |
|
From: Nicholas N. <nj...@cs...> - 2008-03-02 21:05:52
|
On Sun, 2 Mar 2008, Bart Van Assche wrote: > * When DRD is started with LinuxThreads and the environment variable > LD_ASSUME_KERNEL is not set: > > Detected the LinuxThreads threading library. Sorry, but DRD only supports > the newer NPTL (Native POSIX Threads Library). Please try to rerun DRD > after having upgraded to a newer version of your Linux distribution. > Giving up. > > * When DRD is started with LinuxThreads and the environment variable > LD_ASSUME_KERNEL is set (this environment variable has to be set in > order to use LinuxThreads on a system where both NPTL and LinuxThreads > are installed): > > Detected the LinuxThreads threading library. Sorry, but DRD only supports > the newer NPTL (Native POSIX Threads Library). Please try to rerun DRD > after having unset the environment variable LD_ASSUME_KERNEL. Giving up. Looks good! N |
|
From: Igmar P. <mai...@jd...> - 2008-03-03 08:14:22
|
> By this time I have changed the error message into the following: > > * When DRD is started with LinuxThreads and the environment variable > LD_ASSUME_KERNEL is not set: > > Detected the LinuxThreads threading library. Sorry, but DRD only supports > the newer NPTL (Native POSIX Threads Library). Please try to rerun DRD > after having upgraded to a newer version of your Linux distribution. > Giving up. > > * When DRD is started with LinuxThreads and the environment variable > LD_ASSUME_KERNEL is set (this environment variable has to be set in > order to use LinuxThreads on a system where both NPTL and LinuxThreads > are installed): > > Detected the LinuxThreads threading library. Sorry, but DRD only supports > the newer NPTL (Native POSIX Threads Library). Please try to rerun DRD > after having unset the environment variable LD_ASSUME_KERNEL. Giving up. You can't depend on LD_ASSUME_KERNEL. Simply use confstr(), it should work in all cases. Igmar |
|
From: Bart V. A. <bar...@gm...> - 2008-03-03 08:26:51
|
On Mon, Mar 3, 2008 at 9:13 AM, Igmar Palsenberg <mai...@jd...> wrote: > > You can't depend on LD_ASSUME_KERNEL. Simply use confstr(), it should work > in all cases. Please have a look at the exp-drd source code -- LD_ASSUME_KERNEL is only tested after it is clear that the LinuxThreads library is in use. And I'm not sure that confstr() does work in all cases. There exist Linux distributions that include both the NPTL and LinuxThreads. I'm not sure that it is a good idea to rely on the return value of confstr() for such distributions. Bart. |
|
From: Igmar P. <mai...@jd...> - 2008-03-03 09:11:58
|
> Please have a look at the exp-drd source code -- LD_ASSUME_KERNEL is > only tested after it is clear that the LinuxThreads library is in use. You're however creating a thread, and then looking if the pid's are different. In this case, the program is already threaded, with possible side affects I'm not saying it doesn't work, we might want something that doesn't involve creating threads. > And I'm not sure that confstr() does work in all cases. There exist > Linux distributions that include both the NPTL and LinuxThreads. I'm > not sure that it is a good idea to rely on the return value of > confstr() for such distributions. This is from a distro that has both LinuxThread and NPTL : [igmar@jdi ~]$ export LD_ASSUME_KERNEL=2.2.5 [igmar@jdi ~]$ ./xxx linuxthreads-0.10 [igmar@jdi ~]$ unset LD_ASSUME_KERNEL [igmar@jdi ~]$ ./xxx NPTL 2.3.4 Regards, Igmar |
|
From: Bart V. A. <bar...@gm...> - 2008-03-03 09:19:52
|
On Mon, Mar 3, 2008 at 10:10 AM, Igmar Palsenberg <mai...@jd...> wrote: > > > And I'm not sure that confstr() does work in all cases. There exist > > Linux distributions that include both the NPTL and LinuxThreads. I'm > > not sure that it is a good idea to rely on the return value of > > confstr() for such distributions. > > This is from a distro that has both LinuxThread and NPTL : > > [igmar@jdi ~]$ export LD_ASSUME_KERNEL=2.2.5 > [igmar@jdi ~]$ ./xxx > linuxthreads-0.10 > [igmar@jdi ~]$ unset LD_ASSUME_KERNEL > [igmar@jdi ~]$ ./xxx > NPTL 2.3.4 Thanks for the information. The current behavior of exp-drd is as follows: * At client startup, call getpid() and store the result. * As soon as the first thread is created, call getpid() in the created thread and compare the result with the result of the getpid() call in the main thread. * If the result of both getpid() calls is the same, this means that the running process (Valgrind core + exp-drd + client) has been started with NTPL or that it is running on another kernel than the Linux kernel. * If the result of the two getpid() calls is not identical, this means that the running process has been started with LinuxThreads. As soon as this is detected, exp-drd stops and prints an error message. In case it would turn out that the above algorithm does not work, I will be happy to replace this algorithm by a test based on confstr(). Bart. |