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
|
|
From: <cha...@ya...> - 2003-04-11 20:15:14
|
Hi, Im wondering if its possible to cachegrind to periodically dump a partial cachegrind.out file, so one can check the profile statistics without finishing the application Greetings ------------ ¡Internet GRATIS es Yahoo! Conexión! Usuario "yahoo", contraseña "yahoo". Desde Buenos Aires, 4004-1010. Otras ciudades: http://conexion.yahoo.com.ar/avanzados.html |
|
From: Mathieu M. <Mat...@cr...> - 2003-04-11 17:31:42
|
Hi all, Once again I'll start by saying that I am a newbie and please bear with me...blabla Ok now I introduced myself ;) I have two questions: 1. What does : "valgrind's libpthread.so: KLUDGED call to: pthread_cond_destroy" means ? I wasn't able to translate KLUDGED ... 2. And what does " Syscall param writev(vector[...]) contains uninitialised or unaddressable byte(s) at 0x40237951: my_do_syscall3 (vg_libpthread.c:2389) by 0x40236BA8: vgIntercept_writev (vg_libpthread.c:2055) by 0x4017BF68: __writev (vg_intercept.c:287) by 0x43246B45: (within /usr/X11R6/lib/libX11.so.6.2) Address 0x413C7FD8 is 124 bytes inside a block of size 2048 alloc'd at 0x40165F4D: calloc (vg_clientfuncs.c:242) by 0x4321D6FE: XOpenDisplay (in /usr/X11R6/lib/libX11.so.6.2) by 0x430BEB12: gdk_init_check (in /usr/lib/libgdk-1.2.so.0.9.1) by 0x42EC3CA1: gtk_init_check (in /usr/lib/libgtk-1.2.so.0.9.1)" means ? Please note that this message isn't shown if I start my app with option '--sync', which mean that X whill be started in synchronize mode : XSynchronize(display,True). If this sole message doesn't give any clue on what the problem is, could someone told me what to do then (use gtk debug lib, X debug lib -if such beast exists-, ...) I was running valgrind on my linux box with lastest nvidia driver with the following command line: __GL_FORCE_GENERIC_CPU=1 valgrind -v --leak-check=yes python2.2 wxMyApp.py thanks, mathieu Ps: I am trying to debug an app that works perfectly if using '--sync' option but freeze my X session if started without '--sync' option. -- Mathieu Malaterre CREATIS 28 Avenue du Doyen LEPINE B.P. Lyon-Montchat 69394 Lyon Cedex 03 http://www.creatis.insa-lyon.fr/~malaterre/ |
|
From: Lennert B. <bu...@gn...> - 2003-04-11 14:29:00
|
(Please CC on replies, I'm not on the list.)
SIOCOUTQ is an ioctl that, when called on a socket, returns the number
of bytes currently in that socket's send buffer. It writes this value
as an int to the memory location indicated by the third argument of
ioctl(2).
Below is a trvial patch that implements support for this ioctl, and
corrects some text in README_MISSING_SYSCALL_OR_IOCTL.
diff -urN valgrind-1.9.5-orig/README_MISSING_SYSCALL_OR_IOCTL valgrind-1.9.5/README_MISSING_SYSCALL_OR_IOCTL
--- valgrind-1.9.5-orig/README_MISSING_SYSCALL_OR_IOCTL Fri Mar 22 02:29:21 2002
+++ valgrind-1.9.5/README_MISSING_SYSCALL_OR_IOCTL Fri Apr 11 16:10:39 2003
@@ -12,7 +12,7 @@
there's not a lot of need to distinguish them (at least conceptually)
in the discussion that follows.
-All this machinery is in vg_syscall_mem.c.
+All this machinery is in coregrind/vg_syscalls.c.
What are syscall/ioctl wrappers? What do they do?
@@ -141,12 +141,6 @@
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Is pretty much the same as writing syscall wrappers.
-If you can't be bothered, do a cheap hack: add it (the ioctl number
-emitted in Valgrind's panic-message) to the long list of IOCTLs which
-are noted but not fully handled by Valgrind (search for the text
-"noted but unhandled ioctl" in vg_syscall_mem.c). This will get you
-going immediately, at the risk of giving you spurious value errors.
-
As above, please do send me the resulting patch.
diff -urN valgrind-1.9.5-orig/coregrind/vg_syscalls.c valgrind-1.9.5/coregrind/vg_syscalls.c
--- valgrind-1.9.5-orig/coregrind/vg_syscalls.c Fri Apr 4 00:44:27 2003
+++ valgrind-1.9.5/coregrind/vg_syscalls.c Fri Apr 11 16:13:41 2003
@@ -2010,7 +2010,7 @@
arg3, sizeof(int) );
KERNEL_DO_SYSCALL(tid,res);
break;
- case FIONREAD:
+ case FIONREAD: /* identical to SIOCINQ */
SYSCALL_TRACK( pre_mem_write, tst, "ioctl(FIONREAD)",
arg3, sizeof(int) );
KERNEL_DO_SYSCALL(tid,res);
@@ -2152,6 +2152,13 @@
if (!VG_(is_kerror)(res) && res == 0)
VG_TRACK( post_mem_write,arg3, sizeof(struct timeval));
break;
+ case SIOCOUTQ:
+ SYSCALL_TRACK( pre_mem_write,tst, "ioctl(SIOCOUTQ)", arg3,
+ sizeof(int));
+ KERNEL_DO_SYSCALL(tid,res);
+ if (!VG_(is_kerror)(res) && res == 0)
+ VG_TRACK( post_mem_write,arg3, sizeof(int));
+ break;
case SIOCGRARP: /* get RARP table entry */
case SIOCGARP: /* get ARP table entry */
SYSCALL_TRACK( pre_mem_write,tst, "ioctl(SIOCGARP)", arg3,
diff -urN valgrind-1.9.5-orig/coregrind/vg_unsafe.h valgrind-1.9.5/coregrind/vg_unsafe.h
--- valgrind-1.9.5-orig/coregrind/vg_unsafe.h Sat Oct 5 17:18:27 2002
+++ valgrind-1.9.5/coregrind/vg_unsafe.h Fri Apr 11 16:13:58 2003
@@ -41,6 +41,7 @@
#include <sys/resource.h> /* for struct rlimit */
#include <linux/shm.h> /* for struct shmid_ds & struct ipc_perm */
#include <sys/socket.h> /* for struct msghdr */
+#include <linux/sockios.h> /* for SIOCOUTQ */
#include <sys/un.h> /* for sockaddr_un */
#include <net/if.h> /* for struct ifreq et al */
#include <net/if_arp.h> /* for struct arpreq */
|
|
From: Nicholas N. <nj...@ca...> - 2003-04-11 10:45:59
|
On Thu, 10 Apr 2003, Xiang Yan wrote:
> 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
Not quite, but there is this option:
--logfile-fd=<number> file descriptor for messages [2=stderr]
N
|
|
From: Julian S. <js...@ac...> - 2003-04-11 07:33:21
|
The non-working of valgrind with nvidia drivers might go away when
we finally get around to implementing SSE/SSE2 instructions, which
we hope will happen soon.
However, NVidia also noticed this it seems, and the "latest" drivers
(don't ask me what version, I don't use them) come with this text
DISABLING CPU SPECIFIC FEATURES
Setting the environment variable __GL_FORCE_GENERIC_CPU to a
non-zero value will inhibit the use of CPU specific features
such as MMX, SSE, or 3DNOW!. Use of this option may result in
performance loss. This option may be useful in conjunction with
software such as the Valgrind memory debugger.
__GL_FORCE_GENERIC_CPU=1 valgrind ... whatever ...
apparently does work. Great stuff. Ah yes, version 4349 according
to Sylvain's just-arrived message.
J
On Friday 11 April 2003 5:36 am, Paul Cheyrou-lagreze wrote:
> I use both on the same linux system :
>
> 1. install latest nvidia driver
> 2. download Mesa source from mesa3d.org
> 3. compile and install Mesa from sources (make install should install it in
> /usr/local/lib/) (if you're coding some opengl try configure --enable-warn
> --enable-trace, you'll get some VERY useful information)
>
> Then, when you want to use Mesa,
> just launch a shell command
> export LD_LIBRARY_PATH=/usr/local/lib
> and launch apps. (Valgrind included)
>
> When you want to use hardware opengl,
> export LD_LIBRARY_PATH=
>
> Then you can test code with both, and debug with Mesa, wich is easier.
>
> -Paul
>
>
>
> -------------------------------------------------------
> 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: Sylvain J. <syl...@m4...> - 2003-04-11 07:27:41
|
You can disable the use of MMX/SSE/whatever in the latest nvidia driver=20 (4349) by setting the __GL_FORCE_GENERIC_CPU environment variable to a=20 non-zero value =46rom the readme: DISABLING CPU SPECIFIC FEATURES Setting the environment variable __GL_FORCE_GENERIC_CPU to a non-zero value will inhibit the use of CPU specific features such as MMX, SSE, or 3DNOW!. Use of this option may result in performance loss. This option may be useful in conjunction with software such as the Valgrind memory debugger. =2D-=20 Sylvain Joyeux |
|
From: Paul Cheyrou-l. <Pau...@in...> - 2003-04-11 05:36:48
|
I use both on the same linux system : 1. install latest nvidia driver 2. download Mesa source from mesa3d.org 3. compile and install Mesa from sources (make install should install it in /usr/local/lib/) (if you're coding some opengl try configure --enable-warn --enable-trace, you'll get some VERY useful information) Then, when you want to use Mesa, just launch a shell command export LD_LIBRARY_PATH=/usr/local/lib and launch apps. (Valgrind included) When you want to use hardware opengl, export LD_LIBRARY_PATH= Then you can test code with both, and debug with Mesa, wich is easier. -Paul |
|
From: Paul H. <pa...@ha...> - 2003-04-11 00:08:11
|
My company bought a new Linux system so I can run valgrind faster. The purchasing department doesn't understand Linux, so it came with Windows XP installed and a high end Nvidia graphics card. Getting rid of Windows XP was easy, but I think I'm stuck with the Nvidia card. The "nv" driver mostly works, but text was getting messed up when xterms scrolled. So I tried the drivers from Nvidia. Now my xterms worked, but valgrind stopped working. As many are painfully aware, the problem isn't the hardware, it is the drivers. Specifically it's /usr/lib/libGL.so.1.0.4349 and libraries it pulls in. My system is mostly Debian unstable. After foolishly installing the Nvidia drivers, I got valgrind to work again by typing: apt-get install --reinstall xlibmesa3-gl This puts back the /usr/X11R6/lib/libGL.so.1.2 that the Nvidia install script removed. The nvidia stuff is libGL.so.1.0 and the mesa3-gl is .1.2, so I can probably play with version numbers to get either library. The mesa library is fast enough for me, since I spend far more time working on the CAD program than I do actually running the CAD program with large models. Most importantly, my xterms don't get messed up when I scroll them. I've tried valgrind 1.0.4, 1.9.5 and the CVS tip (why does it call itself 1.9.4?), and they all work on this somewhat bastardized OpenGL configuration. Performance with the Mesa libGL and the "nvidia" driver is much better than it was with the "nv" driver. (That might just mean I screwed up the "nv" driver configuration.) I spent some time playing with LD_LIBRARY_PATH to get different libraries, this worked, but it looked like I'd have to spend time maintaining multiple suppression files, since our older Linux systems aren't cursed with the Nvidia hardware. -- Paul Haas, paulh@Hamjudo.com |
|
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 |