You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
(58) |
Apr
(261) |
May
(169) |
Jun
(214) |
Jul
(201) |
Aug
(219) |
Sep
(198) |
Oct
(203) |
Nov
(241) |
Dec
(94) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(137) |
Feb
(149) |
Mar
(150) |
Apr
(193) |
May
(95) |
Jun
(173) |
Jul
(137) |
Aug
(236) |
Sep
(157) |
Oct
(150) |
Nov
(136) |
Dec
(90) |
| 2005 |
Jan
(139) |
Feb
(130) |
Mar
(274) |
Apr
(138) |
May
(184) |
Jun
(152) |
Jul
(261) |
Aug
(409) |
Sep
(239) |
Oct
(241) |
Nov
(260) |
Dec
(137) |
| 2006 |
Jan
(191) |
Feb
(142) |
Mar
(169) |
Apr
(75) |
May
(141) |
Jun
(169) |
Jul
(131) |
Aug
(141) |
Sep
(192) |
Oct
(176) |
Nov
(142) |
Dec
(95) |
| 2007 |
Jan
(98) |
Feb
(120) |
Mar
(93) |
Apr
(96) |
May
(95) |
Jun
(65) |
Jul
(62) |
Aug
(56) |
Sep
(53) |
Oct
(95) |
Nov
(106) |
Dec
(87) |
| 2008 |
Jan
(58) |
Feb
(149) |
Mar
(175) |
Apr
(110) |
May
(106) |
Jun
(72) |
Jul
(55) |
Aug
(89) |
Sep
(26) |
Oct
(96) |
Nov
(83) |
Dec
(93) |
| 2009 |
Jan
(97) |
Feb
(106) |
Mar
(74) |
Apr
(64) |
May
(115) |
Jun
(83) |
Jul
(137) |
Aug
(103) |
Sep
(56) |
Oct
(59) |
Nov
(61) |
Dec
(37) |
| 2010 |
Jan
(94) |
Feb
(71) |
Mar
(53) |
Apr
(105) |
May
(79) |
Jun
(111) |
Jul
(110) |
Aug
(81) |
Sep
(50) |
Oct
(82) |
Nov
(49) |
Dec
(21) |
| 2011 |
Jan
(87) |
Feb
(105) |
Mar
(108) |
Apr
(99) |
May
(91) |
Jun
(94) |
Jul
(114) |
Aug
(77) |
Sep
(58) |
Oct
(58) |
Nov
(131) |
Dec
(62) |
| 2012 |
Jan
(76) |
Feb
(93) |
Mar
(68) |
Apr
(95) |
May
(62) |
Jun
(109) |
Jul
(90) |
Aug
(87) |
Sep
(49) |
Oct
(54) |
Nov
(66) |
Dec
(84) |
| 2013 |
Jan
(67) |
Feb
(52) |
Mar
(93) |
Apr
(65) |
May
(33) |
Jun
(34) |
Jul
(52) |
Aug
(42) |
Sep
(52) |
Oct
(48) |
Nov
(66) |
Dec
(14) |
| 2014 |
Jan
(66) |
Feb
(51) |
Mar
(34) |
Apr
(47) |
May
(58) |
Jun
(27) |
Jul
(52) |
Aug
(41) |
Sep
(78) |
Oct
(30) |
Nov
(28) |
Dec
(26) |
| 2015 |
Jan
(41) |
Feb
(42) |
Mar
(20) |
Apr
(73) |
May
(31) |
Jun
(48) |
Jul
(23) |
Aug
(55) |
Sep
(36) |
Oct
(47) |
Nov
(48) |
Dec
(41) |
| 2016 |
Jan
(32) |
Feb
(34) |
Mar
(33) |
Apr
(22) |
May
(14) |
Jun
(31) |
Jul
(29) |
Aug
(41) |
Sep
(17) |
Oct
(27) |
Nov
(38) |
Dec
(28) |
| 2017 |
Jan
(28) |
Feb
(30) |
Mar
(16) |
Apr
(9) |
May
(27) |
Jun
(57) |
Jul
(28) |
Aug
(43) |
Sep
(31) |
Oct
(20) |
Nov
(24) |
Dec
(18) |
| 2018 |
Jan
(34) |
Feb
(50) |
Mar
(18) |
Apr
(26) |
May
(13) |
Jun
(31) |
Jul
(13) |
Aug
(11) |
Sep
(15) |
Oct
(12) |
Nov
(18) |
Dec
(13) |
| 2019 |
Jan
(12) |
Feb
(29) |
Mar
(51) |
Apr
(22) |
May
(13) |
Jun
(20) |
Jul
(13) |
Aug
(12) |
Sep
(21) |
Oct
(6) |
Nov
(9) |
Dec
(5) |
| 2020 |
Jan
(13) |
Feb
(5) |
Mar
(25) |
Apr
(4) |
May
(40) |
Jun
(27) |
Jul
(5) |
Aug
(17) |
Sep
(21) |
Oct
(1) |
Nov
(5) |
Dec
(15) |
| 2021 |
Jan
(28) |
Feb
(6) |
Mar
(11) |
Apr
(5) |
May
(7) |
Jun
(8) |
Jul
(5) |
Aug
(5) |
Sep
(11) |
Oct
(9) |
Nov
(10) |
Dec
(12) |
| 2022 |
Jan
(7) |
Feb
(13) |
Mar
(8) |
Apr
(7) |
May
(12) |
Jun
(27) |
Jul
(14) |
Aug
(27) |
Sep
(27) |
Oct
(17) |
Nov
(17) |
Dec
|
| 2023 |
Jan
(10) |
Feb
(18) |
Mar
(9) |
Apr
(26) |
May
|
Jun
(13) |
Jul
(18) |
Aug
(5) |
Sep
(6) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
1
(5) |
|
2
(2) |
3
(15) |
4
(3) |
5
|
6
(11) |
7
(4) |
8
|
|
9
(3) |
10
(6) |
11
(4) |
12
(5) |
13
(7) |
14
(37) |
15
(8) |
|
16
(1) |
17
(19) |
18
(20) |
19
(20) |
20
(15) |
21
(13) |
22
|
|
23
|
24
(20) |
25
(6) |
26
(2) |
27
(4) |
28
(6) |
29
|
|
30
(5) |
|
|
|
|
|
|
|
From: Dirk M. <dm...@gm...> - 2003-11-17 11:19:41
|
On Monday 17 November 2003 05:06, sandhya satyanarayan wrote: > After this i am not getting any output. Though the process is linking the > system library pthread statically. If the pthread library is indeed linked statically into your programm, then thats the problem. It has to be linked dynamically. |
|
From: Nicholas N. <nj...@ca...> - 2003-11-17 10:38:26
|
On Sat, 15 Nov 2003, Avery Pennarun wrote:
> On Fri, Nov 14, 2003 at 06:20:14PM +0100, Dimitri Papadopoulos-Orfanos wrote:
>
> > >>==14433== Warning: attempt to set SIGKILL handler in __NR_sigaction.
> > >>==14433== Warning: attempt to set SIGSTOP handler in __NR_sigaction.
> >
> > Maybe the wording can be improved, so that "normal" programers can
> > understand it. For example by changing from:
> > attempt to set SIGKILL handler in __NR_sigaction.
> > to:
> > attempt to set a handler for SIGKILL signal.
> >
> > Also maybe this can be added to the FAQ. If even 'ls' emits such
> > warnings, I guess many other programs will emit them too.
>
> How about: "warning: attempt to set SIGKILL handler never has an effect"?
I just committed a change so it prints this:
Warning: ignored attempt to set SIGKILL handler in sigaction();
the SIGKILL signal is uncatchable
> Also, for programs that set the sighandler in a loop - apparently include ls
> on some systems - I bet they're usually *disabling* a special handler, ie.
> 'sa' is NULL in the code fragment below. It would probably give fewer
> spurious warnings if we just didn't print a warning when sa==NULL.
No. Valgrind doesn't print the warning when sa==NULL.
N
|
|
From: Nicholas N. <nj...@ca...> - 2003-11-17 09:40:19
|
On Thu, 13 Nov 2003, David Judson wrote:
> I have a problem running a program under valgrind on RH9. The application
> is multi-threaded. When run under valgrind, one of the threads call munmap
> on the memory segment of a shared library. Subsequently, another thread
> needs a symbol in the library and tries to reload it. However the dlopen
> library becomes very confused, probably because it doesn't realize that the
> original copy of the library is unmapped. Things go rapdily downhill from
> there.
>
> This problem does not happen when using valgrind on RH 7.2
> When I run the program on RH9 using gdb, there is no call to munmap at this
> part of the program.
>
> To track this down, I would like to determine where the call to munmap is
> being made. How can I temporarily modify valgrind to produce a stack dump
> when munmap is called?
Try adding this:
VG_(pp_ExeContext)(
VG_(get_ExeContext)(
VG_(get_current_or_recent_tid)() ) );
VG_(message)(Vg_UserMsg, "");
to coregrind/vg_syscalls.c:munmap_segment().
N
|
|
From: sandhya s. <san...@ya...> - 2003-11-17 04:07:06
|
I am using valgrind-2.0.0 , i have worked with valgrind-1.0.3.But In both the versions i face the same problem . I am using the following command line arguments ./valgrind -v --leak-check=yes --show-reachable=yes --leak-resolution=high --workaround-gcc296-bugs=yes ./processName 2>ValgrindLog & The Output of valgrind -v looks like this ==26675== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux. ==26675== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward. ==26675== Using valgrind-2.0.0, a program supervision framework for x86-linux. ==26675== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward. ==26675== Command line: ==26675== ./processName ==26675== Startup, with flags: ==26675== --suppressions=/home/mms/valgrind-2.0.0/lib/valgrind/default.supp ==26675== -v ==26675== --leak-check=yes ==26675== --show-reachable=yes ==26675== --leak-resolution=high ==26675== --workaround-gcc296-bugs=yes ==26675== --gdb-attach=yes ==26675== Reading syms from /home/mms/valgrind-2.0.0/bin/processName ==26675== Reading syms from /lib/ld-2.2.4.so ==26675== Reading syms from /home/mms/valgrind-2.0.0/lib/valgrind/vgskin_memcheck.so ==26675== Reading syms from /home/mms/valgrind-2.0.0/lib/valgrind/valgrind.so ==26675== Reading syms from /lib/libssl.so.0.9.6b ==26675== object doesn't have any debug info ==26675== Reading syms from /home/mms/valgrind-2.0.0/lib/valgrind/libpthread.so ==26675== Reading syms from /lib/libresolv-2.2.4.so ==26675== Reading syms from /lib/libnsl-2.2.4.so ==26675== Reading syms from /usr/lib/libxml2.so.2.4.2 ==26675== object doesn't have any debug info ==26675== Reading syms from /usr/lib/libz.so.1.1.3 ==26675== object doesn't have any debug info ==26675== Reading syms from /lib/i686/libm-2.2.4.so ==26675== Reading syms from /lib/libcrypto.so.0.9.6b ==26675== object doesn't have any debug info ==26675== Reading syms from /usr/lib/libstdc++-3-libc6.2-2-2.10.0.so ==26675== Reading syms from /lib/i686/libc-2.2.4.so ==26675== Reading syms from /lib/libdl-2.2.4.so ==26675== Reading suppressions file: /home/mms/valgrind-2.0.0/lib/valgrind/default.supp ==26675== Estimated CPU clock rate is 869 MHz ==26675== ==26675== Syscall param open(pathname) contains uninitialised or unaddressable byte(s) ==26675== at 0x4056B474: __libc_open (in /lib/i686/libc-2.2.4.so) ==26675== by 0x4027C989: __open (vg_libpthread.c:2089) ==26675== by 0x40505FD7: _IO_file_fopen@@GLIBC_2.1 (fileops.c:220) ==26675== by 0x404FC5C2: _IO_fopen@@GLIBC_2.1 (iofopen.c:67) ==26675== Address 0x0 is not stack'd, malloc'd or free'd ==26675== ==26675== ---- Attach to GDB ? --- [Return/N/n/Y/y/C/c] ---- ==26675== Reading syms from /lib/libnss_files-2.2.4.so ==26675== ==26675== pthread_mutex_destroy: mutex is still in use ==26675== at 0x4027A163: pthread_error (vg_libpthread.c:286) ==26675== by 0x4027B0E3: __pthread_mutex_destroy (vg_libpthread.c:1015) ==26675== by 0x80B93AA: mutex_destroy(Mutex *) (thread.c:60) ==26675== by 0x80B057F: list_destroy(List *, void (*)(void *)) (list.c:96) ==26675== valgrind's libpthread.so: KLUDGED call to: pthread_cond_destroy ==26675== valgrind's libpthread.so: KLUDGED call to: pthread_cond_destroy ==26675== valgrind's libpthread.so: KLUDGED call to: pthread_cond_destroy After this i am not getting any output. Though the process is linking the system library pthread statically. But i have read in the valgrind documentation of 2.0.0 that it will automatically take its pthread library. And even with the above output one can make out that it is executing the valgrind pthread library code and not the system library code. Hope that this information is sufficient for you to throw some light. Thanks -sandhya Nicholas Nethercote <nj...@ca...> wrote: On Sat, 15 Nov 2003, sandhya satyanarayan wrote: > I am facing problem in detecting memory leaks using > valgrind for a multithreaded application.When i run > the multithreaded applcn with valgrind valgrind > doensnt detect any errors and neither does it shows > the leak > summary. The last line shown by valgrind is > "valgrind's libpthread.so: KLUDGED call to: > phread_cond_destroy" > What may be the problem What may be the problem, indeed? It's difficult to say, from the scant information you have presented. Perhaps if you could tell us some useful information, such as the version you are running, what command-line you are using, and what the output of "valgrind -v" looks like, we might be able to help you. N --------------------------------- Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard |
|
From: Jeremy F. <je...@go...> - 2003-11-17 01:19:19
|
On Fri, 2003-11-14 at 08:51, Tom Hughes wrote: > As valgrind has it's own libpthread we would have to work out how > setup the thread area for the new thread, which seems to be very > complicated as the GDT entry set in the kernel seems to point at a > thread descriptor structure which in turns points at the TLS data > and so on. OK, I looked at this in more detail. There are two parts of the puzzle: 1: There's the kernel mechanism for setting up a thread-local storage area, using the set_thread_area syscall. The argument to this is a segment descriptor, like the one used for set_ldt. This segment descriptor is assigned to one of the 3 TLS entries in the GDT. On thread context switch, the kernel reassigns the GDT entries to the thread's TLS segment. The thread itself assigns that descriptor to one of its segment registers, and uses %seg:0 as the pointer to its TLS area. This is easy for us to implement, since Julian has already done the hard work. We can store a per-thread "GDT" containing only these entries as part of each Thread structure. In VG_(do_useg)() we just look for the GDT (vs LDT) bit in the segment selector and do the appropriate thing. 2: All this is to support the new TLS extensions to the ABI. These are described in detail in http://people.redhat.com/drepper/tls.pdf. I've read this once, but I still don't understand the details. The essential point is that ELF files can now have a PT_TLS segment which is used as a prototype segment for thread-local variables. When a new thread is created, it effectively gets a new copy of the contents of the PT_TLS segment attached to its own thread area (pointed to via %gs). This is does lazily, so only the TLS segments which the thread actually uses are copied for it. This means that there's cooperation between the dynamic linker and libpthread. Since we control the one but not the other, we need to make our libpthread compatible with the dynamic linker's TLS implementation. The ABI documents some of this, but unfortunately it only documents the compiler interface to this goo, but not the internal interfaces between libpthread and the ld.so. The easy part of this is making sure that new threads get their own new TLS areas (which the glibc libpthread does by passing CLONE_SETTLS to clone(), which is the equivalent of doing set_thread_area() in the new thread). Trickier is getting the details of all the other structures right. And since they're internal to glibc, there's no certainty they won't change from release to release... BTW, this is completely independent of NPTL. The TLS stuff is an extension to the ABI which is also supported by the pre-NPTL threads library (though I'm not sure how they make do without the set_thread_area syscall). BTW(2): Nvidia will use set_thread_area and this tls mechanism when available. Otherwise they implement it themselves using a similar segment trick. In summary, I'm not sure what to do about this. J |
|
From: Daniel B. <bar...@ia...> - 2003-11-16 21:50:40
|
I just built valgrind 2.0.0 on my glibc 2.2.1 system, and got a couple of errors compiling vg_intercept.c, when the compiler didn't find a definition of struct timeval. I did the obvious thing and commented out the #ifdef around the include for sys/time.h, and everything seems to work. So my guess is that the #ifdef is just insufficiently inclusive. -Daniel *This .sig left intentionally blank* |
|
From: Dima B. <di...@cs...> - 2003-11-15 23:26:36
|
Hi,
Has anybody had trouble using valgrind with the BerkeleyDB.
This is a stock RedHat 9.0 box, nptl, and the application
is multi-threaded using pthreads.
The following code craps out, the open fails:
DB_ENV *dbe;
long res;
res = db_env_create( &(pi->dbe), 0 );
assert( !res );
res = dbe->open( dbe, "foobar", DB_CREATE | DB_INIT_MPOOL | DB_INIT_LOCK |
DB_INIT_LOG | DB_INIT_TXN | DB_RECOVER, S_IRUSR | S_IWUSR );
if ( res ) {
dbe->err( pi->dbe, res, "env_open" );
dbe->close( pi->dbe, 0 );
assert( 0 );
}
the open fails with the following error:
env_open: Function not implemented
This code runs fine without valgrind, and with valgrind on a non
nptl 2.4 kernel.
Thanks
ttyl
Dima
--
Dima Brodsky di...@cs...
http://www.cs.ubc.ca/~dima
201-2366 Main Mall
Department of Computer Science (604) 822-2895 (DSG Lab)
University of British Columbia, Canada (604) 822-5485 (FAX)
"The price of reliability is the pursuit of the utmost simplicity.
It is a price which the very rich find the most hard to pay."
(Sir Antony Hoare, 1980)
|
|
From: Sean O. <ow...@hy...> - 2003-11-15 23:12:49
|
sandhya satyanarayan writes: > I am facing problem in detecting memory leaks using > valgrind for a multithreaded application.When i run > the multithreaded applcn with valgrind valgrind > doensnt detect any errors and neither does it shows > the leak > summary. The last line shown by valgrind is > "valgrind's libpthread.so: KLUDGED call to: > phread_cond_destroy" > What may be the problem > -Sandhya Just a check - make sure that your program isn't statically linking the system pthreads library. This is something that bit me hard when I first tried to use valgrind. I was statically linking pthreads and valgrind was giving me nothing in the way of output. Sean -- Sean R. Owens ow...@cs... 412-268-3194 (office number) 1604c Newell Simon Hall | "The Soldier's Medal is awarded to Mr. Hugh C. Thompson, Jr. for | heroism above and beyond the call of duty on 16 March, 1968 ... at | My Lai, Quang Ngai Province, South Vietnam. ... landed his | helicopter in the line of fire between fleeing Vietnamese civilians | and pursuing American ground troops to prevent their murder. ... | exemplifies the highest standards of personal courage and ethical | conduct ..." - Signed, Togo D. West, Jr., Secretary of the Army. | http://www.acadianhouse.com/hughthompson/story.htm |
|
From: Avery P. <ape...@ni...> - 2003-11-15 17:57:52
|
On Fri, Nov 14, 2003 at 06:20:14PM +0100, Dimitri Papadopoulos-Orfanos wrote: > >>==14433== Warning: attempt to set SIGKILL handler in __NR_sigaction. > >>==14433== Warning: attempt to set SIGSTOP handler in __NR_sigaction. > > >They're almost not worth warning about. SIGKILL and SIGSTOP cannot be > >caught or handled in any way, so trying to set them to anything other > >than SIG_DFL with sigaction is an error - but a very minor one with no > >side-effects. This warning is common with code which does something > >like: > > > > for(sig = 1; sig < NSIG; sig++) > > sigaction(sig, &sa, NULL); > > Maybe the wording can be improved, so that "normal" programers can > understand it. For example by changing from: > attempt to set SIGKILL handler in __NR_sigaction. > to: > attempt to set a handler for SIGKILL signal. > > Also maybe this can be added to the FAQ. If even 'ls' emits such > warnings, I guess many other programs will emit them too. How about: "warning: attempt to set SIGKILL handler never has an effect"? Also, for programs that set the sighandler in a loop - apparently include ls on some systems - I bet they're usually *disabling* a special handler, ie. 'sa' is NULL in the code fragment below. It would probably give fewer spurious warnings if we just didn't print a warning when sa==NULL. Have fun, Avery |
|
From: Andriy R. <ar...@bc...> - 2003-11-15 17:31:12
|
Works fine with the pach, thanks. Andriy Nicholas Nethercote wrote: >On Fri, 14 Nov 2003, Andriy Rysin wrote: > > > >>Can anybody confirm this? It seems like valgrind does not handle >>posix_memalign, I saw __posix_memalign in the code but apparently it >>does not help. >> >> > >Can you add these lines: > > # define weak_alias(name, aliasname) \ > extern __typeof (name) aliasname __attribute__ ((weak, alias (#name))); > weak_alias(__posix_memalign, posix_memalign); > >just after __posix_memalign() (line 375) in coregrind/vg_replace_malloc.c? > >If it works, I'll commit it. > >Thanks. > >N > > |
|
From: Nicholas N. <nj...@ca...> - 2003-11-15 12:59:13
|
On Sat, 15 Nov 2003, sandhya satyanarayan wrote: > I am facing problem in detecting memory leaks using > valgrind for a multithreaded application.When i run > the multithreaded applcn with valgrind valgrind > doensnt detect any errors and neither does it shows > the leak > summary. The last line shown by valgrind is > "valgrind's libpthread.so: KLUDGED call to: > phread_cond_destroy" > What may be the problem What may be the problem, indeed? It's difficult to say, from the scant information you have presented. Perhaps if you could tell us some useful information, such as the version you are running, what command-line you are using, and what the output of "valgrind -v" looks like, we might be able to help you. N |
|
From: sandhya s. <san...@ya...> - 2003-11-15 11:04:42
|
I am facing problem in detecting memory leaks using valgrind for a multithreaded application.When i run the multithreaded applcn with valgrind valgrind doensnt detect any errors and neither does it shows the leak summary. The last line shown by valgrind is "valgrind's libpthread.so: KLUDGED call to: phread_cond_destroy" What may be the problem -Sandhya __________________________________ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree |
|
From: Nicholas N. <nj...@ca...> - 2003-11-15 10:49:34
|
On Fri, 14 Nov 2003, Andriy Rysin wrote:
> Can anybody confirm this? It seems like valgrind does not handle
> posix_memalign, I saw __posix_memalign in the code but apparently it
> does not help.
Can you add these lines:
# define weak_alias(name, aliasname) \
extern __typeof (name) aliasname __attribute__ ((weak, alias (#name)));
weak_alias(__posix_memalign, posix_memalign);
just after __posix_memalign() (line 375) in coregrind/vg_replace_malloc.c?
If it works, I'll commit it.
Thanks.
N
|
|
From: Andriy R. <ar...@bc...> - 2003-11-15 01:42:48
|
Can anybody confirm this? It seems like valgrind does not handle
posix_memalign, I saw __posix_memalign in the code but apparently it
does not help.
valgrind (up to 2.0.0) on program:
#include <stdlib.h>
int main()
{
int *ptr;
posix_memalign(&ptr, 16, 4096);
ptr[16] = 5;
printf("%d\n", ptr[16]);
free(ptr);
}
gives this:
...
==12016== Invalid free() / delete / delete[]
==12016== at 0x40026961: free (vg_replace_malloc.c:231)
==12016== by 0x8048404: main (posix_mem.c:9)
==12016== by 0x420158F6: __libc_start_main (in /lib/i686/libc-2.3.2.so)
==12016== by 0x8048320: (within /root/work/tmp/posix_mem)
==12016== Address 0x905B020 is not stack'd, malloc'd or free'd
...
Thanks,
Andriy
P.S. in man pages memalign and valloc marked as deprecated in favor of
posix_memalign so it's a pity if valgrind does not support it
|
|
From: Julian S. <js...@ac...> - 2003-11-14 19:19:27
|
See Q1/A1 in FAQ.txt. J On Friday 14 November 2003 11:39, Test Valgrind wrote: > Hi All, > > I downloaded the valgrind sources (both Valgrind version 20031012 and > valgrind-2.0) from http://valgrind.kde.org. > > As per the README, used the following commands > > /configure --prefix /usr/local/bin > make > make install > > I guess both the times the valgrind was compiled and installed > correctly. I also tried once with ./configure only (i.e. without giving > prefix option). Also tried using the setting up specific paths. But > still all the time I am getting the segmentation fault whenever I run > "./valgrind ls -al". > > Can anybody tell me what could be the problem? Any information/steps > about this issues is welcome! > > Best regards > > AMOLAK |
|
From: Dimitri Papadopoulos-O. <pap...@sh...> - 2003-11-14 18:06:06
|
Hi, Please find attached a patch against valgrind-2.0.0 adding support for pkgconfig. It adds a lib/pkgconfig/valgrind.pc file. -- Dimitri |
|
From: Nicholas N. <nj...@ca...> - 2003-11-14 17:39:21
|
On Fri, 14 Nov 2003, Amol Kulkarni wrote: > Hi Attched is the output of ./valgrind -v ls -al > > ==5684== Invalid read of size 4 > ==5684== at 0x40262C83: _nl_unload_locale (loadlocale.c:237) > ==5684== by 0x4026279C: free_mem (findlocale.c:257) > ==5684== by 0x402C1961: __libc_freeres (set-freeres.c:34) > ==5684== by 0x40186E43: vgPlain___libc_freeres_wrapper > (vg_intercept.c:873) Two suggestions that might help: 1. As Jeremy said, try not ./valgrind but /usr/local/bin/valgrind. 2. Try --run-libc-freeres=no, as per FAQ #1. You said you're running RH 7.1, so your glibc is probably old enough to still suffer that problem. HTH N |
|
From: Amol K. <am...@in...> - 2003-11-14 17:33:44
|
Hi Attched is the output of ./valgrind -v ls -al [test@mmsc bin]$ ./valgrind -v ls -al ==5684== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux. ==5684== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward. ==5684== Using valgrind-2.0.0, a program supervision framework for x86-linux. ==5684== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward. ==5684== Command line: ==5684== ls ==5684== -al ==5684== Startup, with flags: ==5684== --suppressions=/usr/local/bin/valgrind-2.0.0//lib/valgrind/d efault.s upp ==5684== -v ==5684== Reading syms from /bin/ls ==5684== object doesn't have a symbol table ==5684== object doesn't have any debug info ==5684== Reading syms from /lib/ld-2.2.2.so ==5684== Reading syms from /usr/local/bin/valgrind-2.0.0/lib/valgrind/vgskin_mem check.so ==5684== Reading syms from /usr/local/bin/valgrind-2.0.0/lib/valgrind/valgrind.s o ==5684== Reading syms from /lib/libtermcap.so.2.0.8 ==5684== object doesn't have a symbol table ==5684== object doesn't have any debug info ==5684== Reading syms from /lib/i686/libc-2.2.2.so ==5684== Reading suppressions file: /usr/local/bin/valgrind-2.0.0//lib/valgrind/ default.supp ==5684== Estimated CPU clock rate is 751 MHz ==5684== ==5684== Reading syms from /lib/libnss_files-2.2.2.so total 1336 drwxrwxr-x 2 root root 4096 Nov 14 18:35 . drwxrwxr-x 17 root root 4096 Nov 14 13:12 .. -rwxrwxrwx 1 root root 31885 Nov 14 12:13 cg_annotate -rw------- 1 root root 2637824 Nov 14 18:34 core -rwxrwxrwx 1 root root 0 Nov 14 18:37 test.log -rwxrwxrwx 1 root root 5610 Nov 14 12:13 valgrind -rwxrwxrwx 1 root root 61561 Nov 14 12:13 valgrind-listener ==5684== Invalid read of size 4 ==5684== at 0x40262C83: _nl_unload_locale (loadlocale.c:237) ==5684== by 0x4026279C: free_mem (findlocale.c:257) ==5684== by 0x402C1961: __libc_freeres (set-freeres.c:34) ==5684== by 0x40186E43: vgPlain___libc_freeres_wrapper (vg_intercept.c:873) ==5684== Address 0x40C95050 is 12 bytes inside a block of size 380 free'd ==5684== at 0x4002BEA7: free (vg_replace_malloc.c:231) ==5684== by 0x40262CB9: _nl_unload_locale (loadlocale.c:245) ==5684== by 0x40262217: free_mem (setlocale.c:460) ==5684== by 0x402C1961: __libc_freeres (set-freeres.c:34) ==5684== ==5684== Invalid read of size 4 ==5684== at 0x40262C8A: _nl_unload_locale (loadlocale.c:238) ==5684== by 0x4026279C: free_mem (findlocale.c:257) ==5684== by 0x402C1961: __libc_freeres (set-freeres.c:34) ==5684== by 0x40186E43: vgPlain___libc_freeres_wrapper (vg_intercept.c:873) ==5684== Address 0x40C9504C is 8 bytes inside a block of size 380 free'd ==5684== at 0x4002BEA7: free (vg_replace_malloc.c:231) ==5684== by 0x40262CB9: _nl_unload_locale (loadlocale.c:245) ==5684== by 0x40262217: free_mem (setlocale.c:460) ==5684== by 0x402C1961: __libc_freeres (set-freeres.c:34) ==5684== ==5684== Invalid read of size 4 ==5684== at 0x40262C91: _nl_unload_locale (loadlocale.c:238) ==5684== by 0x4026279C: free_mem (findlocale.c:257) ==5684== by 0x402C1961: __libc_freeres (set-freeres.c:34) ==5684== by 0x40186E43: vgPlain___libc_freeres_wrapper (vg_intercept.c:873) ==5684== Address 0x40C95048 is 4 bytes inside a block of size 380 free'd ==5684== at 0x4002BEA7: free (vg_replace_malloc.c:231) ==5684== by 0x40262CB9: _nl_unload_locale (loadlocale.c:245) ==5684== by 0x40262217: free_mem (setlocale.c:460) ==5684== by 0x402C1961: __libc_freeres (set-freeres.c:34) [amol@mmsc bin]$ ./valgrind -v ls -al ==5691== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux. ==5691== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward. ==5691== Using valgrind-2.0.0, a program supervision framework for x86-linux. ==5691== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward. ==5691== Command line: ==5691== ls ==5691== -al ==5691== Startup, with flags: ==5691== --suppressions=/usr/local/bin/valgrind-2.0.0//lib/valgrind/d efault.s upp ==5691== -v ==5691== Reading syms from /bin/ls ==5691== object doesn't have a symbol table ==5691== object doesn't have any debug info ==5691== Reading syms from /lib/ld-2.2.2.so ==5691== Reading syms from /usr/local/bin/valgrind-2.0.0/lib/valgrind/vgskin_mem check.so ==5691== Reading syms from /usr/local/bin/valgrind-2.0.0/lib/valgrind/valgrind.s o ==5691== Reading syms from /lib/libtermcap.so.2.0.8 ==5691== object doesn't have a symbol table ==5691== object doesn't have any debug info ==5691== Reading syms from /lib/i686/libc-2.2.2.so ==5691== Reading suppressions file: /usr/local/bin/valgrind-2.0.0//lib/valgrind/ default.supp ==5691== Estimated CPU clock rate is 752 MHz ==5691== total 1336 ==5691== Reading syms from /lib/libnss_files-2.2.2.so drwxrwxr-x 2 root root 4096 Nov 14 18:35 . drwxrwxr-x 17 root root 4096 Nov 14 13:12 .. -rwxrwxrwx 1 root root 31885 Nov 14 12:13 cg_annotate -rw------- 1 root root 2637824 Nov 14 18:34 core -rwxrwxrwx 1 root root 0 Nov 14 18:37 test.log -rwxrwxrwx 1 root root 5610 Nov 14 12:13 valgrind -rwxrwxrwx 1 root root 61561 Nov 14 12:13 valgrind-listener ==5691== Invalid read of size 4 ==5691== at 0x40262C83: _nl_unload_locale (loadlocale.c:237) ==5691== by 0x4026279C: free_mem (findlocale.c:257) ==5691== by 0x402C1961: __libc_freeres (set-freeres.c:34) ==5691== by 0x40186E43: vgPlain___libc_freeres_wrapper (vg_intercept.c:873) ==5691== Address 0x40C95050 is 12 bytes inside a block of size 380 free'd ==5691== at 0x4002BEA7: free (vg_replace_malloc.c:231) ==5691== by 0x40262CB9: _nl_unload_locale (loadlocale.c:245) ==5691== by 0x40262217: free_mem (setlocale.c:460) ==5691== by 0x402C1961: __libc_freeres (set-freeres.c:34) ==5691== ==5691== Invalid read of size 4 ==5691== at 0x40262C8A: _nl_unload_locale (loadlocale.c:238) ==5691== by 0x4026279C: free_mem (findlocale.c:257) ==5691== by 0x402C1961: __libc_freeres (set-freeres.c:34) ==5691== by 0x40186E43: vgPlain___libc_freeres_wrapper (vg_intercept.c:873) ==5691== Address 0x40C9504C is 8 bytes inside a block of size 380 free'd ==5691== at 0x4002BEA7: free (vg_replace_malloc.c:231) ==5691== by 0x40262CB9: _nl_unload_locale (loadlocale.c:245) ==5691== by 0x40262217: free_mem (setlocale.c:460) ==5691== by 0x402C1961: __libc_freeres (set-freeres.c:34) ==5691== ==5691== Invalid read of size 4 ==5691== at 0x40262C91: _nl_unload_locale (loadlocale.c:238) ==5691== by 0x4026279C: free_mem (findlocale.c:257) ==5691== by 0x402C1961: __libc_freeres (set-freeres.c:34) ==5691== by 0x40186E43: vgPlain___libc_freeres_wrapper (vg_intercept.c:873) ==5691== Address 0x40C95048 is 4 bytes inside a block of size 380 free'd ==5691== at 0x4002BEA7: free (vg_replace_malloc.c:231) ==5691== by 0x40262CB9: _nl_unload_locale (loadlocale.c:245) ==5691== by 0x40262217: free_mem (setlocale.c:460) ==5691== by 0x402C1961: __libc_freeres (set-freeres.c:34) Segmentation fault [amol@mmsc bin]$ -----Original Message----- From: Nicholas Nethercote [mailto:nj...@he...]On Behalf Of Nicholas Nethercote Sent: Friday, November 14, 2003 4:51 PM To: Test Valgrind Cc: Valgrind Users Subject: Re: running valgrind on Red Hat Linux release 7.1 (Seawolf) Kernel 2.4.2-2 On Fri, 14 Nov 2003, Test Valgrind wrote: > I downloaded the valgrind sources (both Valgrind version 20031012 and > valgrind-2.0) from http://valgrind.kde.org. > > As per the README, used the following commands > > ./configure --prefix /usr/local/bin > make > make install > > I guess both the times the valgrind was compiled and installed > correctly. I also tried once with ./configure only (i.e. without giving > prefix option). Also tried using the setting up specific paths. But > still all the time I am getting the segmentation fault whenever I run > "./valgrind ls -al". Can you send the entire output of "./valgrind -v ls -al"? Thanks. N |
|
From: Dan K. <da...@ke...> - 2003-11-14 17:25:21
|
Tom Hughes wrote: >>On Friday 14 November 2003 14:41, Dimitri Papadopoulos-Orfanos wrote: >> >>>I'm trying to run valgrind-2.0.0 on a program that makes use of OpenGL >>>on Red Hat Linux 9. This is a dual-processor Dell with NVidia card and >>>latest drivers 1.0-4496. Valgrind dies. Any clue? >> > ... Somebody else saw this with the > NVidia OpenGL drivers a while ago - it seems that they only supply > an NPTL version and don't mark the library in the right way for the > fallback to work when LD_ASSUME_KERNEL is set anyway. Aha. That's good to know. Anyone know if NVidia has been informed of this? - Dan |
|
From: Dimitri Papadopoulos-O. <pap...@sh...> - 2003-11-14 17:25:03
|
Hi, >>Can we expect an NPTL version of Valgrind in 2004? > > > I posted a message a while back explaining that I'm not convinced it > is possible with the current threading model - I have tried. I have Insure++ here, which provides Chaperon, an equivalent to Valgrind. It has been ported to Red Hat 9, and works with both NPTL and NVidia drivers. Maybe it's possible to get Valgrind to work on Red Hat after all? I'm not saying it's easy or that it won't be ugly, but maybe it's technicaly feasible. -- Dimitri |
|
From: Dan K. <da...@ke...> - 2003-11-14 17:21:58
|
Dirk Mueller wrote: > So you say that > > a) the version of NPTL in Redhat 9 is still current with the development tree > b) the version of NPTL in Redhat 9 is fully binary and behaviour compatible > with the stuff that went into kernel 2.6 > c) the version of NPTL in Redhat 9 is without bugs > > ? > > Lets just say that this was an extremely biased answer. > > About the "no idea why": I don't think this belongs on a public mailing list, > but since you started dragging it into it, I've to give it an answer: I find > it unacceptable to do such a massive ABI change in a "vendor" kernel that is > labeled as "linux 2.4". Its not anything near linux 2.4 what you ship. > Instead you expect that every 3rd party developer will be happy and full of > joy that you again managed to release a distro that is in core parts > completely incompatible to any (!) other distro out there. That alone > wouldn't be too bad (you could claim that you're technically ahead of other > distributions), but the fact is that its not even compatible to what went > into vanilla kernel makes it a bad decision. ? The compatibility doesn't seem to bad to me. *Someone* had to take the hit and be the first to switch to NPTL etc., and I'm really glad Red Hat did it. Yes, there was some disruption, but it was minimal and responsibly handled, and worth it. > But after redhat-gcc and > redhat-glibc it was just a matter of time until there would be a > redhat-kernel. Aha, you're still pissed about gcc-2.96-rh, aren't you? My personal advice is: let it go. Red Hat had to ship that; they supported it well; and they moved to a standard gcc when that was ready. I fully support what Red Hat did (except perhaps for naming). Apologies for replying to an off-topic thread... - Dan |
|
From: Dimitri Papadopoulos-O. <pap...@sh...> - 2003-11-14 17:18:02
|
Hi, >>==14433== Warning: attempt to set SIGKILL handler in __NR_sigaction. >>==14433== Warning: attempt to set SIGSTOP handler in __NR_sigaction. >>[...] >> >>What do they mean exactly? >>Should these warnings be ignored? >>Should the program be fixed? > > > They're almost not worth warning about. SIGKILL and SIGSTOP cannot be > caught or handled in any way, so trying to set them to anything other > than SIG_DFL with sigaction is an error - but a very minor one with no > side-effects. This warning is common with code which does something > like: > > for(sig = 1; sig < NSIG; sig++) > sigaction(sig, &sa, NULL); > > So ignore it unless you're being pedantic. I understand now. Thanks for explaining this. Maybe the wording can be improved, so that "normal" programers can understand it. For example by changing from: attempt to set SIGKILL handler in __NR_sigaction. to: attempt to set a handler for SIGKILL signal. Also maybe this can be added to the FAQ. If even 'ls' emits such warnings, I guess many other programs will emit them too. -- Dimitri |
|
From: Bill R. Jr. <bru...@te...> - 2003-11-14 17:15:03
|
On Fri, Nov 14, 2003 at 08:43:14AM -0800, Jeremy Fitzhardinge wrote:
> $ cd /usr/lib/tls
> $ mkdir hide
> $ mv ligGL* hide
>
> This works for me - but you need to make sure you always use
> LD_ASSUME_KERNEL=2.4.1 when you run your code without Valgrind.
You can avoid this by running valgrind in a private namespace,
and using bind-mounts to cover/hide the libraries.
There is as yet no standard exec-chaining utility (ala time(1),
nice(1), etc.) for creating a private namespace, but it is rather
trivial:
#include <syscall.h>
static inline _syscall2(int, clone, int, flags, int, foo)
#define CLONE_NEWNS 0x00020000 /* New namespace */
...
int pid = clone(CLONE_NEWNS | SIGCHLD,0);
if (pid == 0)
...
In your new namespace, just do
sudo mount -n --bind ...
to avoid mucking with /etc/mtab.
Regards,
Bill Rugolsky
|
|
From: Jeremy F. <je...@go...> - 2003-11-14 17:04:08
|
On Fri, 2003-11-14 at 08:51, Tom Hughes wrote: > As valgrind has it's own libpthread we would have to work out how > setup the thread area for the new thread, which seems to be very > complicated as the GDT entry set in the kernel seems to point at a > thread descriptor structure which in turns points at the TLS data > and so on. Urk. I've never really looked at x86 segmentation, let alone how TLS uses it. I'm working on changes to let us get control before ld-linux.so starts. Would that help here? Actually, definitely, yes, because we can always set things up to tell the app that there's no TLS here, nope, go about your business. Another thought: with the new syscalls stuff, every app has its own cloned thread. Could we use those to hang kernel TLS state off in some way? > The other bits of NPTL shouldn't be a problem should they? It just > means implementing things like the futex system call. Well, more to the point, the other bits of NPTL don't have any app-visible API or ABI changes, so we can handle them in our libpthread. We don't need to emulate futex or clone unless someone wants to use them directly. J |
|
From: Jeremy F. <je...@go...> - 2003-11-14 16:58:34
|
On Fri, 2003-11-14 at 03:39, Test Valgrind wrote: > I guess both the times the valgrind was compiled and installed > correctly. I also tried once with ./configure only (i.e. without giving > prefix option). Also tried using the setting up specific paths. But > still all the time I am getting the segmentation fault whenever I run > "./valgrind ls -al". Why "./valgrind"? If you're doing this in your build tree this won't run your freshly build version, but the one in <prefix>/lib/valgrind. You need to use "./valgrind --in-place=.." to make sure you get all-new bits running together. J |