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: Nicholas N. <nj...@ca...> - 2003-11-09 17:11:11
|
On Sun, 2 Nov 2003, Avery Pennarun wrote:
> Since I have total control over the setjmp/longjmp calls, would it be
> possible to add a feature to valgrind like
>
> if (!setjmp)
> VALGRIND_STOP_INVALIDATING
> longjmp(elsewhere)
> // else someone longjmped back to me
> VALGRIND_START_INVALIDATING
> printf("x is now %d\n", x);
>
> It would then need to be sure to invalidate only the areas between the old
> and new stack pointer whenever %sp is changed (the normal way) rather than
> blindly invalidating "everything under the current stack pointer."
>
> This is pretty low priority, however.
Indeed. I don't think this feature is likely to be added, since it would
only ever be used in extremely obscure circumstances, which is exactly the
kind of feature we don't like adding. Sorry about that.
(I still don't quite understand why you need to use this unusual
setjmp/longjmp thing instead of switching stack in a more normal way,
although I'm sure you have a good reason.)
N
|
|
From: Jeremy F. <je...@go...> - 2003-11-07 17:18:15
|
On Thu, 2003-11-06 at 08:08, Dhirendra Pal Singh wrote: > Hi All, > I am new to this valgrind. I am trying to valgrind my code. Its a pretty > decent size code with lot of multithreading. Now when I start valgrind > using the following command... > > valgrind --num-callers=20 --alignment=8 --leak-check=yes > --leak-resolution=med --error-limit=no --show-reachable=yes > /usr/sbin/myprog > > It shows me some error messages in the beginig, and then goes to sleep. > By sleep I mean that the process dosent dies but dosent do anything > either... It shows 0.0 percent cpu usage, and does not respond to key > stroke. > [...] > Now I tried to attach gdb/totalview to it this myprog while valgrinding. > And it shows the myprog is stuck at line 2154 of vg_scheduler.c .. > the code is as follows... It's probably blocked in a syscall. What does strace -p <pid> show? Attaching with gdb/totalview is more likely to be confusing than useful, since your program isn't even really running when it's under Valgrind. BTW, the message it prints is probably a real bug, so you should look at fixing that first. J |
|
From: Dhirendra P. S. <dp...@ka...> - 2003-11-07 16:44:50
|
I dont think thats the case because my program does not dies with a segmentation fault....? the process still keeps running as i can see it using ps -eaf. Any body with any other idea ? Dimitri Papadopoulos-Orfanos wrote: > Hi, > >> I am new to this valgrind. I am trying to valgrind my code. Its a >> pretty decent size code with lot of multithreading. Now when I start >> valgrind using the following command... > > > Did you have a look at Q10 of the FAQ? > http://developer.kde.org/~sewardj/docs-20031012/FAQ.txt > > Maybe it applies to you, depending on the version of valgrind and your > operating system. > > -- > Dimitri |
|
From: Brian A. <ba...@we...> - 2003-11-07 13:36:14
|
I have an apache 2 module which I suspect is leaking memory, but valgrind never reports it. To test this I included "valgrind/memcheck.h" and call VALGRIND_DO_LEAK_CHECK for every request in this module. Valgrind does a memory leak test, but doesn't seem to catch anything in this modules. Example: char *p; p = malloc(128); p = NULL; This never gets caught. Any suggestions. This is apache 2.0.48, threaded, Debian unstable, valgrind 20031012 Thanks -- Brian Akins <ba...@we...> CNN Internet Technologies |
|
From: Dimitri Papadopoulos-O. <pap...@sh...> - 2003-11-07 07:04:38
|
Hi, > I am new to this valgrind. I am trying to valgrind my code. Its a pretty > decent size code with lot of multithreading. Now when I start valgrind > using the following command... Did you have a look at Q10 of the FAQ? http://developer.kde.org/~sewardj/docs-20031012/FAQ.txt Maybe it applies to you, depending on the version of valgrind and your operating system. -- Dimitri |
|
From: Daniel G. <dan...@no...> - 2003-11-06 22:38:22
|
Processor is an STPC Atlas. /proc/cpuinfo reports the model name as Cx486DX2. The cpu does not seem to have the cpuid instruction. 'valgrind --help' now succeeds. Trying to debug a program crashes with 'Illegal Instruction' again, but grepping through the code I note the cpuid is in at least one other place too... I will apply a similar fix. Thank you for your help! Dan. -----Original Message----- From: Jeremy Fitzhardinge [mailto:je...@go...] Sent: Thursday, November 06, 2003 4:03 PM To: Daniel Goertzen Cc: val...@li... Subject: Re: [Valgrind-users] vg crashes with "Illegal Instruction" On Thu, 2003-11-06 at 13:28, Daniel Goertzen wrote: > Some unusual things about my system: > - I am using a cross compile toolchain > - Build system is an old RedHat system, athlon, gcc-2.96, libc-2.2.5. linux > 2.4.20 > - Host(target) system is 486, gcc-3.3.2, libc-2.3.2, linux 2.4.22 > - Environmental variables CC, RANLIB, AR etc are set to cross compile > equivalents. Watching the VG build I note that these tools are being used > properly (with the exception of AR, which I fixed) > - My target system is an embedded PC104 module on which I would like to do > some debugging. > - 100% of the software on the embedded system, including the linux kernel, > is compiled with the cross tool chain and everything works great except for > vg. Do you know if your CPU supports the CPUID instruction? What is the exact CPU model (manufacturer, etc). What does /proc/cpuinfo say? What happens if you make a change something like this: *** vg_startup.S 17 Oct 2003 13:24:40 -0000 1.18 --- vg_startup.S 6 Nov 2003 22:01:54 -0000 *************** really_start_up: *** 112,117 **** --- 112,118 ---- # cpu or not. movb $0, VG_(have_ssestate) # assume sse-disabled movl $0, %eax + jmp get_fpu cpuid cmpl $1, %eax jl get_fpu # we cant do cpuid(1) ?! J |
|
From: Jeremy F. <je...@go...> - 2003-11-06 22:02:43
|
On Thu, 2003-11-06 at 13:28, Daniel Goertzen wrote: > Some unusual things about my system: > - I am using a cross compile toolchain > - Build system is an old RedHat system, athlon, gcc-2.96, libc-2.2.5. linux > 2.4.20 > - Host(target) system is 486, gcc-3.3.2, libc-2.3.2, linux 2.4.22 > - Environmental variables CC, RANLIB, AR etc are set to cross compile > equivalents. Watching the VG build I note that these tools are being used > properly (with the exception of AR, which I fixed) > - My target system is an embedded PC104 module on which I would like to do > some debugging. > - 100% of the software on the embedded system, including the linux kernel, > is compiled with the cross tool chain and everything works great except for > vg. Do you know if your CPU supports the CPUID instruction? What is the exact CPU model (manufacturer, etc). What does /proc/cpuinfo say? What happens if you make a change something like this: *** vg_startup.S 17 Oct 2003 13:24:40 -0000 1.18 --- vg_startup.S 6 Nov 2003 22:01:54 -0000 *************** really_start_up: *** 112,117 **** --- 112,118 ---- # cpu or not. movb $0, VG_(have_ssestate) # assume sse-disabled movl $0, %eax + jmp get_fpu cpuid cmpl $1, %eax jl get_fpu # we cant do cpuid(1) ?! J |
|
From: Jeremy F. <je...@go...> - 2003-11-06 21:47:19
|
On Thu, 2003-11-06 at 11:08, David Faure wrote:
> I'm running a multithreaded program through valgrind.
>
> In some earlier versions of valgrind (1.9.5 maybe?), threads used to get their
> own ID, as seen in pthread_self(), starting at 1 (IIRC 0 was the main thread).
>
> With valgrind_2_0_really or valgrind CVS HEAD (KDE CVS), the thread
> gets an ID of 0, like the main thread, which makes the debugging a little more difficult.
I don't see this. I get the same results with current CVS and the
2.0_REALLY branch, which are both expected:
$ valgrind -q ./tt
tid=1
tid=2
tid=3
tid=4
tid=5
tid=6
tid=7
$ cat tt.c
#include <stdio.h>
#include <pthread.h>
static void *th(void *a)
{
printf("tid=%d\n", pthread_self());
}
int main()
{
pthread_t t[10];
pthread_t *pt = t;
th(NULL);
pthread_create(pt++, NULL, th, NULL);
pthread_create(pt++, NULL, th, NULL);
pthread_create(pt++, NULL, th, NULL);
pthread_create(pt++, NULL, th, NULL);
pthread_create(pt++, NULL, th, NULL);
pthread_create(pt++, NULL, th, NULL);
while(pt > t)
pthread_join(*--pt, NULL);
return 0;
}
BTW, running this natively gets tid's which are far from small integers:
$ ./tt
tid=1073894560
tid=1082293552
tid=1090686256
tid=1099078960
tid=1116949808
tid=1125342512
tid=1133735216
So long as the thread IDs are all distinct, you can't really rely on any
particular values...
J
|
|
From: Daniel G. <dan...@no...> - 2003-11-06 21:28:18
|
When I run any valgrind command, including 'valgrind --help', I get this error: 'Illegal Instruction' I turned on loader debugging with 'LD_DEBUG=files; export LD_DEBUG', and the last thing it was trying to do before dying was 'calling init: //lib/valgrind/valgrind.so' Any idea what is going on here? I've been pulling my hair out all day on this. Some unusual things about my system: - I am using a cross compile toolchain - Build system is an old RedHat system, athlon, gcc-2.96, libc-2.2.5. linux 2.4.20 - Host(target) system is 486, gcc-3.3.2, libc-2.3.2, linux 2.4.22 - Environmental variables CC, RANLIB, AR etc are set to cross compile equivalents. Watching the VG build I note that these tools are being used properly (with the exception of AR, which I fixed) - My target system is an embedded PC104 module on which I would like to do some debugging. - 100% of the software on the embedded system, including the linux kernel, is compiled with the cross tool chain and everything works great except for vg. Thanks in advance, Dan Goertzen dan...@no... |
|
From: David F. <fa...@kd...> - 2003-11-06 19:09:00
|
Hi, I'm running a multithreaded program through valgrind. In some earlier versions of valgrind (1.9.5 maybe?), threads used to get their own ID, as seen in pthread_self(), starting at 1 (IIRC 0 was the main thread). With valgrind_2_0_really or valgrind CVS HEAD (KDE CVS), the thread gets an ID of 0, like the main thread, which makes the debugging a little more difficult. Thanks, David. PS: please CC me any replies, I'm not subscribed. -- David FAURE, fa...@kd..., sponsored by Trolltech to work on KDE, Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org). |
|
From: Tom H. <th...@cy...> - 2003-11-06 18:41:14
|
In message <87e...@vo...>
Andrés Roldán <ar...@de...> wrote:
> Tom Hughes <th...@cy...> writes:
>
> > Get a more recent version of valgrind that understand how to
> > disable NPTL.
>
> I could not find where to disable NPTL in the valgrind cvs. Can you give
> me a light?
The valgrind shell script does it automatically by setting LD_ASSUME_KERNEL
if your system appears to be using NPTL.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: <ar...@de...> - 2003-11-06 17:37:26
|
Tom Hughes <th...@cy...> writes: > In message <106...@ga...> > Ken Foskey <fo...@op...> wrote: > >> I have a problem piece of code that I brought home to test on and I >> could not run valgrind on it: >> >> valgrind: vg_ldt.c:167 (vgPlain_do_useseg): Assertion `(seg_selector & >> 7) == 7' failed. >> >> I just rebooted into Kernel 2.4 and it is now slogging away to find my >> bug. > > Get a more recent version of valgrind that understand how to > disable NPTL. I could not find where to disable NPTL in the valgrind cvs. Can you give me a light? > >> I found two other instances of this message on the web however there >> were no answers on them. > > Funny, because it's answered on a regular basis here, which reminds > me, can we *please* get this put in the FAQ... > > Tom > > -- > Tom Hughes (th...@cy...) > Software Engineer, Cyberscience Corporation > http://www.cyberscience.com/ > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users -- Andres Roldan Fluidsignal Group <ar...@fl...> The Debian Project <ar...@de...> GPG Key-ID: 0xB29396EB Home Page http://people.fluidsignal.com/~aroldan |
|
From: Dhirendra P. S. <dp...@ka...> - 2003-11-06 16:08:36
|
Hi All,
I am new to this valgrind. I am trying to valgrind my code. Its a pretty
decent size code with lot of multithreading. Now when I start valgrind
using the following command...
valgrind --num-callers=20 --alignment=8 --leak-check=yes
--leak-resolution=med --error-limit=no --show-reachable=yes
/usr/sbin/myprog
It shows me some error messages in the beginig, and then goes to sleep.
By sleep I mean that the process dosent dies but dosent do anything
either... It shows 0.0 percent cpu usage, and does not respond to key
stroke.
The last lines I can see on the screen are
==13919== Thread 2:
==13919== Conditional jump or move depends on uninitialised value(s)
==13919== at 0x804DBC1: TcpConnLis::ThreadProc() (tcplist.cxx:251)
==13919== by 0x804F960: ListenerThreadProc(void*) (tcplist.cxx:1088)
==13919== by 0x40A2BD8A: __thread_startup__(void*)
(../../osdep/posix/posix_thread.cxx:378)
==13919== by 0x411B0572: thread_wrapper (vg_libpthread.c:667)
==13919== by 0x4016C16B: do__quit (vg_scheduler.c:2146)
TcpConnLis::TcpConnLis() error: no TCP fixed port config
ListenerThreadProc() end, arg 1152967432
==13919== valgrind's libpthread.so: KLUDGED call to: sem_destroy
==13919== valgrind's libpthread.so: IGNORED call to:
pthread_attr_setinheritsched
==13919== valgrind's libpthread.so: IGNORED call to: pthread_setschedparam
As you would have assumed that myprog uses extensive posix thread and tpcip.
Now I tried to attach gdb/totalview to it this myprog while valgrinding.
And it shows the myprog is stuck at line 2154 of vg_scheduler.c ..
the code is as follows...
***********************
/* Should never be entered. If it is, will be on the simulated
CPU. */
static
void do__apply_in_new_thread_bogusRA ( void )
{
VG_(core_panic)("do__apply_in_new_thread_bogusRA");
}
******************************************
Following is the stack trace in total view..
vgPlain_do_syscall, FP=46d0bde4
recvmsg, FP=46d0be18
pollForFdXfers, FP=46d0bec8
_Z18__thread_startup__Pv, FP=46d0bf98
thread_wrapper, FP=46d0bfd4
do__quit, FP=46d0bfd4
PC: bfffe648, FP=bfffe648
...eRjPFiPvES0_16ThreadAttributesj, FP=bfffe6b8
main, FP=bfffe918
__libc_start_main, FP=bfffe948
Anyhelp would be very much appreciated as I want to get out of this ASAP
and continue valgrinding...
Thanks in advance
Dp
|
|
From: Ken F. <fo...@op...> - 2003-11-06 13:11:14
|
On Fri, 2003-11-07 at 00:05, Tom Hughes wrote: > Funny, because it's answered on a regular basis here, which reminds > me, can we *please* get this put in the FAQ... I did check the FAQ. I also scanned the archives, could not see how to search. -- Thanks KenF OpenOffice.org developer |
|
From: Tom H. <th...@cy...> - 2003-11-06 13:06:59
|
In message <106...@ga...>
Ken Foskey <fo...@op...> wrote:
> I have a problem piece of code that I brought home to test on and I
> could not run valgrind on it:
>
> valgrind: vg_ldt.c:167 (vgPlain_do_useseg): Assertion `(seg_selector &
> 7) == 7' failed.
>
> I just rebooted into Kernel 2.4 and it is now slogging away to find my
> bug.
Get a more recent version of valgrind that understand how to
disable NPTL.
> I found two other instances of this message on the web however there
> were no answers on them.
Funny, because it's answered on a regular basis here, which reminds
me, can we *please* get this put in the FAQ...
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Ken F. <fo...@op...> - 2003-11-06 12:44:05
|
I have a problem piece of code that I brought home to test on and I could not run valgrind on it: valgrind: vg_ldt.c:167 (vgPlain_do_useseg): Assertion `(seg_selector & 7) == 7' failed. I just rebooted into Kernel 2.4 and it is now slogging away to find my bug. I found two other instances of this message on the web however there were no answers on them. -- Thanks KenF OpenOffice.org developer |
|
From: tmoog <tm...@sa...> - 2003-11-04 14:59:23
|
valgrind is great
I recently upgraded to 2003-10-12 and had problems so I went
to 2003-07-25. I'm finding that 2003-07-25 is reporting
many problems with stl string operations, some as simple as
std::string foo;
...
foo = "";
or
foo += "something";
When I run the program under 1.0.4 the program is totallly
clean. Are others seeing this behavior ?
Second issue: I have send in patches for epoll operations, but
these don't seem to have migrated into the kit, when I last
checked about a month ago. What is the proper method of
submitting such changes ?
|
|
From: Dimitri Papadopoulos-O. <pap...@sh...> - 2003-11-04 14:01:22
|
Hi again, > Unfortunately I know close to nothing about automake/autoconf. > > Please find attached what seems to be an acceptable valgrind.pc.in file, > but I'm not sure how to integrate it to the automake/autoconf stuff. It would seem it's a simple question of modifying Makefile.am from: EXTRA_DIST = $(val_DATA) \ FAQ.txt \ PATCHES_APPLIED ACKNOWLEDGEMENTS \ README_KDE3_FOLKS README_PACKAGERS \ README_MISSING_SYSCALL_OR_IOCTL TODO \ valgrind.spec valgrind.spec.in to: EXTRA_DIST = $(val_DATA) \ FAQ.txt \ PATCHES_APPLIED ACKNOWLEDGEMENTS \ README_KDE3_FOLKS README_PACKAGERS \ README_MISSING_SYSCALL_OR_IOCTL TODO \ valgrind.spec valgrind.spec.in \ valgrind.pc.in and then adding: pkgconfigdir = $(libdir)/pkgconfig pkgconfig_DATA = valgrind.pc $(pkgconfig_DATA): config.status and finally changing configure.in from: AC_OUTPUT( Makefile valgrind.spec docs/Makefile [...] none/docs/Makefile ) to: AC_OUTPUT( Makefile valgrind.spec valgrind.pc docs/Makefile [...] none/docs/Makefile ) I'm not aware if some specific version of automake or autoconf are needed for that or not. -- Dimitri |
|
From: Dimitri Papadopoulos-O. <pap...@sh...> - 2003-11-04 12:09:03
|
Hi, >>It would be nice to have a bin/valgrind-config script or a >>lib/pkgconfig/valgrind.pc file, so that skins such as calltree can find >>the location of valgrind easily. > > > can you write a valgrind.pc file? I'll be happy to include it then. Unfortunately I know close to nothing about automake/autoconf. Please find attached what seems to be an acceptable valgrind.pc.in file, but I'm not sure how to integrate it to the automake/autoconf stuff. -- Dimitri |
|
From: Owen O'M. <ow...@em...> - 2003-11-03 19:04:46
|
I wrote a skin that writes an xml report and so I didn't want any
extra non-xml stuff in the log file. Fortunately, -q does a pretty
good job of keeping valgrind quiet. I just need to prevent the:
==11666==
==11666== My PID = 11666, parent PID = 28045. Prog and args are:
==11666== a.out
message from coming out. Therefore, I put in the following change that
adds an extra condition on the message above being printed. Writing
error logs in specific formats is a handy thing to be able to do and
Valgrind probably deserves a "better" solution so that the skin can
request a quiet run.
Thanks,
Owen
PS. I can post my trivial skin if there is any interest. Currently it
just prints the pattern of pthread lock accesses. The output log looks
like:
<run>
...
<thread-create parent="1" child="2"/>
<mutex-request thread="1" mutex="0x08049C60"/>
<mutex-lock thread="1" mutex="0x08049C60"/>
<mutex-request thread="1" mutex="0x40270A18"/>
<mutex-lock thread="1" mutex="0x40270A18"/>
<mutex-unlock thread="1" mutex="0x40270A18"/>
...
</run>
*** coregrind/vg_main.c~ Mon Nov 3 10:50:41 2003
--- coregrind/vg_main.c Mon Nov 3 10:51:16 2003
***************
*** 1188,1194 ****
"Copyright (C) 2000-2003, and GNU GPL'd, by Julian
Seward.");
}
! if (VG_(clo_log_to) != VgLogTo_Fd) {
VG_(message)(Vg_UserMsg, "");
VG_(message)(Vg_UserMsg,
"My PID = %d, parent PID = %d. Prog and args are:",
--- 1188,1194 ----
"Copyright (C) 2000-2003, and GNU GPL'd, by Julian
Seward.");
}
! if (VG_(clo_verbosity) > 0 && VG_(clo_log_to) != VgLogTo_Fd) {
VG_(message)(Vg_UserMsg, "");
VG_(message)(Vg_UserMsg,
"My PID = %d, parent PID = %d. Prog and args are:",
|
|
From: Avery P. <ape...@ni...> - 2003-11-03 18:31:31
|
On Mon, Nov 03, 2003 at 12:50:40PM +0100, Peter Firefly Lund wrote:
> On Sun, 2 Nov 2003, Avery Pennarun wrote:
>
> > int x;
>
> shouldn't x be volatile in any case?
>
> (otherwise it might be stored in a register at setjmp/longjmp time -- and
> they are not required to save/restore registers so when another task
> longjmps back to your setjmp x will be trashed)
I'm willing to be proven wrong, but my understanding is that setjmp and
longjmp are allowed to trash any registers that any other function call is
allowed to trash - no more, no less. Therefore, the compiler should do the
right thing even if x isn't volatile.
> > if (!setjmp)
> > longjmp(elsewhere)
> > // else someone longjmped back to me
> > VALGRIND_MAKE_READABLE(blah blah)
> > printf("x is now %d\n", x);
>
> What you would really like is to save/restore the validity bits for a
> whole memory range together with your setjmp/longjmp. A stack of validity
> stored bits won't be enough - you'll either need access to some id for
> each range (and have valgrind manage the memory) or you'll need some sort
> of escape hatch to copy these bits between valgrind and your memory space.
Not really - imagine if I do
int x;
obj->set_xptr(&x);
if (!setjmp)
longjmp(someone who sets x);
// else someone longjmped back to me
printf("x is now %d\n", x);
I expect the flags for 'x' to not be wiped by longjmp *and* to be different
upon return than they were when I left. Suspending the auto-flag-changes
temporarily, then resuming them, would do this.
Revalidating the entire stack will also work, and that's what I'm doing
right now, but it loses some of valgrind's protection.
Have fun,
Avery
|
|
From: Jeremy F. <je...@go...> - 2003-11-03 17:08:00
|
On Mon, 2003-11-03 at 07:56, Andrés Roldán wrote: > Hi all. > > I've been maintaining valgrind for Debian using 2.4 kernel series. > > Debian glibc maintainers have included now glibc packages compiled with > linux 2.6 headers and then valgrind compilation stop working. > > The problem is that valgrind includes kernel headers directly instead > of make a local copy of those constants and definitions on the valgrind > headers. We seem to be moving in that direction anyway (see the addition of vg_unistd.h). vg_unsafe.h is a bit of a mess, and it will continue to bite us - but copying a minimal subset of the kernel headers (and maybe doing a vg/vki transform on them) is a moderately tedious editoral job which nobody has taken up yet. J |
|
From: Jeremy F. <je...@go...> - 2003-11-03 17:04:17
|
On Mon, 2003-11-03 at 07:21, arn...@re... wrote:
> I complied it with gcc and ran valgrind --skin=memcheck
> --leak-check=yes --leak-resolution=high --show-reachable=yes
> test_leak.
>
> Valgrind did detect all problems but did not detect the strcpy errors
> (stack overwrite) on variables str2 and str3.
>
> Looks like a valgrind bug to me.
That's definitely an error we'd like to catch, but we can't at present.
The problem is that there's no way from looking at the machine-code
itself to tell what the bounds of the arrays on stack are, so we can't
check accesses to them. Nick is hoping to be able to extract enough
details from the debug information so we can use that to determine the
bounds of arrays on the stack.
So, it isn't a bug in the sense that Valgrind is supposed to check for
it now, but it is something we'd like to have.
J
|
|
From: Bill R. Jr. <bru...@te...> - 2003-11-03 16:19:48
|
On Fri, Oct 31, 2003 at 10:18:41AM +0100, Josef Weidendorfer wrote: > I would like to integrate events related to data structures in my > calltree skin. I recently had no time for this, but it is definitely on > my TODO. > > Perhaps we can work together to make this a reality? I too am swamped with other things; it will be a few months at least before I can devote any real time to this, though I may get a chance to play with modifying the cachegrind output format and running some data through some stat tools like R. I have long-term profiling needs that would be well-served by this type of skin, so I'll try to allocate time in my work schedule. I've seen an app with soft-realtime requirements spend 80+% of its time waiting for cache-misses; a little guesswork more than halved that overhead. Regards, Bill Rugolsky |
|
From: <ar...@de...> - 2003-11-03 15:56:34
|
Hi all. I've been maintaining valgrind for Debian using 2.4 kernel series. Debian glibc maintainers have included now glibc packages compiled with linux 2.6 headers and then valgrind compilation stop working. The problem is that valgrind includes kernel headers directly instead of make a local copy of those constants and definitions on the valgrind headers. I've attached a patch that solves the problem (for the moment) and I was able to recompile valgrind again. However, it would be good to re-evaluate the way valgrind includes its files. Thanks for the good work so far :) |