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
(4) |
2
(6) |
3
(4) |
4
(5) |
5
(8) |
6
(7) |
7
(2) |
|
8
(1) |
9
|
10
(5) |
11
(5) |
12
(5) |
13
(9) |
14
(11) |
|
15
(3) |
16
(3) |
17
(10) |
18
(7) |
19
(2) |
20
|
21
(3) |
|
22
|
23
(1) |
24
(25) |
25
(3) |
26
(7) |
27
(3) |
28
|
|
29
(10) |
|
|
|
|
|
|
|
From: Tom H. <th...@cy...> - 2004-02-12 07:18:53
|
In message <107...@id...>
Jean-Marc Valin <Jean-Marc.Valin@USherbrooke.ca> wrote:
> I'm getting the following error while running my program with valgrind
> 2.0.0:
> disInstr: unhandled instruction bytes: 0xF3 0xF 0x52 0xC9
>
> I suspect it's probably SSE related, since I'm using an SSE version of
> FFTW (note that the program runs fine without valgrind). I'm running
> Fedoda Core 1 on a Pentium-M and kernel 2.6.2-mm1.
It's RSQRTSS and it is implemented in the CVS head version of valgrind.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Jean-Marc V.
|
Hi, I'm getting the following error while running my program with valgrind 2.0.0: disInstr: unhandled instruction bytes: 0xF3 0xF 0x52 0xC9 I suspect it's probably SSE related, since I'm using an SSE version of FFTW (note that the program runs fine without valgrind). I'm running Fedoda Core 1 on a Pentium-M and kernel 2.6.2-mm1. Jean-Marc --=20 Jean-Marc Valin, M.Sc.A., ing. jr. LABORIUS (http://www.gel.usherb.ca/laborius) Universit=E9 de Sherbrooke, Qu=E9bec, Canada |
|
From: Nicholas N. <nj...@ca...> - 2004-02-11 22:45:59
|
On Tue, 10 Feb 2004, Stephane Donze wrote: > I guess it would be possible in the memcheck skin to record mutex usage > and report them in the leak summary ? Sure, it's possible. You'd have to track mutexes in the same way that heap blocks are tracked; you could probably reuse a lot of the heap-block-tracking machinery. Patches are welcome :) N |
|
From: Nicholas N. <nj...@ca...> - 2004-02-11 12:01:19
|
On Tue, 10 Feb 2004, Alex Ivershen wrote: > I have a problem using vgprof skin for performance profiling. To be > exact, I can't use it at all :) > I downloaded vgpfor binary from Jeremy's website, and tried to follw the > instructions: > > "The basic form is: valgrind --skin=vgprof program" > > Invocation of Valgrind with this skin yields "The shared library > vgskin_vgprof.so for the chosen skin cannot be found". > And of course it can't ... because I don't have it. What am I missing > here? Any hints from people who did run vgprof successfully? It's confusing: the name of the skin is "vgprof", the name of the patched version of gprof that works with vgprof's output is "VGProf". You would have downloaded VGProf, but not the patch for vgprof, if that makes sense. I just updated valgrind.kde.org/related.html, which might make it a little clearer. N |
|
From: Tom H. <th...@cy...> - 2004-02-11 09:58:23
|
In message <Pin...@ye...>
Nicholas Nethercote <nj...@ca...> wrote:
> On Wed, 11 Feb 2004, Tom Hughes wrote:
>
>> I wonder if system is implemented using vfork rather than fork?
>>
>> The NPTL C library implements fork using clone, and as part of
>> the NPTL/TLS changes I made valgrind handle that, but it may be
>> that vfork is also being done using clone with slightly different
>> flags and valgrind isn't catching that.
>>
>> Try stracing the test program without valgrind and see what
>> system calls the system() is doing.
>
> Full trace attached. The interesting bit is:
OK. It isn't vfork as such, it's a custom fork that system uses...
If you look at sysdeps/unix/sysv/linux/system.c in a recent glibc you
will see that it defines FORK() before including the generic version
of the system() code. That version of FORK() actually uses clone with
the CLONE_PARENT_SETTID flag to get the value of the child's PID in
a variable in the parent for cancellation.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2004-02-11 00:11:42
|
On Wed, 11 Feb 2004, Tom Hughes wrote:
> > Very strange -- a trivial system() is tripping Valgrind up on my machine,
> > yet this is the first I've seen of it on the current HEAD?
>
> I wonder if system is implemented using vfork rather than fork?
>
> The NPTL C library implements fork using clone, and as part of
> the NPTL/TLS changes I made valgrind handle that, but it may be
> that vfork is also being done using clone with slightly different
> flags and valgrind isn't catching that.
>
> Try stracing the test program without valgrind and see what
> system calls the system() is doing.
Full trace attached. The interesting bit is:
rt_sigaction(SIGINT, {SIG_IGN}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGQUIT, {SIG_IGN}, {SIG_DFL}, 8) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
clone(child_stack=0, flags=CLONE_PARENT_SETTID|0x11, [7814], <ignored>) = 7814
wait4(7814, [WIFEXITED(s) && WEXITSTATUS(s) == 0], 0, NULL) = 7814
rt_sigaction(SIGINT, {SIG_DFL}, NULL, 8) = 0
rt_sigaction(SIGQUIT, {SIG_DFL}, NULL, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
--- SIGCHLD (Child exited) @ 0 (0) ---
exit_group(0) = ?
Um, hmm.
N |
|
From: Tom H. <th...@cy...> - 2004-02-11 00:02:09
|
In message <Pin...@ye...>
Nicholas Nethercote <nj...@ca...> wrote:
> Just to add to the confusion, I tried that program and get:
>
> ==31559== Valgrind detected that your program requires
> ==31559== the following unimplemented functionality:
> ==31559== clone(): not supported by Valgrind.
> We do now support programs linked against
> libpthread.so, though. Re-run with -v and ensure that
> you are picking up Valgrind's implementation of libpthread.so.
>
> valgrind: CVS HEAD.
> kernel: 2.4.20-24.9
> glibc: stable 2.3.2
> gcc: 3.2.2
>
> Current Valgrind 2.0.0 branch works ok.
>
> Very strange -- a trivial system() is tripping Valgrind up on my machine,
> yet this is the first I've seen of it on the current HEAD?
I wonder if system is implemented using vfork rather than fork?
The NPTL C library implements fork using clone, and as part of
the NPTL/TLS changes I made valgrind handle that, but it may be
that vfork is also being done using clone with slightly different
flags and valgrind isn't catching that.
Try stracing the test program without valgrind and see what
system calls the system() is doing.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2004-02-10 22:24:16
|
On Tue, 10 Feb 2004, Patrick Ohly wrote:
> [ assert ksigismember ]
> > Here is a test program I wrote to produce the above error:
> >
> > int main ()
> > {
> > printf ("Hello World\n");
> > system ("ls >/tmp/junk");
> > }
>
> For all that it's worth: I got the same error in my
> own application and can reproduce it with this test
> program.
>
> valgrind version: valgrind-2.1.0
> Linux distribution: Red Hat 7.3 (modified)
> Kernel version: 2.4.9-xxx
> glibc version: gcc version 2.96
Just to add to the confusion, I tried that program and get:
==31559== Valgrind detected that your program requires
==31559== the following unimplemented functionality:
==31559== clone(): not supported by Valgrind.
We do now support programs linked against
libpthread.so, though. Re-run with -v and ensure that
you are picking up Valgrind's implementation of libpthread.so.
valgrind: CVS HEAD.
kernel: 2.4.20-24.9
glibc: stable 2.3.2
gcc: 3.2.2
Current Valgrind 2.0.0 branch works ok.
Very strange -- a trivial system() is tripping Valgrind up on my machine,
yet this is the first I've seen of it on the current HEAD?
N
|
|
From: Alex I. <ale...@in...> - 2004-02-10 19:06:36
|
Hi all, I have a problem using vgprof skin for performance profiling. To be exact, I can't use it at all :) I downloaded vgpfor binary from Jeremy's website, and tried to follw the instructions: "The basic form is: valgrind --skin=vgprof program" Invocation of Valgrind with this skin yields "The shared library vgskin_vgprof.so for the chosen skin cannot be found". And of course it can't ... because I don't have it. What am I missing here? Any hints from people who did run vgprof successfully? Thanks! Alex ------------------------------------------------------------------------ Confidentiality Notice: This e-mail transmission may contain confidential and/or privileged information that is intended only for the individual or entity named in the e-mail address. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or reliance upon the contents of this e-mail message is strictly prohibited. If you have received this e-mail transmission in error, please reply to the sender, so that proper delivery can be arranged, and please delete the message from your computer. Thank you. Inet Technologies, Inc. ------------------------------------------------------------------------ |
|
From: Patrick O. <Pat...@in...> - 2004-02-10 15:52:22
|
On Mon, 2004-01-12 at 22:45, Lee, Tim wrote:
[ assert ksigismember ]
> Here is a test program I wrote to produce the above error:
>
> int main ()
> {
> printf ("Hello World\n");
> system ("ls >/tmp/junk");
> }
For all that it's worth: I got the same error in my
own application and can reproduce it with this test
program.
valgrind version: valgrind-2.1.0
Linux distribution: Red Hat 7.3 (modified)
Kernel version: 2.4.9-xxx
glibc version: gcc version 2.96
I found that disabling the two asserts in
vg_async_signalhandler() allowed valgrind to
proceed, without any apparent problems so far.
--
Best Regards
Patrick Ohly
Senior Software Engineer
Intel GmbH
Software & Solutions Group
Hermuelheimer Strasse 8a
50321 Bruehl
Germany
Tel: +49-2232-2090-30
Fax: +49-2232-2090-29
|
|
From: Stephane D. <ste...@ex...> - 2004-02-10 14:10:22
|
Hi guys,
I just spent a few days chasing a very strange memory leak that seemed
to be invisible to valgrind's sharp eyes. Actually, the program was not
leaking on Linux platform, but the same code on a Tru64 machine leaked a
few hundreds of bytes per HTTP query. The leak was in fact not a memory
leak, but a mutex leak that has completely different behaviours
depending on the OS thread implementation. On Tru64 UNIX, there is a
malloc() hidden in the pthread_mutex_init call, thus resulting in a
memory leak.
When I run the following program under valgrind, he (or she ? :-) )
doesn't complain about anything:
#include <stdio.h>
#include <pthread.h>
int main(int argc, char* argv[]) {
pthread_mutex_t mutex;
int i;
for (i = 0; i < 1000; i++) {
pthread_mutex_init(&mutex, NULL);
}
}
marj$ valgrind ./foo
==14611== Memcheck, a.k.a. Valgrind, a memory error detector for
x86-linux.
==14611== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward.
==14611== Using valgrind-20031012, a program supervision framework for
x86-linux.
==14611== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward.
==14611== Estimated CPU clock rate is 1800 MHz
==14611== For more details, rerun with: -v
==14611==
==14611==
==14611== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==14611== malloc/free: in use at exit: 0 bytes in 0 blocks.
==14611== malloc/free: 0 allocs, 0 frees, 0 bytes allocated.
==14611== For a detailed leak analysis, rerun with: --leak-check=yes
==14611== For counts of detected errors, rerun with: -v
I guess it would be possible in the memcheck skin to record mutex usage
and report them in the leak summary ?
Regards,
Stephane
|
|
From: Leonard m. <spa...@ya...> - 2004-02-10 01:27:02
|
--- Mathieu Malaterre <mat...@ki...> wrote:
> Same here ! the display is fine, but if I hit a key ('q' to
> quit the app), then after about 20s the whole machine locks.
>
> BTW I was able to open the display, render my 3d structure, and
> quit without problem, the sole difference was that I didn't
> had to hit any key to close. So my guess is now this is a
> mixture of: keyborad event
Well, I can say with pretty high confidence that it has nothing to do
with the keyboard. Our app won't even come up and start rendering,
whether I touch the keyboard or not. It just locks the whole machine
hard.
Could you trace down what your app is doing in response to that key?
Maybe its touching some kernel sysctl or driver API call that's causing
valgrind to lose its mind.
__________________________________
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.
http://taxes.yahoo.com/filing.html
|
|
From: Olly B. <ol...@su...> - 2004-02-08 00:10:53
|
On Fri, Feb 06, 2004 at 04:35:00PM -0600, Watts, Mark wrote:
> It's not obvious to me..... I don't know what the problem with memmove is
> since the man page says it should handle overlaps and at this stage it
> is a simple malloc of two spaces and a memmove between them.
You're trying to copy 21 bytes from a block of size 10 to one of size
21 (the value of size is 21 by the time memmove is called). That means
memmove reads past the end of the block it's reading from.
Cheers,
Olly
|
|
From: Watts, M.
|
It's not obvious to me..... I don't know what the problem with memmove =
is
since the man page says it should handle overlaps and at this stage it
is a simple malloc of two spaces and a memmove between them.
Any help would be greatly appreciated.
[----------------------- source listing ------------------------------]
#include <unistd.h>
#include <string.h>
#include <malloc.h>
#define ADD_ON_SIZE 10
#define INITIAL_SIZE 11
size_t size =3D INITIAL_SIZE;
int main(int argc, char **argv)
{
int index_ctr =3D 0;
void * ptr1 =3D (void *) NULL;
void * ptr2 =3D (void *) NULL;
ptr1 =3D malloc(size);
size +=3D ADD_ON_SIZE;
ptr2 =3D malloc(size);
ptr2 =3D memmove(ptr2,ptr1,size);
free (ptr2);
free (ptr1);
return 0;
}
$ valgrind ./t_malloc=20
=3D=3D5879=3D=3D Memcheck, a.k.a. Valgrind, a memory error detector for =
x86-linux.
=3D=3D5879=3D=3D Copyright (C) 2002-2003, and GNU GPL'd, by Julian =
Seward.
=3D=3D5879=3D=3D Using valgrind-20030725, a program supervision =
framework for x86-linux.
=3D=3D5879=3D=3D Copyright (C) 2000-2003, and GNU GPL'd, by Julian =
Seward.
=3D=3D5879=3D=3D Estimated CPU clock rate is 1398 MHz
=3D=3D5879=3D=3D For more details, rerun with: -v
=3D=3D5879=3D=3D=20
=3D=3D5879=3D=3D Invalid read of size 1
=3D=3D5879=3D=3D at 0x402CDE2A: memmove =
(../sysdeps/generic/memmove.c:79)
=3D=3D5879=3D=3D by 0x8048535: main (in =
/share/systems/views/garedman/garedman_linux_ehs/.s/00053/80003c634015a64=
et_malloc)
=3D=3D5879=3D=3D by 0x40261686: __libc_start_main =
(../sysdeps/generic/libc-start.c:129)
=3D=3D5879=3D=3D by 0x80483F0: (within =
/share/systems/views/garedman/garedman_linux_ehs/.s/00053/80003c634015a64=
et_malloc)
=3D=3D5879=3D=3D Address 0x4146002F is 0 bytes after a block of size =
11 alloc'd
=3D=3D5879=3D=3D at 0x4002B944: malloc (vg_replace_malloc.c:153)
=3D=3D5879=3D=3D by 0x80484F8: main (in =
/share/systems/views/garedman/garedman_linux_ehs/.s/00053/80003c634015a64=
et_malloc)
=3D=3D5879=3D=3D by 0x40261686: __libc_start_main =
(../sysdeps/generic/libc-start.c:129)
=3D=3D5879=3D=3D by 0x80483F0: (within =
/share/systems/views/garedman/garedman_linux_ehs/.s/00053/80003c634015a64=
et_malloc)
=3D=3D5879=3D=3D=20
=3D=3D5879=3D=3D ERROR SUMMARY: 10 errors from 1 contexts (suppressed: 0 =
from 0)
=3D=3D5879=3D=3D malloc/free: in use at exit: 0 bytes in 0 blocks.
=3D=3D5879=3D=3D malloc/free: 2 allocs, 2 frees, 32 bytes allocated.
=3D=3D5879=3D=3D For a detailed leak analysis, rerun with: =
--leak-check=3Dyes
=3D=3D5879=3D=3D For counts of detected errors, rerun with: -v
------ gory details run.....
$ valgrind -v ./t_malloc
=3D=3D5915=3D=3D Memcheck, a.k.a. Valgrind, a memory error detector for =
x86-linux.
=3D=3D5915=3D=3D Copyright (C) 2002-2003, and GNU GPL'd, by Julian =
Seward.
=3D=3D5915=3D=3D Using valgrind-20030725, a program supervision =
framework for x86-linux.
=3D=3D5915=3D=3D Copyright (C) 2000-2003, and GNU GPL'd, by Julian =
Seward.
=3D=3D5915=3D=3D Startup, with flags:
=3D=3D5915=3D=3D =
--suppressions=3D/usr/local/lib/valgrind/default.supp
=3D=3D5915=3D=3D -v
=3D=3D5915=3D=3D Reading syms from =
/share/systems/views/garedman/garedman_linux_ehs/.s/00053/80003c634015a64=
et_malloc
=3D=3D5915=3D=3D Reading syms from /lib/ld-2.2.4.so
=3D=3D5915=3D=3D Reading syms from =
/usr/local/lib/valgrind/vgskin_memcheck.so
=3D=3D5915=3D=3D Reading syms from /usr/local/lib/valgrind/valgrind.so
=3D=3D5915=3D=3D Reading syms from /lib/i686/libc-2.2.4.so
=3D=3D5915=3D=3D Reading suppressions file: =
/usr/local/lib/valgrind/default.supp
=3D=3D5915=3D=3D Estimated CPU clock rate is 1399 MHz
=3D=3D5915=3D=3D=20
=3D=3D5915=3D=3D Invalid read of size 1
=3D=3D5915=3D=3D at 0x402CDE2A: memmove =
(../sysdeps/generic/memmove.c:79)
=3D=3D5915=3D=3D by 0x8048535: main (in =
/share/systems/views/garedman/garedman_linux_ehs/.s/00053/80003c634015a64=
et_malloc)
=3D=3D5915=3D=3D by 0x40261686: __libc_start_main =
(../sysdeps/generic/libc-start.c:129)
=3D=3D5915=3D=3D by 0x80483F0: (within =
/share/systems/views/garedman/garedman_linux_ehs/.s/00053/80003c634015a64=
et_malloc)
=3D=3D5915=3D=3D Address 0x4146002F is 0 bytes after a block of size =
11 alloc'd
=3D=3D5915=3D=3D at 0x4002B944: malloc (vg_replace_malloc.c:153)
=3D=3D5915=3D=3D by 0x80484F8: main (in =
/share/systems/views/garedman/garedman_linux_ehs/.s/00053/80003c634015a64=
et_malloc)
=3D=3D5915=3D=3D by 0x40261686: __libc_start_main =
(../sysdeps/generic/libc-start.c:129)
=3D=3D5915=3D=3D by 0x80483F0: (within =
/share/systems/views/garedman/garedman_linux_ehs/.s/00053/80003c634015a64=
et_malloc)
=3D=3D5915=3D=3D=20
=3D=3D5915=3D=3D ERROR SUMMARY: 10 errors from 1 contexts (suppressed: 0 =
from 0)
=3D=3D5915=3D=3D=20
=3D=3D5915=3D=3D 10 errors in context 1 of 1:
=3D=3D5915=3D=3D Invalid read of size 1
=3D=3D5915=3D=3D at 0x402CDE2A: memmove =
(../sysdeps/generic/memmove.c:79)
=3D=3D5915=3D=3D by 0x8048535: main (in =
/share/systems/views/garedman/garedman_linux_ehs/.s/00053/80003c634015a64=
et_malloc)
=3D=3D5915=3D=3D by 0x40261686: __libc_start_main =
(../sysdeps/generic/libc-start.c:129)
=3D=3D5915=3D=3D by 0x80483F0: (within =
/share/systems/views/garedman/garedman_linux_ehs/.s/00053/80003c634015a64=
et_malloc)
=3D=3D5915=3D=3D Address 0x4146002F is 0 bytes after a block of size =
11 alloc'd
=3D=3D5915=3D=3D at 0x4002B944: malloc (vg_replace_malloc.c:153)
=3D=3D5915=3D=3D by 0x80484F8: main (in =
/share/systems/views/garedman/garedman_linux_ehs/.s/00053/80003c634015a64=
et_malloc)
=3D=3D5915=3D=3D by 0x40261686: __libc_start_main =
(../sysdeps/generic/libc-start.c:129)
=3D=3D5915=3D=3D by 0x80483F0: (within =
/share/systems/views/garedman/garedman_linux_ehs/.s/00053/80003c634015a64=
et_malloc)
=3D=3D5915=3D=3D IN SUMMARY: 10 errors from 1 contexts (suppressed: 0 =
from 0)
=3D=3D5915=3D=3D=20
=3D=3D5915=3D=3D malloc/free: in use at exit: 0 bytes in 0 blocks.
=3D=3D5915=3D=3D malloc/free: 2 allocs, 2 frees, 32 bytes allocated.
=3D=3D5915=3D=3D=20
--5915-- TT/TC: 0 tc sectors discarded.
--5915-- 290 chainings, 0 unchainings.
--5915-- translate: new 736 (9572 -> 143181; ratio 149:10)
--5915-- discard 0 (0 -> 0; ratio 0:10).
--5915-- dispatch: 0 jumps (bb entries), of which 1032 (103200%) were =
unchained.
--5915-- 2/743 major/minor sched events. 736 tt_fast misses.
--5915-- reg-alloc: 60 t-req-spill, 27269+359 orig+spill uis, 3363 =
total-reg-r.
--5915-- sanity: 3 cheap, 1 expensive checks.
--5915-- ccalls: 3278 C calls, 62% saves+restores avoided (12128 =
bytes)
--5915-- 4073 args, avg 0.89 setup instrs each (820 bytes)
--5915-- 0% clear the stack (9834 bytes)
--5915-- 1191 retvals, 32% of reg-reg movs avoided (750 =
bytes)
Mark S. Watts
Huntsville Operations Support Center (HOSC)
CSC/NASA
Huntsville, AL
256-544-6165
|
|
From: Nicholas N. <nj...@ca...> - 2004-02-07 18:03:31
|
On Fri, 6 Feb 2004, Mathieu Malaterre wrote:
> > Yes, I experience exactly the same problem on programs linked with the
> > ATI libGL.so on Linux. The whole machine locks hard after about 20-30
> > seconds!
>
> Same here ! the display is fine, but if I hit a key ('q' to quit the
> app), then after about 20s the whole machine locks.
Can one of you please file a bug at bugs.kde.org/enter_valgrind_bug.cgi?
Please include as much relevant info as possible.
N
|
|
From: Mathieu M. <mat...@ki...> - 2004-02-06 20:30:34
|
> Yes, I experience exactly the same problem on programs linked with the
> ATI libGL.so on Linux. The whole machine locks hard after about 20-30
> seconds!
Same here ! the display is fine, but if I hit a key ('q' to quit the
app), then after about 20s the whole machine locks.
BTW I was able to open the display, render my 3d structure, and quit
without problem, the sole difference was that I didn't had to hit any
key to close. So my guess is now this is a mixture of: keyborad event +
ATI libGL.so + valgrind.
Comments welcome
Mathieu
|
|
From: Leonard m. <spa...@ya...> - 2004-02-06 19:36:13
|
Mathieu Malaterre: > Does anyone of you use the fglrx driver and valgrind ? I am having bad X froze. valgrind is working really fine with console type programm, and it also doing fine when using nvidia driver (on another machine with a 3d graphics program). Is there a way to track the problem ? Yes, I experience exactly the same problem on programs linked with the ATI libGL.so on Linux. The whole machine locks hard after about 20-30 seconds! I hadn't conclusively established that it was the ATI driver but I guess you have. I'll help track this as well if one of the valgrind folks can suggest a few things to try. I greatly miss being able to use valgrind on my app. Mesa hasn't caught up with the features we're using, so linking with Mesa's libGL is unfortunately not a work-around. __________________________________ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html |
|
From: Mathieu M. <mat...@ki...> - 2004-02-06 18:43:53
|
Hi all, Does anyone of you use the fglrx driver and valgrind ? I am having bad X froze. valgrind is working really fine with console type programm, and it also doing fine when using nvidia driver (on another machine with a 3d graphics program). Is there a way to track the problem ? Thanks Mathieu Using fedora, linux knl: 2.4.22-1.2115.nptlsmp $ fglrxinfo display: :0.0 screen: 0 OpenGL vendor string: ATI Technologies Inc. OpenGL renderer string: RADEON 9800 Pro x86/SSE2 OpenGL version string: 1.3 (X4.3.0-3.7.0) |
|
From: <man...@ve...> - 2004-02-06 08:53:31
|
Thanks for the replies !!! I will consider these options.
Thanks,
Mani.
"Nicholas
Nethercote" To: Manikandan X.
<nj...@ca...> Shanmugam/EMPL/India/Verizon@VZNotes
Sent by: cc: val...@li...
"Nicholas Subject: Re: [Valgrind-users] Attaching a process with
Nethercote" valgrind using process id
<nj...@he...m
.ac.uk>
02/06/04 01:36 PM
On Fri, 6 Feb 2004 man...@ve... wrote:
> * Attach a process id with valgrind, i know it is not
possible,
> just confirming it.
Correct, you cannot do it. Valgrind has to gain control at startup. If
it didn't, then eg. Memcheck wouldn't be able to work, because it couldn't
know what memory had been allocated so far, etc.
> * I have a scenario where, we have a system monitor which
> starts/initializes/monitors all the other core processes. These core
> processes cannot be started alone. They are tightly coupled with system
> monitor. Is there any way, i will be able to individually attach valgrind
> to the core process without attaching to the system monitor. I know of
the
> --trace-children option, this is not suited for our system, since it
spawns
> lot of processes in the order of hundreds.
When the system monitor spawns the core processes, can you exec them with
"valgrind x" instead of "x"?
N
|
|
From: Tom H. <th...@cy...> - 2004-02-06 08:16:03
|
In message <OF4...@co...>
manikandan x. shanmugam <man...@ve...> wrote:
> * Attach a process id with valgrind, i know it is not possible,
> just confirming it.
Indeed it isn't.
> * I have a scenario where, we have a system monitor which
> starts/initializes/monitors all the other core processes. These core
> processes cannot be started alone. They are tightly coupled with system
> monitor. Is there any way, i will be able to individually attach valgrind
> to the core process without attaching to the system monitor. I know of the
> --trace-children option, this is not suited for our system, since it spawns
> lot of processes in the order of hundreds.
You would have to either change the monitor to start the core process
in question under valgrind, or replace the executable for that process
with a shell script that started the real core process under valgrind.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2004-02-06 08:06:07
|
On Fri, 6 Feb 2004 man...@ve... wrote: > * Attach a process id with valgrind, i know it is not possible, > just confirming it. Correct, you cannot do it. Valgrind has to gain control at startup. If it didn't, then eg. Memcheck wouldn't be able to work, because it couldn't know what memory had been allocated so far, etc. > * I have a scenario where, we have a system monitor which > starts/initializes/monitors all the other core processes. These core > processes cannot be started alone. They are tightly coupled with system > monitor. Is there any way, i will be able to individually attach valgrind > to the core process without attaching to the system monitor. I know of the > --trace-children option, this is not suited for our system, since it spawns > lot of processes in the order of hundreds. When the system monitor spawns the core processes, can you exec them with "valgrind x" instead of "x"? N |
|
From: <man...@ve...> - 2004-02-06 07:21:01
|
Hi Folks,
I searched the valgrind documentation, but was not able to find the
answers for the following questions,
* Attach a process id with valgrind, i know it is not possible,
just confirming it.
* I have a scenario where, we have a system monitor which
starts/initializes/monitors all the other core processes. These core
processes cannot be started alone. They are tightly coupled with system
monitor. Is there any way, i will be able to individually attach valgrind
to the core process without attaching to the system monitor. I know of the
--trace-children option, this is not suited for our system, since it spawns
lot of processes in the order of hundreds.
Any help will be deeply appreciated,
Thanks,
Mani.
|
|
From: Jeremy F. <je...@go...> - 2004-02-05 23:31:28
|
On Thu, 2004-02-05 at 13:50, Nicholas Nethercote wrote: > On Thu, 5 Feb 2004, Jeremy Fitzhardinge wrote: > > > The check is redundant - POST(x) is never called if the syscall didn't > > succeed. > > Jeremy, can you take a look at the patch and tell me whether the > fd_allowed() call is needed in POST(epoll_create)? Thanks. fd_allowed is to check FDs as they're passed into syscalls; it shouldn't be necessary for FDs created by a syscall (ie, they should always be in a PRE(x)). J |
|
From: Nicholas N. <nj...@ca...> - 2004-02-05 21:50:28
|
On Thu, 5 Feb 2004, Jeremy Fitzhardinge wrote: > The check is redundant - POST(x) is never called if the syscall didn't > succeed. Jeremy, can you take a look at the patch and tell me whether the fd_allowed() call is needed in POST(epoll_create)? Thanks. N |
|
From: Jeremy F. <je...@go...> - 2004-02-05 10:31:15
|
On Thu, 2004-02-05 at 02:21, Nicholas Nethercote wrote: > On Thu, 5 Feb 2004, Jeremy Fitzhardinge wrote: > > > > - In POST(epoll_wait), I check if the result is > 0 before doing the > > > SYSCALL_TRACK, and the size argument relies on the result, rather than > > > arg3. > > > > The check is redundant - POST(x) is never called if the syscall didn't > > succeed. > > It can succeed and still return 0; if it does, we don't want to to call > post_mem_write because nothing has been written (and the size arg would be > 0). Ah, OK. J |