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
(6) |
2
(16) |
3
(3) |
4
(11) |
5
(2) |
|
6
(4) |
7
(11) |
8
(4) |
9
(6) |
10
(25) |
11
(10) |
12
(1) |
|
13
(2) |
14
(6) |
15
(16) |
16
(19) |
17
(16) |
18
(5) |
19
|
|
20
(4) |
21
(5) |
22
(21) |
23
(4) |
24
(14) |
25
(3) |
26
(9) |
|
27
(3) |
28
(13) |
29
(6) |
30
(16) |
|
|
|
|
From: Conrad H. <CH...@fo...> - 2003-04-10 21:35:28
|
Thank you so much; it built and installed perfectly just now with a locally built Make 3.80. This version of RedHat Linux used Make 3.79. Problem solved! -----Original Message----- From: Julian Seward To: Conrad Heiney; 'val...@li...' Cc: Sean Crowe Sent: 4/10/03 2:26 PM Subject: Re: [Valgrind-users] Unable to build valgrind on RedHat Linux 7.2 > make: expand.c:489: allocated_variable_append: Assertion > `current_variable_set_list->next != 0' failed. Yeh, I've seen this before a couple of times. Somehow it seems like a bug in GNU make. All I can suggest is that you try a newer version of gnu make (I guess it is not hard to build from source). J > > Is there a workaround for this, or should I stay with 1.0.4 or some other > earlier version on this version of Linux? > > Thanks, > > Conrad Heiney > Senior Unix System Administrator > FOXSports.com > > > ------------------------------------------------------- > This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger > for complex code. Debugging C/C++ programs can leave you feeling lost and > disoriented. TotalView can help you find your way. Available on major UNIX > and Linux platforms. Try it free. www.etnus.com > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Julian S. <js...@ac...> - 2003-04-10 21:26:42
|
> make: expand.c:489: allocated_variable_append: Assertion > `current_variable_set_list->next != 0' failed. Yeh, I've seen this before a couple of times. Somehow it seems like a bug in GNU make. All I can suggest is that you try a newer version of gnu make (I guess it is not hard to build from source). J > > Is there a workaround for this, or should I stay with 1.0.4 or some other > earlier version on this version of Linux? > > Thanks, > > Conrad Heiney > Senior Unix System Administrator > FOXSports.com > > > ------------------------------------------------------- > This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger > for complex code. Debugging C/C++ programs can leave you feeling lost and > disoriented. TotalView can help you find your way. Available on major UNIX > and Linux platforms. Try it free. www.etnus.com > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Julian S. <js...@ac...> - 2003-04-10 21:22:09
|
On Thursday 10 April 2003 10:21 am, David Eriksson wrote: > On Thu, 2003-04-10 at 12:14, Luke Howard wrote: > > >What valgrind version are you using? > > > > 1.9.3. I will try 1.9.5 and report any improvements. > > May I suggeest that you also try the old 1.0.4 version. > > The reason for this is that I have a program with sockets and threads > that works fine in 1.0.4 but has problems in 1.9.4. I haven't tried > 1.9.5 yet. Really? Can you send a test case? That shouldn't happen. I know there are some difficulties on glibc-2.3.X systems, but apart from that 1.9.X should run anything 1.0.X runs. J |
|
From: Crispin F. <cr...@th...> - 2003-04-10 20:44:14
|
I just tried the sample code (once I had got it to compile) and it
worked fine - as expected. If you can provide a complete program that
acts as a test case, then you may have more luck tracking down the
problem in your code.
Crispin
On Thu, 2003-04-10 at 21:28, Xiang Yan wrote:
> On Thu, 10 Apr 2003, Xiang Yan wrote:
> >
> > > My question is, for code below, valgrind will report an error or not on
> memory allocated for c1::m_p1?
> > > class c1
> > > {
> > > ~c1()
> > > {
> > > delete []m_p1;
> > > }
> > > void * m_p1;
> > > }
> > >
> > > class c2
> > > {
> > > ~c2() {
> > > if(m_c1 != NULL)
> > > delete []m_c1;
> > > }
> > > func1() {
> > > m_c1 = new c1[10];
> > > for(i = 0; i < 10; i++) {
> > > m_c1[i].m_p1 = new char[10]; // reports definitely lost here
> > > }
> > > }
> > > c1 *m_c1;
> > > }
> > >
> > > somewhere else outside above class has following call:
> > > c2 *pc2 = new c2();
> > > c2->func1();
> > > delete c2;
> >
> > You've written an almost-whole program, and you want to know what Valgrind
> > says about it?
> >
> > It looks to me like there won't be any errors, because AFAICT the memory
> > is all deallocated correctly. But I suggest you finish and compile the
> > program, and run Valgrind on it.
>
> That's the result of running Valgrind on my code, the line it indicated is
> below with definitly lost message:
> m_c1[i].m_p1 = new char[10]; // refer to above
> (it's multithreaded btw)
>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger
> for complex code. Debugging C/C++ programs can leave you feeling lost and
> disoriented. TotalView can help you find your way. Available on major UNIX
> and Linux platforms. Try it free. www.etnus.com
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>
|
|
From: Xiang Y. <xy...@pr...> - 2003-04-10 20:33:59
|
Hello, I know 1.9.5 has an option of dumping message to a file, but 1.0.4 = online help doesn't have this info. Any way can dump valgrind's output = to a file for v1.0.4 TIA Xiang |
|
From: Xiang Y. <xy...@pr...> - 2003-04-10 20:29:12
|
On Thu, 10 Apr 2003, Xiang Yan wrote:
>
> > My question is, for code below, valgrind will report an error or not on
memory allocated for c1::m_p1?
> > class c1
> > {
> > ~c1()
> > {
> > delete []m_p1;
> > }
> > void * m_p1;
> > }
> >
> > class c2
> > {
> > ~c2() {
> > if(m_c1 != NULL)
> > delete []m_c1;
> > }
> > func1() {
> > m_c1 = new c1[10];
> > for(i = 0; i < 10; i++) {
> > m_c1[i].m_p1 = new char[10]; // reports definitely lost here
> > }
> > }
> > c1 *m_c1;
> > }
> >
> > somewhere else outside above class has following call:
> > c2 *pc2 = new c2();
> > c2->func1();
> > delete c2;
>
> You've written an almost-whole program, and you want to know what Valgrind
> says about it?
>
> It looks to me like there won't be any errors, because AFAICT the memory
> is all deallocated correctly. But I suggest you finish and compile the
> program, and run Valgrind on it.
That's the result of running Valgrind on my code, the line it indicated is
below with definitly lost message:
m_c1[i].m_p1 = new char[10]; // refer to above
(it's multithreaded btw)
|
|
From: Conrad H. <CH...@fo...> - 2003-04-10 20:00:01
|
I attempted to upgrade from version 1.0.4 to version 1.9.5 on a Red Hat Linux 7.2 system, and got the following error on 'make': make[3]: Entering directory `/home/cheiney/valgrind-1.9.5/coregrind' source='vg_clientfuncs.c' object='vg_clientfuncs.o' libtool=no \ depfile='.deps/vg_clientfuncs.Po' tmpdepfile='.deps/vg_clientfuncs.TPo' \ depmode=gcc3 /bin/sh ../depcomp \ gcc -DHAVE_CONFIG_H -I. -I. -I.. -I./demangle -I../include -DVG_LIBDIR="\"/usr/local/lib"\" -Winline -Wall -Wshadow -O -fomit-frame-pointer -mpreferred-stack-boundary=2 -g -fno-omit-frame-pointer -c `test -f 'vg_clientfuncs.c' || echo './'`vg_clientfuncs.c make: expand.c:489: allocated_variable_append: Assertion `current_variable_set_list->next != 0' failed. Is there a workaround for this, or should I stay with 1.0.4 or some other earlier version on this version of Linux? Thanks, Conrad Heiney Senior Unix System Administrator FOXSports.com |
|
From: Nicholas N. <nj...@ca...> - 2003-04-10 18:33:28
|
On Thu, 10 Apr 2003, Xiang Yan wrote:
> My question is, for code below, valgrind will report an error or not on memory allocated for c1::m_p1?
> class c1
> {
> ~c1()
> {
> delete []m_p1;
> }
> void * m_p1;
> }
>
> class c2
> {
> ~c2() {
> if(m_c1 != NULL)
> delete []m_c1;
> }
> func1() {
> m_c1 = new c1[10];
> for(i = 0; i < 10; i++) {
> m_c1[i].m_p1 = new char[10];
> }
> }
> c1 *m_c1;
> }
>
> somewhere else outside above class has following call:
> c2 *pc2 = new c2();
> c2->func1();
> delete c2;
You've written an almost-whole program, and you want to know what Valgrind
says about it?
It looks to me like there won't be any errors, because AFAICT the memory
is all deallocated correctly. But I suggest you finish and compile the
program, and run Valgrind on it.
N
|
|
From: Xiang Y. <xy...@pr...> - 2003-04-10 17:40:36
|
Hello,
I got following message with --leak-check=3Dyes, valgrind 1.0.4.
=3D=3D1750=3D=3D 1825 bytes in 146 blocks are definitely lost in loss =
record 98 o
=3D=3D1750=3D=3D at 0x400485EC: __builtin_vec_new =
(vg_clientfuncs.c:156)
=3D=3D1750=3D=3D by 0x8061119: idgapis::prepareparams(void) =
(idgapis.cpp:904)
=3D=3D1750=3D=3D by 0x806199E: idgapis::proc(void) (idgapis.cpp:1052)
=3D=3D1750=3D=3D by 0x8063ED7: idgsockthread::callapi(void) =
(idgsockthread.cpp
My question is, for code below, valgrind will report an error or not on =
memory allocated for c1::m_p1?
class c1
{
~c1()=20
{
delete []m_p1;
}
void * m_p1;
}
class c2
{
~c2() {
if(m_c1 !=3D NULL)
delete []m_c1;
}
func1() {
m_c1 =3D new c1[10];
for(i =3D 0; i < 10; i++) {
m_c1[i].m_p1 =3D new char[10];
}
}=20
c1 *m_c1;
}
somewhere else outside above class has following call:
c2 *pc2 =3D new c2();
c2->func1();
delete c2;
TIA
Xiang
|
|
From: Nicholas N. <nj...@ca...> - 2003-04-10 17:01:13
|
On 10 Apr 2003, Tom Roeder wrote: > I have a question to which I hope the answer is simple, but I haven't > managed to find any way to do it short of hacking the code myself. I > have a program (it happens to be ns, the network simulator) that I have > been working on for a while. There's a memory leak, and it ends up > getting a signal and dying on an out of memory error. The problem is > that when it dies, valgrind gives up too! I would much rather have > valgrind catch that signal and print out what it knows about the memory > problems already. Similarly, it has occasionally happened that I have > wanted to stop valgrind short in a run and tell it to print out what it > knows. Unfortunately, at least when I did it, Ctrl-C just causes it to > quit and not tell me anything. All of this could be solved if there > were some sort of command-line option like > > "--catch-signal-and-report=<signals>" > > where I could give it a list of signals and it would report on memory > problems before giving up when receiving them. I have a good knowledge > of C and C++, but I don't have much time to try to understand the > valgrind code and figure it out and add this option in a way that > doesn't interfere with other valgrind signal functionality. If this has > already been implemented, so much the better. If not, could anyone give > me a pointer into where this might be done in the code, so I can try to > add the signal handlers myself? Can you catch the signal with the client program? If so, in the signal handler, you could call the VALGRIND_DO_LEAK_CHECK macro (just #include memcheck.h) to do a leak check at that point. N |
|
From: Tom R. <tmr...@cs...> - 2003-04-10 16:39:19
|
Hi valgrind users,
I have a question to which I hope the answer is simple, but I haven't
managed to find any way to do it short of hacking the code myself. I
have a program (it happens to be ns, the network simulator) that I have
been working on for a while. There's a memory leak, and it ends up
getting a signal and dying on an out of memory error. The problem is
that when it dies, valgrind gives up too! I would much rather have
valgrind catch that signal and print out what it knows about the memory
problems already. Similarly, it has occasionally happened that I have
wanted to stop valgrind short in a run and tell it to print out what it
knows. Unfortunately, at least when I did it, Ctrl-C just causes it to
quit and not tell me anything. All of this could be solved if there
were some sort of command-line option like
"--catch-signal-and-report=<signals>"
where I could give it a list of signals and it would report on memory
problems before giving up when receiving them. I have a good knowledge
of C and C++, but I don't have much time to try to understand the
valgrind code and figure it out and add this option in a way that
doesn't interfere with other valgrind signal functionality. If this has
already been implemented, so much the better. If not, could anyone give
me a pointer into where this might be done in the code, so I can try to
add the signal handlers myself?
Thanks muchly, :-)
Tom Roeder
|
|
From: Xiang Y. <xy...@pr...> - 2003-04-10 16:31:53
|
> On Thu, 10 Apr 2003, Xiang Yan wrote: > > > > > ==32225== Conditional jump or move depends on uninitialised value(s) > > > > ==32225== at 0x86823C2: CMP_Compare (in /home/xiang/test/m27/srv) > > > > ==32225== by 0x8684660: CMP_ModularReduce (in > > /home/xiang/test/m27/srv) > > > > ==32225== by 0x868DBA7: Alg_ComputeModQ_GHash (in > > /home/xiang/test/m27/srv) > > > > ==32225== by 0x86686CA: A_X931RandomGenerateBytes (in > > /home/xiang/test/m27/srv) > > > > > > For a start, recompile the code in question with -g if you can, so you at > > > least get line numbers in your error messages. > > > > > > > I'm using -g, no line number. I'm suspecting it's inside oracle oci lib. Is > > it possible? > > Er... is what possible? Getting line numbers -- depends if you can > recompile /home/xiang/test/m27/srv, whatever that is... > Thanks. No, it's in debuging mode, couldn't get the line numbers somehow. All errors(total 2500) come from one oracle oci function call, so I have to give up cleaning them :( |
|
From: Nicholas N. <nj...@ca...> - 2003-04-10 16:23:18
|
On Thu, 10 Apr 2003, Xiang Yan wrote: > > > ==32225== Conditional jump or move depends on uninitialised value(s) > > > ==32225== at 0x86823C2: CMP_Compare (in /home/xiang/test/m27/srv) > > > ==32225== by 0x8684660: CMP_ModularReduce (in > /home/xiang/test/m27/srv) > > > ==32225== by 0x868DBA7: Alg_ComputeModQ_GHash (in > /home/xiang/test/m27/srv) > > > ==32225== by 0x86686CA: A_X931RandomGenerateBytes (in > /home/xiang/test/m27/srv) > > > > For a start, recompile the code in question with -g if you can, so you at > > least get line numbers in your error messages. > > > > I'm using -g, no line number. I'm suspecting it's inside oracle oci lib. Is > it possible? Er... is what possible? Getting line numbers -- depends if you can recompile /home/xiang/test/m27/srv, whatever that is... N |
|
From: Xiang Y. <xy...@pr...> - 2003-04-10 16:09:14
|
> > I'm developing a server runing on linux, my environment is redhat ads, > > gcc 2.96. Here are some results from valgrind 1.04, all functions > > displayed are not mine:). How can I get more clues on cleaning? > > > > /// Valgrind 1.0.4 > > ==32225== Conditional jump or move depends on uninitialised value(s) > > ==32225== at 0x86823C2: CMP_Compare (in /home/xiang/test/m27/srv) > > ==32225== by 0x8684660: CMP_ModularReduce (in /home/xiang/test/m27/srv) > > ==32225== by 0x868DBA7: Alg_ComputeModQ_GHash (in /home/xiang/test/m27/srv) > > ==32225== by 0x86686CA: A_X931RandomGenerateBytes (in /home/xiang/test/m27/srv) > > For a start, recompile the code in question with -g if you can, so you at > least get line numbers in your error messages. > I'm using -g, no line number. I'm suspecting it's inside oracle oci lib. Is it possible? |
|
From: Sebastian K. <Seb...@so...> - 2003-04-10 15:26:12
|
At first (this is my first post here), hello to everyone, especially developers -- thanks for creating such great tool (it puts some commercial $$$ stuff, I was once using, to shame -- V is more powerful, more feature rich, and on text console is much more useable, than the other $tuff was with gui) ----- Original Message ----- From: "Jeremy Fitzhardinge" <je...@go...> > Quoting Julian Seward <js...@ac...>: > > > Try the patch called 09-rdtsc-calibration from > > http://www.goop.org/~jeremy/valgrind/ > > I doubt that will help much - that just stops an assertion failure when getting > the calibration. The basic problem is that the TSC is variable-rate, and > therefore useless as a timebase. Well, using TSC for counting time is not *The Right Thing(tm)*. Is it impossible to use some other measurement instead (at best OS provided)? What are the issues? rgds Sebastian Kaliszewski |
|
From: Nicholas N. <nj...@ca...> - 2003-04-10 15:20:48
|
On Thu, 10 Apr 2003, Xiang Yan wrote: > I'm developing a server runing on linux, my environment is redhat ads, > gcc 2.96. Here are some results from valgrind 1.04, all functions > displayed are not mine:). How can I get more clues on cleaning? > > /// Valgrind 1.0.4 > ==32225== Conditional jump or move depends on uninitialised value(s) > ==32225== at 0x86823C2: CMP_Compare (in /home/xiang/test/m27/srv) > ==32225== by 0x8684660: CMP_ModularReduce (in /home/xiang/test/m27/srv) > ==32225== by 0x868DBA7: Alg_ComputeModQ_GHash (in /home/xiang/test/m27/srv) > ==32225== by 0x86686CA: A_X931RandomGenerateBytes (in /home/xiang/test/m27/srv) For a start, recompile the code in question with -g if you can, so you at least get line numbers in your error messages. N |
|
From: Xiang Y. <xy...@pr...> - 2003-04-10 14:49:52
|
Hello, I'm developing a server runing on linux, my environment is redhat ads, = gcc 2.96. Here are some results from valgrind 1.04, all functions = displayed are not mine:). How can I get more clues on cleaning? TIA =20 Xiang=20 /// Valgrind 1.0.4 =3D=3D32225=3D=3D Conditional jump or move depends on uninitialised = value(s) =3D=3D32225=3D=3D at 0x86823C2: CMP_Compare (in = /home/xiang/test/m27/srv) =3D=3D32225=3D=3D by 0x8684660: CMP_ModularReduce (in = /home/xiang/test/m27/srv) =3D=3D32225=3D=3D by 0x868DBA7: Alg_ComputeModQ_GHash (in = /home/xiang/test/m27/srv) =3D=3D32225=3D=3D by 0x86686CA: A_X931RandomGenerateBytes (in = /home/xiang/test/m27/srv) =3D=3D32225=3D=3D Conditional jump or move depends on uninitialised = value(s) =3D=3D32225=3D=3D at 0x86823D0: CMP_Compare (in = /home/xiang/test/m27/srv) =3D=3D32225=3D=3D by 0x8684660: CMP_ModularReduce (in = /home/xiang/test/m27/srv) =3D=3D32225=3D=3D by 0x868DBA7: Alg_ComputeModQ_GHash (in = /home/xiang/test/m27/srv) =3D=3D32225=3D=3D by 0x86686CA: A_X931RandomGenerateBytes (in = /home/xiang/test/m27/srv) =3D=3D32225=3D=3D Conditional jump or move depends on uninitialised = value(s) =3D=3D32225=3D=3D at 0x86827E8: CMP_CMPIntToOctetString (in = /home/xiang/test/m27/srv) =3D=3D32225=3D=3D by 0x8682944: CMP_CMPIntToFixedLenOctetStr (in = /home/xiang/test/m27/srv) =3D=3D32225=3D=3D by 0x866858E: A_X931RandomGenerateBytes (in = /home/xiang/test/m27/srv) =3D=3D32225=3D=3D by 0x84B6CE4: ztcrandom (in = /home/xiang/test/m27/srv) =3D=3D32225=3D=3D Use of uninitialised value of size 4 =3D=3D32225=3D=3D at 0x84B8931: ztvopepad (in = /home/xiang/test/m27/srv) =3D=3D32225=3D=3D by 0x84B8811: ztvope (in /home/xiang/test/m27/srv) =3D=3D32225=3D=3D by 0x826A43E: kzsrepw (in /home/xiang/test/m27/srv) =3D=3D32225=3D=3D by 0x82613F5: kpu8lgn (in /home/xiang/test/m27/srv) Use of uninitialised value of size 4 =3D=3D32225=3D=3D at 0x84B3CD7: ztcedecb (in = /home/xiang/test/m27/srv) =3D=3D32225=3D=3D by 0x84B8504: ztvo3de (in /home/xiang/test/m27/srv) =3D=3D32225=3D=3D by 0x84B8832: ztvope (in /home/xiang/test/m27/srv) =3D=3D32225=3D=3D by 0x826A43E: kzsrepw (in /home/xiang/test/m27/srv) =3D=3D32225=3D=3D |
|
From: Nicholas N. <nj...@ca...> - 2003-04-10 12:09:17
|
On Thu, 10 Apr 2003, Bastien Chevreux wrote: > Uh, just thinking about it: debugging valgrind with itself, is that possible? > :-) Nope, unfortunately not, due to the LD_PRELOAD (ab)use at start-up. One of the reasons we'd like to not use it. Reminds me of an error message I saw on some kind of emulator program (User Mode Linux, or Wine, or something like that, I can't remember): "Error: Foo cannot run itself. You just had to try, didn't you?" N |
|
From: Bastien C. <ba...@ch...> - 2003-04-10 11:47:36
|
On Thursday 10 April 2003 12:31, Luke Howard wrote:
> ...
> And that this is potentially the problem.
Uh, just thinking about it: debugging valgrind with itself, is that possi=
ble?=20
:-)
Salut,
Bastien
--=20
-- The universe has its own cure for stupidity. --
-- Unfortunately, it doesn't always apply it. --
|
|
From: Luke H.
|
>The reason for this is that I have a program with sockets and threads >that works fine in 1.0.4 but has problems in 1.9.4. I haven't tried >1.9.5 yet. No luck with 1.9.5 or 1.0.4 I'm afraid. It does appear that the stack gets smashed (see below) when siglongjmp()/sigsetjmp() are called: (gdb) bt #0 vg_do_syscall2 (syscallno=1074473960, arg1=1073822720, arg2=0) at vg_mylibc.c:76 #1 0x00000004 in ?? () #2 0x40064136 in vgPlain_main () at vg_main.c:1173 (gdb) And that this is potentially the problem. -- Luke -- Luke Howard | PADL Software Pty Ltd | www.padl.com |
|
From: David E. <da...@2g...> - 2003-04-10 10:21:27
|
On Thu, 2003-04-10 at 12:14, Luke Howard wrote: > >What valgrind version are you using? > > 1.9.3. I will try 1.9.5 and report any improvements. May I suggeest that you also try the old 1.0.4 version. The reason for this is that I have a program with sockets and threads that works fine in 1.0.4 but has problems in 1.9.4. I haven't tried 1.9.5 yet. -- -\- David Eriksson -/- www.2GooD.nu "I personally refuse to use inferior tools because of ideology." - Linus Torvalds |
|
From: Luke H.
|
>What valgrind version are you using? 1.9.3. I will try 1.9.5 and report any improvements. -- Luke -- Luke Howard | PADL Software Pty Ltd | www.padl.com |
|
From: David E. <da...@2g...> - 2003-04-10 10:12:51
|
On Thu, 2003-04-10 at 11:56, Luke Howard wrote: > I'm attempting to run valgrind on a DCE RPC server. The problem is > that, while under valgrind, the server doesn't seem to receive any > client requests. It does work normally, of course, but there are > a couple of bugs for which valgrind will be very useful in fixing. What valgrind version are you using? -- -\- David Eriksson -/- www.2GooD.nu "I personally refuse to use inferior tools because of ideology." - Linus Torvalds |
|
From: Luke H.
|
I'm attempting to run valgrind on a DCE RPC server. The problem is
that, while under valgrind, the server doesn't seem to receive any
client requests. It does work normally, of course, but there are
a couple of bugs for which valgrind will be very useful in fixing.
There are some interesting aspects of the DCE RPC runtime that,
while not necessarily related to this problem, may give valgrind
some grief. The RPC library does the following "weird" things:
o wraps the pthread API to provide POSIX Threads Draft
4 API semantics (however, the symbols do not conflict
with LinuxThreads)
o wraps common system calls with jackets that enable
asynchronous thread cancellation for the duration of
the system call
o implements exception handling on top of setjmp()/longjmp()
and pthread cancels (see below):
/*
* Note that the rough schema for the exception handler is:
*
* do {
* pthread_cleanup_push("routine that will longjmp back here");
* val = setjmp(...);
* if (val == 0)
* ...normal code...
* else
* ...exception code...
* ...finally code...
* if ("exception happened")
* if ("exception handled")
* break;
* else
* ...re-raise exception...
* pthread_cleanup_pop(...);
* } while (0);
*
* Exceptions are raised by doing a pthread_cancel against one's self
* and then doing a pthread_testcancel. This causes the topmost cleanup
* routine to be popped and called. This routine (_exc_cleanup_handler)
* longjmp's back to the exception handler. This approach means we can
* leverage off the fact that the push/pop routines are maintaining some
* per-thread state (hopefully [but likely not] more efficiently than
* we could ourselves). We need this state to string together the dynamic
* stack of exception handlers.
*/
Disabling the system call jackets didn't seem to help.
A backtrace of the under-valgrind server follows:
(gdb) bt
#0 0x401924a2 in vgPlain_do_syscall () from /usr/local/lib/valgrind/valgrind.so
#1 0x4052a1e2 in recvmsg (fd=9, message=0x496ca89c, flags=0) at libc_jacket.c:221
#2 0x45fd1078 in receive_packet (assoc=0x4179608c, fragbuf_p=0x496ca9e4, ovf_fragbuf_p=0x496ca9e8,
st=0x496ca9f0) at ../../../ncklib/include/comsoc_bsd.h:339
#3 0x45fcf9ea in receive_dispatch (assoc=0x4179608c) at cnrcvr.c:508
#4 0x45fcf248 in rpc__cn_network_receiver (assoc=0x4179608c) at cnrcvr.c:274
#5 0x4053254c in thread_wrapper (info=0x417961e0) at vg_libpthread.c:667
#6 0x4016c778 in do__apply_in_new_thread_bogusRA () at vg_scheduler.c:2122
Then, probably after the siglongjmp() call:
(gdb) bt
#0 vg_do_syscall2 (syscallno=1079218620, arg1=1077504048, arg2=0) at vg_mylibc.c:76
#1 0x00000004 in ?? ()
#2 0x4017eff2 in vgPlain_main () at vg_main.c:1384
(gdb)
Valgrind shows:
04/10 09:56:09 [RPC] Registered endpoint ncacn_ip_tcp:127.0.0.1[1035]
04/10 09:56:09 [RPC] Registered endpoint ncadg_ip_udp:127.0.0.1[1035]
...
==3670== valgrind's libpthread.so: KLUDGED call to: siglongjmp (cleanup handlers are ignored)
Any ideas?
cheers,
-- Luke
--
Luke Howard | PADL Software Pty Ltd | www.padl.com
|
|
From: Geoff A. <gal...@nc...> - 2003-04-10 02:27:59
|
This appears to be the same libstdc++ "memory leak" I mentioned in the = "still reachable" memory from g++'s std::string thread, which I started = on 31 March 2003. You can check the Valgrind-users archive at = http://sourceforge.net/mailarchive/forum.php?thread_id=3D1908802&forum_id= =3D32038. Note that the thread continues into April, so you'll need to = search both the March and April archives. In one of my later postings, = I give suppression files for suppressing these libstdc++ "still = reachable" messages for both gcc 2.95.2 and 3.2. Note that this is working as intended. There are a number of discussions = on this in the libstdc++ mailing list. For example, see = http://gcc.gnu.org/ml/libstdc++/2002-10/msg00038.html, = http://gcc.gnu.org/ml/libstdc++/2002-08/msg00105.html, and = http://gcc.gnu.org/ml/libstdc++/2002-10/msg00044.html. It's not = considered a bug, but rather part of a memory cache optimization. From = http://gcc.gnu.org/ml/libstdc++/2002-08/msg00105.html: Both libstdc++-v2 and libstdc++-v3 cache memory internally to greatly = aid performance yet, as far as we know, no pointers are ever lost as in = foo(). I believe there are compile options for disabling the libstdc++ memory = cache optimization if you don't like the behavior. But if you do, = expect significant performance degradation on some platforms. Geoff Alexander ----- Original Message -----=20 From: "Bastien Chevreux" <ba...@ch...> To: "valgrind users" <val...@li...> Sent: Wednesday, April 09, 2003 9:45 AM Subject: [Valgrind-users] "Reachable" memory, where's the bug (g++, STL, = valgrind)? Hello there, I have serious troubles with possible memory leaks in programs heavily using the STL. I am not able to tell whether it is a problem with the compiler, the STL or wrong valgrind output, so I'll start here before filing in a gcc bug report. One of my programs grew larger and larger without I knew why, so took valgrind to look and started building testcases to find out what was happening. I have a SuSE 8.1 distribution, that's kernel 2.4.x, glibc2.2 and gcc version 3.2 Consider this test case example: ------------------------------------------------------- #include <vector> #include <ext/hash_map> using namespace __gnu_cxx; void f1() { int n=3D42; vector<int> v; for(int i=3D0; i<1000000; i++) v.push_back(n); } int main(){ f1(); return 0; } ---------------------------------------------------------- g++ -g -o test test.C=20 and then=20 valgrind --leak-resolution=3Dhigh --num-callers=3D20 = --show-reachable=3Dyes --leak-check=3Dyes ./test I will get the following summary: ---------------------------------------------------------- =3D=3D16880=3D=3D LEAK SUMMARY: =3D=3D16880=3D=3D definitely lost: 16 bytes in 1 blocks. =3D=3D16880=3D=3D possibly lost: 0 bytes in 0 blocks. =3D=3D16880=3D=3D still reachable: 6912 bytes in 4 blocks. ---------------------------------------------------------- The number which troubles me ist the bytes that are still reachable. Here's, the detail: ---------------------------------------------------------- =3D=3D19169=3D=3D 6848 bytes in 3 blocks are still reachable in loss = record 3 of 3 =3D=3D19169=3D=3D at 0x4015DE3B: __builtin_new (vg_clientfuncs.c:129) =3D=3D19169=3D=3D by 0x4015DE76: operator new(unsigned) = (vg_clientfuncs.c:142) =3D=3D19169=3D=3D by 0x40278E00: std::__default_alloc_template<true, = 0>::_S_chunk_alloc(unsigned, int&) (in /usr/lib/libstdc++.so.5.0.0) =3D=3D19169=3D=3D by 0x40278D1C: std::__default_alloc_template<true, = 0>::_S_refill(unsigned) (in /usr/lib/libstdc++.so.5.0.0) =3D=3D19169=3D=3D by 0x402788EF: std::__default_alloc_template<true, = 0>::allocate(unsigned) (in /usr/lib/libstdc++.so.5.0.0) =3D=3D19169=3D=3D by 0x8049008: std::__simple_alloc<int, = std::__default_alloc_template<true, 0> >::allocate(unsigned) = (/usr/include/g++/bits/stl_alloc.h:224) =3D=3D19169=3D=3D by 0x8048D7E: std::_Vector_alloc_base<int, = std::allocator<int>, true>::_M_allocate(unsigned) = (/usr/include/g++/bits/stl_vector.h:121) =3D=3D19169=3D=3D by 0x8048A45: std::vector<int, std::allocator<int> = >::_M_insert_aux(__gnu_cxx::__normal_iterator<int*, std::vector<int, = std::allocator<int> > >, int const&) = (/usr/include/g++/bits/stl_vector.h:898) =3D=3D19169=3D=3D by 0x804884C: std::vector<int, std::allocator<int> = >::push_back(int const&) (/usr/include/g++/bits/stl_vector.h:496) =3D=3D19169=3D=3D by 0x80486A1: f1() (test2.C:10) =3D=3D19169=3D=3D by 0x80487A2: main (test2.C:21) =3D=3D19169=3D=3D by 0x403094A1: __libc_start_main (in = /lib/libc.so.6) =3D=3D19169=3D=3D by 0x8048580: (within = /home/bach/work/assembly/htga/src/progs/test) ---------------------------------------------------------- Regarding the program above, I sincerely do think that there should be no leak at all, even not in "reachable" parts. Now, a few bytes don't hurt. Unfortunately, when I let run my real program, here's what I get (for really small data sets): ---------------------------------------------------------- =3D=3D698=3D=3D LEAK SUMMARY: =3D=3D698=3D=3D definitely lost: 24825 bytes in 3492 blocks. =3D=3D698=3D=3D possibly lost: 1398 bytes in 3 blocks. =3D=3D698=3D=3D still reachable: 1125492 bytes in 65 blocks. ---------------------------------------------------------- (please note that I don't care about the that the definitely and possibly lost numbers, these I can trace back to real oversights in my code.) The "still reachable" 1M number is about 40 times greater than the other two numbers added together and I have the distinct impression that the memory is really eaten away somewhere:=20 1) all valgrind detail messages are more or less similar to the one of the test case above, all have something to do with containers 2) putting a "while(1)" loop at a distinctive point in my program where everything should have been more or less freed after some heavy computation (using about any existing STL container type that exists with dozens of different classes) gives me remaining memory footprints of >1G (yes, that's gigabyte). Now my question: any idea where to start searching? is valgrind at fault (which I don't think, but one never knows)? the gnu STL? the gnu g++ compiler? Any suggestion welcome.=20 Regards, Bastien --=20 -- The universe has its own cure for stupidity. -- -- Unfortunately, it doesn't always apply it. -- ------------------------------------------------------- This SF.net email is sponsored by: Etnus, makers of TotalView, The = debugger=20 for complex code. Debugging C/C++ programs can leave you feeling lost = and=20 disoriented. TotalView can help you find your way. Available on major = UNIX=20 and Linux platforms. Try it free. www.etnus.com _______________________________________________ Valgrind-users mailing list Val...@li... https://lists.sourceforge.net/lists/listinfo/valgrind-users |