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
|
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
1
|
|
2
(3) |
3
(14) |
4
(33) |
5
(1) |
6
(11) |
7
(4) |
8
(3) |
|
9
|
10
(13) |
11
(23) |
12
(4) |
13
(4) |
14
(7) |
15
(1) |
|
16
|
17
(29) |
18
(24) |
19
(5) |
20
(8) |
21
(8) |
22
(3) |
|
23
|
24
(1) |
25
(9) |
26
(4) |
27
(8) |
28
(7) |
29
(5) |
|
30
(6) |
31
(3) |
|
|
|
|
|
|
From: Tom H. <to...@co...> - 2005-10-04 12:15:07
|
In message <20051004120104.GA1236@white>
Bob Rossi <bo...@br...> wrote:
> This works most of the time, of course. However, if your program changes
> the state of something external (filesystem, network sockets, ...), then
> when you "carry on", something could potentially hit the fan. In this
> situation, the best bet is to fix the problem and restart.
Which program? The valgrind client is suspended as is the copy of it
that is being debugged.
Obviously the user can use a shell to do something horrible while we
are in the debugger but that is always true even if you're not in the
debugger.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Bob R. <bo...@br...> - 2005-10-04 12:01:24
|
On Tue, Oct 04, 2005 at 09:27:46AM +0100, Tom Hughes wrote: > In message <4341F283.6030600@BitWagon.com> > John Reiser <jreiser@BitWagon.com> wrote: > > > Tom Hughes wrote: > >> In message <4341B3F4.9060605@BitWagon.com> > >> John Reiser <jreiser@BitWagon.com> wrote: > >> > >> > >>>>2) I'm not sure how you're supposed to continue execution from gdb. > >>> > >>>"detach" then "quit": > >> > >> > >> A simple quit has always been enough in my experience - that was > >> certainly the intention. > >> > >> Even though I wrote the current debugger attachment code it isn't > >> actually something I actually use very often - hardly ever in > >> fact - so there might well be a problem. > > > > Looking carefully at the process numbers, the debugger is not dealing > > with the original process itself, but with a fork(). [In the output below, > > the original process is 9614, the fork is 9615, and the gdb is 9616.] > > So the debugger cannot alter the state of the original process, such as > > by "set var my_var = 123" Why? Running gdb on yourself works, and > > with proper care can even be told to use the user's symbols, and ignore > > valgrind's. See the second example below. [It might be necessary to > > spoon-feed some 'add-symbol-file' commands ahead of interactive input.] > > The reason we fork a copy of the process is that we want the debugger > to see the simulated register set rather than the real register set. > > So we fork a copy then use ptrace to change that copy's registers to > hold the simulated registers and then attach a debugger to the copy > and wait for the debugger to finish. When the debugger is done we > make sure the copy is dead and then carry on. This works most of the time, of course. However, if your program changes the state of something external (filesystem, network sockets, ...), then when you "carry on", something could potentially hit the fan. In this situation, the best bet is to fix the problem and restart. Bob Rossi |
|
From: Josef W. <Jos...@gm...> - 2005-10-04 09:39:38
|
On Tuesday 04 October 2005 10:31, Bill Howe wrote: > Using massif, I'm seeing the heap-admin band growing over time, but no > other bands are. =A0I'm not sure how =A0my code could be causing a leak t= o be > reported under heap-admin and only under heap-admin. =A0Does anyone know = how > to interpret this behavior? malloc(0) ? Josef |
|
From: Tom H. <to...@co...> - 2005-10-04 08:54:05
|
In message <200...@or...>
Christoph Bartoschek <bar...@or...> wrote:
> running valgrind SVN from friday I get the following error:
>
> --11952:0:aspacem Valgrind: FATAL: M_PROCMAP_BUF is too low.
> --11952:0:aspacem Increase it and rebuild. Exiting now.
>
> How to do this?
How about grepping the source for M_PROCMAP_BUF and increasing it?
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Christoph B. <bar...@or...> - 2005-10-04 08:45:39
|
Hi, running valgrind SVN from friday I get the following error: --11952:0:aspacem Valgrind: FATAL: M_PROCMAP_BUF is too low. --11952:0:aspacem Increase it and rebuild. Exiting now. How to do this? Christoph Bartoschek |
|
From: Bill H. <ho...@cs...> - 2005-10-04 08:32:09
|
Using massif, I'm seeing the heap-admin band growing over time, but no other bands are. I'm not sure how my code could be causing a leak to be reported under heap-admin and only under heap-admin. Does anyone know how to interpret this behavior? A postscript plot generated by massif illustrating the behavior is here: http://cormorant.cs.pdx.edu/heapgrow.ps and the accompanying call graph is here: http://cormorant.cs.pdx.edu/heapgrow.txt I'm using STL with the deafult allocators, so some allocated memory won't be returned to the OS. However, the STL allocators should reuse previously allocated memory rather than continue to allocate more! Thanks for any help, Bill |
|
From: Tom H. <to...@co...> - 2005-10-04 08:27:57
|
In message <4341F283.6030600@BitWagon.com>
John Reiser <jreiser@BitWagon.com> wrote:
> Tom Hughes wrote:
>> In message <4341B3F4.9060605@BitWagon.com>
>> John Reiser <jreiser@BitWagon.com> wrote:
>>
>>
>>>>2) I'm not sure how you're supposed to continue execution from gdb.
>>>
>>>"detach" then "quit":
>>
>>
>> A simple quit has always been enough in my experience - that was
>> certainly the intention.
>>
>> Even though I wrote the current debugger attachment code it isn't
>> actually something I actually use very often - hardly ever in
>> fact - so there might well be a problem.
>
> Looking carefully at the process numbers, the debugger is not dealing
> with the original process itself, but with a fork(). [In the output below,
> the original process is 9614, the fork is 9615, and the gdb is 9616.]
> So the debugger cannot alter the state of the original process, such as
> by "set var my_var = 123" Why? Running gdb on yourself works, and
> with proper care can even be told to use the user's symbols, and ignore
> valgrind's. See the second example below. [It might be necessary to
> spoon-feed some 'add-symbol-file' commands ahead of interactive input.]
The reason we fork a copy of the process is that we want the debugger
to see the simulated register set rather than the real register set.
So we fork a copy then use ptrace to change that copy's registers to
hold the simulated registers and then attach a debugger to the copy
and wait for the debugger to finish. When the debugger is done we
make sure the copy is dead and then carry on.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: John R.
|
Tom Hughes wrote:
> In message <4341B3F4.9060605@BitWagon.com>
> John Reiser <jreiser@BitWagon.com> wrote:
>
>
>>>2) I'm not sure how you're supposed to continue execution from gdb.
>>
>>"detach" then "quit":
>
>
> A simple quit has always been enough in my experience - that was
> certainly the intention.
>
> Even though I wrote the current debugger attachment code it isn't
> actually something I actually use very often - hardly ever in
> fact - so there might well be a problem.
Looking carefully at the process numbers, the debugger is not dealing
with the original process itself, but with a fork(). [In the output below,
the original process is 9614, the fork is 9615, and the gdb is 9616.]
So the debugger cannot alter the state of the original process, such as
by "set var my_var = 123" Why? Running gdb on yourself works, and
with proper care can even be told to use the user's symbols, and ignore
valgrind's. See the second example below. [It might be necessary to
spoon-feed some 'add-symbol-file' commands ahead of interactive input.]
=====invoking gdb from valgrind(memcheck); note 3 processes: vg, vg.fork(), gdb.
==9614== ---- Attach to debugger ? --- [Return/N/n/Y/y/C/c] ---- y
starting debugger
==9614== starting debugger with cmd: /usr/bin/gdb -nw /proc/9615/fd/1015 9615
[gdb banner snipped]
Attaching to program: /proc/9615/fd/1015, process 9615
0xb0022d0d in ?? ()
(gdb) shell
[user@host ~]$ ps l
F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND
0 500 2561 2542 15 0 4512 1500 wait Ss pts/0 0:00 bash
0 500 9614 2561 16 0 1557980 8608 wait S pts/0 0:00 valgrind301
--db-attach=yes ./uninit
0 500 9616 9614 15 0 6972 2784 wait S pts/0 0:00 /usr/bin/gdb -nw
/proc/9615/fd/1015 9615
1 500 9615 9614 17 0 1557980 8612 finish T pts/0 0:00 valgrind301
--db-attach=yes ./uninit
0 500 9619 9616 15 0 4512 1488 wait S pts/0 0:00 bash
0 500 9639 9619 16 0 4440 812 - R+ pts/0 0:00 ps l
$
=====
=====invoking gdb on yourself
$ cat gdbself.c
#include <stdio.h>
#include <unistd.h>
int x;
char cmd[100];
main(int argc, char *argv[])
{
printf("x=%d\n", x);
sprintf(cmd, "gdb %s %d\n", argv[0], getpid());
printf("%s\n", cmd);
system(cmd);
printf("x=%d\n", x);
return 0;
}
$ gcc -g -o gdbself gdbself.c
$ ./gdbself
x=0 ## note original value
gdb ./gdbself 9797
[gdb banner snipped]
Attaching to program: ./gdbself, process 9797
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
0x001c9402 in ?? ()
(gdb) shell
$ ps l
F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND
0 500 9619 2542 16 0 4516 1488 - Ss+ pts/1 0:00 bash
0 500 9798 9797 15 0 8736 4468 wait S pts/0 0:00 gdb ./gdbself 9797
0 500 9797 9619 16 0 1412 344 ptrace T pts/0 0:00 ./gdbself
0 500 9803 9798 15 0 4516 1492 wait S pts/0 0:00 bash
0 500 9823 9803 16 0 4444 812 - R+ pts/0 0:00 ps l
$ exit
(gdb) set var x = 123 ## change value in debugger
(gdb) q
The program is running. Quit anyway (and detach it)? (y or n) y
Detaching from program: ./gdbself, process 9797
x=123 ## note that the value got changed
$
=====
--
|