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
|
2
(7) |
3
(4) |
4
(6) |
5
(6) |
6
(4) |
|
7
|
8
(6) |
9
|
10
|
11
(10) |
12
(5) |
13
(2) |
|
14
(3) |
15
(3) |
16
(14) |
17
(7) |
18
(7) |
19
(5) |
20
(4) |
|
21
(5) |
22
(5) |
23
(3) |
24
(11) |
25
(5) |
26
(9) |
27
(5) |
|
28
(2) |
29
(7) |
30
(3) |
31
(2) |
|
|
|
|
From: Julian S. <js...@ac...> - 2004-03-13 00:35:55
|
We are pleased to announce a new release, 2.1.1, from our current development (unstable) branch, available from http://valgrind.kde.org. It appears to be fairly stable and quite usable, but at the end of the day, is still a development release. Anyway, the details follow. J -------------------------------------------------------------------- 2.1.1 contains some internal structural changes needed for V's long-term future. These don't affect end-users. Most notable user-visible changes are: * Greater isolation between Valgrind and the program being run, so the program is less likely to inadvertently kill Valgrind by doing wild writes. * Massif: a new space profiling tool. Try it! It's cool, and it'll tell you in detail where and when your C/C++ code is allocating heap. Draws pretty .ps pictures of memory use against time. A potentially powerful tool for making sense of your program's space use. * Fixes for many bugs, including support for more SSE2/SSE3 instructions, various signal/syscall things, and various problems with debug info readers. * Support for glibc-2.3.3 based systems. We are now doing automatic overnight build-and-test runs on a variety of distros. As a result, we believe 2.1.1 builds and runs on: Red Hat 7.2, 7.3, 8.0, 9, Fedora Core 1, SuSE 8.2, SuSE 9. The following bugs, and probably many more, have been fixed. These are listed at http://bugs.kde.org. Reporting a bug for valgrind in the http://bugs.kde.org is much more likely to get you a fix than mailing developers directly, so please continue to keep sending bugs there. 69616 glibc 2.3.2 w/NPTL is massively different than what valgrind expects 69856 I don't know how to instrument MMXish stuff (Helgrind) 73892 valgrind segfaults starting with Objective-C debug info (fix for S-type stabs) 73145 Valgrind complains too much about close(<reserved fd>) 73902 Shadow memory allocation seems to fail on RedHat 8.0 68633 VG_N_SEMAPHORES too low (V itself was leaking semaphores) 75099 impossible to trace multiprocess programs 76839 the `impossible' happened: disInstr: INT but not 0x80 ! 76762 vg_to_ucode.c:3748 (dis_push_segreg): Assertion `sz == 4' failed. 76747 cannot include valgrind.h in c++ program 76223 parsing B(3,10) gave NULL type => impossible happens 75604 shmdt handling problem 76416 Problems with gcc 3.4 snap 20040225 75614 using -gstabs when building your programs the `impossible' happened 75787 Patch for some CDROM ioctls CDORM_GET_MCN, CDROM_SEND_PACKET, 75294 gcc 3.4 snapshot's libstdc++ have unsupported instructions. (REP RET) 73326 vg_symtab2.c:272 (addScopeRange): Assertion `range->size > 0' failed. 72596 not recognizing __libc_malloc 69489 Would like to attach ddd to running program 72781 Cachegrind crashes with kde programs 73055 Illegal operand at DXTCV11CompressBlockSSE2 (more SSE opcodes) 73026 Descriptor leak check reports port numbers wrongly 71705 README_MISSING_SYSCALL_OR_IOCTL out of date 72643 Improve support for SSE/SSE2 instructions 72484 valgrind leaves it's own signal mask in place when execing 72650 Signal Handling always seems to restart system calls 72006 The mmap system call turns all errors in ENOMEM 71781 gdb attach is pretty useless 71180 unhandled instruction bytes: 0xF 0xAE 0x85 0xE8 69886 writes to zero page cause valgrind to assert on exit 71791 crash when valgrinding gimp 1.3 (stabs reader problem) 69783 unhandled syscall: 218 69782 unhandled instruction bytes: 0x66 0xF 0x2B 0x80 70385 valgrind fails if the soft file descriptor limit is less than about 828 69529 "rep; nop" should do a yield 70827 programs with lots of shared libraries report "mmap failed" for some of them when reading symbols 71028 glibc's strnlen is optimised enough to confuse valgrind |
|
From: Jeremy F. <je...@go...> - 2004-03-12 23:48:03
|
On Fri, 2004-03-12 at 12:33, Igmar Palsenberg wrote: > Hi, > > Some notices : > > It clutters my screen with : > > Couldn't find previous reference to "/usr/include/sys/types.h"/61667 for > fileidx 1 Sounds like the stabs reader; which version of gcc/toolchain are you using? What distro? > and a few dozen more. > > Second : > > [igmar@ouzo fwtk]$ set | grep VAL > VALGRIND_OPTS=--tool=memcheck > [igmar@ouzo fwtk]$ valgrind --track-children=no ./xx > Segmentation fault (core dumped) > > It's not the program. When i unset the environment variable, all goes > fine. The segfault occurs with every option in that case. Hm. Which glibc/kernel are you using? J |
|
From: Igmar P. <mai...@jd...> - 2004-03-12 20:44:17
|
Hi, Some notices : It clutters my screen with : Couldn't find previous reference to "/usr/include/sys/types.h"/61667 for fileidx 1 and a few dozen more. Second : [igmar@ouzo fwtk]$ set | grep VAL VALGRIND_OPTS=--tool=memcheck [igmar@ouzo fwtk]$ valgrind --track-children=no ./xx Segmentation fault (core dumped) It's not the program. When i unset the environment variable, all goes fine. The segfault occurs with every option in that case. Regards, Igmar |
|
From: <ar...@de...> - 2004-03-12 19:26:10
|
I've already included this patch to valgrind-2.1.0 on the Debian version. The patch is attached. Let me know if it works for you. Regards. |
|
From: Igmar P. <mai...@jd...> - 2004-03-12 19:20:34
|
> VG 2.1.0 starts to use anonymous unions. That works when your compiler is > GCC 3.x.x based, but not when you're using a C89 compiler like gcc 2.94.x. > Would a patch to revert this behaviour be accepted ? I'm willing to fix > this. Forget this, wrong source tree :( Igmar |
|
From: Igmar P. <mai...@jd...> - 2004-03-12 19:12:26
|
Hi, VG 2.1.0 starts to use anonymous unions. That works when your compiler is GCC 3.x.x based, but not when you're using a C89 compiler like gcc 2.94.x. Would a patch to revert this behaviour be accepted ? I'm willing to fix this. Regards, |
|
From: Tom H. <th...@cy...> - 2004-03-11 23:16:52
|
In message <1079042725.25599.209.camel@antigua>
Chris AtLee <ch...@at...> wrote:
> On Thu, 2004-03-11 at 16:52, Jeremy Fitzhardinge wrote:
> > Erm, wouldn't it be enough to just record each basic block? By
> > definition, once you've run the first instruction, you're going to run
> > all the rest (unless your code does *lots* of exceptions). That should
> > reduce the rate of events quite a bit.
>
> What about conditional jumps? I'm not sure what constitutes a basic
> block, which is why I did it the way that I did.
Any sort of jump will end a basic block. That's what a basic block
is - a chunk of code that is always executes to the end once it has
started, at least if you exclude processor exceptions.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Chris A. <ch...@at...> - 2004-03-11 22:16:07
|
On Thu, 2004-03-11 at 16:52, Jeremy Fitzhardinge wrote: > Erm, wouldn't it be enough to just record each basic block? By > definition, once you've run the first instruction, you're going to run > all the rest (unless your code does *lots* of exceptions). That should > reduce the rate of events quite a bit. What about conditional jumps? I'm not sure what constitutes a basic block, which is why I did it the way that I did. Cheers, Chris |
|
From: Jeremy F. <je...@go...> - 2004-03-11 22:04:31
|
On Thu, 2004-03-11 at 11:43, Chris AtLee wrote: > Hi all, > > I started working on a code coverage skin for valgrind...Mostly as a > learning project to see how valgrind works. A patch against current CVS > can be found at: > http://atlee.ca/coverage.patch.gz > > The skin is pretty stupid, it just records hits on instructions when it > sees the INCEIP instruction. It also tries to do some conditional jump > analysis. I've written a python script that will annotate source and > show you what lines have been executed. Erm, wouldn't it be enough to just record each basic block? By definition, once you've run the first instruction, you're going to run all the rest (unless your code does *lots* of exceptions). That should reduce the rate of events quite a bit. > - Really slow, it actually writes out to a file descriptor for every > instruction hit...The skin should probably just maintain a list of line > hits and write it all out at the end like cachegrind. You might want to have a look at vgprof. I wrote it with the intention of making Valgrind interoperate with gprof by generating gprof-format files. Unfortunately, the gprof format is horrible and inextensible, so the only way it can work is by hacking gprof itself, which isn't fun. Anyway, you might get some ideas from it: http://www.goop.org/~jeremy/valgrind/12-vgprof.patch http://www.goop.org/~jeremy/valgrind/vgprof.html J |
|
From: Chris A. <ch...@at...> - 2004-03-11 19:54:12
|
Hi all, I started working on a code coverage skin for valgrind...Mostly as a learning project to see how valgrind works. A patch against current CVS can be found at: http://atlee.ca/coverage.patch.gz The skin is pretty stupid, it just records hits on instructions when it sees the INCEIP instruction. It also tries to do some conditional jump analysis. I've written a python script that will annotate source and show you what lines have been executed. Known bugs: - I get hits recorded in the middle of functions in completely unrelated files sometimes... - Really slow, it actually writes out to a file descriptor for every instruction hit...The skin should probably just maintain a list of line hits and write it all out at the end like cachegrind. Cheers, Chris |
|
From: Dirk M. <dm...@gm...> - 2004-03-11 18:10:49
|
On Thursday 11 March 2004 11:56, mam...@hs... wrote: > What could be wrong here ?? hard to say, but a backtrace of the corefile might help. Dirk |
|
From: Tom H. <th...@cy...> - 2004-03-11 12:53:26
|
In message <Pin...@ye...>
Nicholas Nethercote <nj...@ca...> wrote:
> On Thu, 11 Mar 2004 mam...@hs... wrote:
>
>> I am running :
>> - Valgrind 2.1.0 version.
>> - The command-line is "valgrind ls -l"
>> - The output of valgrind -v is also "Segmentation fault (core dumpted)"
>
> No output before that at all?
>
>> The linux version is Redhat 7.1 , kernel 2.4.2-2.
>> glibc version 2.2 , gnu C version 2.96.
For what it's worth I just built 2.1.0 on a RedHat 7.1 box and it
seems to be running fine. Kernel is 2.4.18-27.7.x and glibc is 2.2.4-32.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: <rk...@ya...> - 2004-03-11 12:41:30
|
Hi, If your linux version is 7.1. and kernel version is 2.4.2-2, you may try with valgrind-1.9.6 version. I also got the core dump and tried with 1.9.6. it works for me. This version of valgrind you won't see in kde site. Better search valgrind-1.9.6 in the google and get the src. Thanks, Kaliyaperumal --- mam...@hs... wrote: > Hi, > I downloaded the valgrind sources , and compiled and > installed it on a > Redhat 7.1 linux machine (i686 arch). > > The make process went through without any problems. > > > I followed the steps as given in the manual. > > ./configure, > make, > make install > > Make install has installed the valgrind executable > at /usr/local/bin. > > But when I ran the valgrind command , I got > "Segmentation fault (core > dumped)" error. > > What could be wrong here ?? > > regards, > -muneeb- > ___________________________________________________________ Yahoo! Messenger - Communicate instantly..."Ping" your friends today! Download Messenger Now http://uk.messenger.yahoo.com/download/index.html |
|
From: Nicholas N. <nj...@ca...> - 2004-03-11 12:21:29
|
On Thu, 11 Mar 2004 mam...@hs... wrote: > I am running : > - Valgrind 2.1.0 version. > - The command-line is "valgrind ls -l" > - The output of valgrind -v is also "Segmentation fault (core dumpted)" No output before that at all? > The linux version is Redhat 7.1 , kernel 2.4.2-2. > glibc version 2.2 , gnu C version 2.96. N |
|
From: Nicholas N. <nj...@ca...> - 2004-03-11 12:03:12
|
On Thu, 11 Mar 2004 mam...@hs... wrote: > But when I ran the valgrind command , I got "Segmentation fault (core > dumped)" error. From valgrind.kde.org/bugs.html: When you report a bug, please give the following information: * What version of Valgrind you are running; * What command-line you are using to run Valgrind; * The output of valgrind -v. It may also be useful to include your Linux version, kernel version, and glibc version. If you include all this information, you are much more likely to get a useful response. N |
|
From: <mam...@hs...> - 2004-03-11 11:13:54
|
Hi, I downloaded the valgrind sources , and compiled and installed it on a Redhat 7.1 linux machine (i686 arch). The make process went through without any problems. I followed the steps as given in the manual. ./configure, make, make install Make install has installed the valgrind executable at /usr/local/bin. But when I ran the valgrind command , I got "Segmentation fault (core dumped)" error. What could be wrong here ?? regards, -muneeb- |
|
From: Jeremy F. <je...@go...> - 2004-03-08 17:52:32
|
On Mon, 2004-03-08 at 09:09, Tom Hughes wrote: > I think some kernels reject vaery large mmaps under certain sorts > of memory starvation condition or something - there is a bug for it > on the bug tracker somewhere. > > If you're not already using the latest kernel for that version > of RH then I'd suggest upgrading or even just trying a reboot of > the machine. It could also be a virtual address size limit, like the one Dirk has installed. There's not a lot we can do about it, other than trying to raise the soft limit. Actually, the most useful thing we can do is check the error returns on all mmaps and generate a useful error message rather than SEGV mysteriously. J |
|
From: Tom H. <th...@cy...> - 2004-03-08 17:17:33
|
In message <32B...@is...>
Mehric Asmir <Asm...@ic...> wrote:
> I'm running a multithreaded application on Red Hat 7.2.
> Valgrind was build from CVS and runs just fine with coregrind, addrcheck and
> cashecheck but fails with memcheck and helgrind.
> Here are the outputs from both problematic runs:
It's failing with the skins that ask for a lot of shadow memory by
the looks of it, which probably means the large mmaps are failing
which is something I saw once but was unable to reproduce after a
reboot.
I think some kernels reject vaery large mmaps under certain sorts
of memory starvation condition or something - there is a bug for it
on the bug tracker somewhere.
If you're not already using the latest kernel for that version
of RH then I'd suggest upgrading or even just trying a reboot of
the machine.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Mehric A. <Asm...@ic...> - 2004-03-08 16:28:42
|
I'm running a multithreaded application on Red Hat 7.2. Valgrind was build from CVS and runs just fine with coregrind, addrcheck and cashecheck but fails with memcheck and helgrind. Here are the outputs from both problematic runs: ******************************* ==19005== Memcheck, a memory error detector for x86-linux. ==19005== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward. ==19005== Using valgrind-2.1.0, a program supervision framework for x86-linux. ==19005== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward. ==19005== Valgrind library directory: /home/src/user/amehric/valgrind-new-inst/lib/valgrind ==19005== Command line ==19005== ./sca_sip ==19005== Startup, with flags: ==19005== -v ==19005== --tool=memcheck ==19005== Reading syms from /home/sca_sip/bin/sca_sip (0x8048000) --19005-- INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting --19005-- si_code=1 Fault EIP: 0xB030B673 (); Faulting address: 0x50100000 valgrind: the `impossible' happened: Killed by fatal signal Basic block ctr is approximately 0 ==19005== at 0xB802D502: ??? ==19005== by 0xB802D501: ??? ==19005== by 0xB802D519: ??? ==19005== by 0xB80332A7: ??? sched status: Thread 1: status = Runnable, associated_mx = 0x0, associated_cv = 0x0 ==19005== at 0x3C001E10: ??? Note: see also the FAQ.txt in the source distribution. It contains workarounds to several common problems. If that doesn't help, please report this bug to: valgrind.kde.org In the bug report, send all the above text, the valgrind version, and what Linux distro you are using. Thanks. ******************************* ==19037== Helgrind, a data race detector for x86-linux. ==19037== Copyright (C) 2002-2004, and GNU GPL'd, by Nicholas Nethercote. ==19037== Using valgrind-2.1.0, a program supervision framework for x86-linux. ==19037== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward. ==19037== Valgrind library directory: /home/src/user/amehric/valgrind-new-inst/lib/valgrind ==19037== Command line ==19037== ./sca_sip ==19037== Startup, with flags: ==19037== -v ==19037== --tool=helgrind ==19037== Reading syms from /home/sca_sip/bin/sca_sip (0x8048000) --19037-- INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting --19037-- si_code=1 Fault EIP: 0xB016AB70 (); Faulting address: 0x54100000 valgrind: the `impossible' happened: Killed by fatal signal Basic block ctr is approximately 0 ==19037== at 0xB802D502: ??? ==19037== by 0xB802D501: ??? ==19037== by 0xB802D519: ??? ==19037== by 0xB80332A7: ??? sched status: Thread 1: status = Runnable, associated_mx = 0x0, associated_cv = 0x0 ==19037== at 0x3F001E10: ??? Note: see also the FAQ.txt in the source distribution. It contains workarounds to several common problems. If that doesn't help, please report this bug to: valgrind.kde.org In the bug report, send all the above text, the valgrind version, and what Linux distro you are using. Thanks. ********************************** It seams to be the same problem in both cases. How can I debug this ? Are there any command line flags that will give more information ? Thanks Asmir Mehic |
|
From: Mehric A. <Asm...@ic...> - 2004-03-08 15:40:48
|
I've applied the vgprof patch file 12-vgprof.patch to the latest CVS sources and got this error: vg_mylibc.c:1393: `rdtsc_ticks_per_millisecond' undeclared (first use in this function) Is vgprof compatible with the current Valgrind CVS ? Asmir Mehic |
|
From: Nicholas N. <nj...@ca...> - 2004-03-08 15:36:51
|
On Wed, 3 Mar 2004, Remko Troncon wrote: > I would like to start off by saying that valgrind is really an excellent > program, and that it already prevented a lot of nasty bugs for me after only > using valgrind for 2 days. > > Now my question: I added it to my automated testsuite, but allthough i use > valgrind -q, i still get the warning: > ==10077== Warning: set address range perms: large range 350158848, a > 0, v 1 > Is there a way for preventing this ? Short of commenting it out in the code and recompiling, no. It shouldn't give out this warning with -q, though. N |
|
From: Nicholas N. <nj...@ca...> - 2004-03-08 15:35:26
|
On Fri, 5 Mar 2004, Paul Pearcy wrote: > I am curious if any of the developers have looked into using valgrind to > gather code coverage information? When valgrind executes a basic block it > seems like it would be almost trivial to add this information to some kind > of coverage file, similar to the .da files created by gcov(the gnu code > coverage tool). I think, the more difficult part would be mapping the basic > block execution info back to the actual source code, especially in the case > of Java, or other translated/interpreted languages. Please let me know if > anybody has input into the feasablity of this and why it would or wouldn't > work. See vgprof, from valgrind.kde.org/related.html. Mapping back to source code in Java would be tricky, I think. Well, Valgrind currently reads stabs and DWARF2 debug info in order to map from instructions back to source code; if Java used them too that shouldn't pose problems, but I don't know if Java uses them. N |
|
From: Rupert K. <rk...@mu...> - 2004-03-06 10:23:58
|
On Fri, 5 Mar 2004, Steven J. Plimpton wrote: > I couldn't find anything specific in the docs about Fortran, other > than a statement that valgrind works with executables from all > languages, including Fortran. > > But a simple program like this generates no errors or memory leaks > when run under valgrind-2.0.0, whereas the equivalent C code flags > both. The 1st 2 lines are f90; replacing them with the 3rd line is > f77. > > integer, allocatable :: a(:) > allocate(a(100)) > c integer a(100) > > i = 101 > a(i) = 1 > write (6,*) a(i) > end > > Is valgrind not able to catch that kind of error/leak in Fortran? > Seems odd, since allocate is presumably a wrapper on malloc. > > Steve > If I remember correctly, allocatable array have automatic storage class by default, i.e. their allocation status becomes 'undefined' when their scope is left. The compiler will free the associated memory, similar to using alloca() in C or std::vector in C++. Rupert |
|
From: Tom H. <th...@cy...> - 2004-03-06 07:54:27
|
In message <002601c40336$8f4752f0$120...@gs...>
"Matt Emmerton" <ma...@gs...> wrote:
> *** pth_cancel2.stderr.exp 2002-11-18 06:33:37.000000000 -0500
> --- pth_cancel2.stderr.out 2004-03-05 23:38:49.000000000 -0500
> ***************
> *** 1 ****
> --- 2 ----
> + write: Interrupted system call
This one doesn't always happen in my experience, but does happen on
a percentage of runs. I think it's some sort of race condition but it
doesn't seem to make any sense to me as my reading of the pthreads
doco says that the writ should never return if it is cancelled.
I've also only ever seen this on RH9 which makes me suspect some sort
of kernel or glibc bug.
> *** res_search.stdout.exp 2003-07-04 12:16:51.000000000 -0400
> --- res_search.stdout.out 2004-03-05 23:39:04.000000000 -0500
> ***************
> *** 1 ****
> - Success!
> --- 0 ----
I haven't seen this in an recent RH9 builds.
> *** inherit.stderr.exp 2003-10-18 18:27:10.000000000 -0400
> --- inherit.stderr.out 2004-03-05 23:39:19.000000000 -0500
> ***************
> *** 1 ****
> ! XXX We expect an error on inherit.c:48
> --- 1,2 ----
> !
> !
This fails everywhere and is an expected failure.
> *** pth_once.stdout.exp 2003-10-30 04:11:03.000000000 -0500
> --- pth_once.stdout.out 2004-03-05 23:41:38.000000000 -0500
> ***************
> *** 11 ****
> - identify_yourself: Hi, I'm thread # 9
> --- 10 ----
> ***************
> *** 20 ****
> --- 20 ----
> + identify_yourself: Hi, I'm thread # 9
I've haven't seen this one either - it looks like that line has
moved in the output though - maybe a race between two threads?
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Matt E. <ma...@gs...> - 2004-03-06 05:00:51
|
Using the latest version from CVS, I get a different set of failures. It builds successfully, but running "tests/vg_regtest --all" fails with 4 failures. The pth_cancel2 and inherit failures are the same in v2.1.0. I will start working on tracking these failures down. == 125 tests, 2 stderr failures, 2 stdout failures ================= corecheck/tests/pth_cancel2 (stderr) corecheck/tests/res_search (stdout) helgrind/tests/inherit (stderr) memcheck/tests/pth_once (stdout) *** pth_cancel2.stderr.exp 2002-11-18 06:33:37.000000000 -0500 --- pth_cancel2.stderr.out 2004-03-05 23:38:49.000000000 -0500 *************** *** 1 **** --- 2 ---- + write: Interrupted system call *** res_search.stdout.exp 2003-07-04 12:16:51.000000000 -0400 --- res_search.stdout.out 2004-03-05 23:39:04.000000000 -0500 *************** *** 1 **** - Success! --- 0 ---- *** inherit.stderr.exp 2003-10-18 18:27:10.000000000 -0400 --- inherit.stderr.out 2004-03-05 23:39:19.000000000 -0500 *************** *** 1 **** ! XXX We expect an error on inherit.c:48 --- 1,2 ---- ! ! *** pth_once.stdout.exp 2003-10-30 04:11:03.000000000 -0500 --- pth_once.stdout.out 2004-03-05 23:41:38.000000000 -0500 *************** *** 11 **** - identify_yourself: Hi, I'm thread # 9 --- 10 ---- *************** *** 20 **** --- 20 ---- + identify_yourself: Hi, I'm thread # 9 |