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
(20) |
2
(6) |
3
(11) |
4
(1) |
|
5
|
6
(2) |
7
(13) |
8
(14) |
9
(3) |
10
(3) |
11
(2) |
|
12
(4) |
13
|
14
(8) |
15
(6) |
16
(7) |
17
(4) |
18
(3) |
|
19
(5) |
20
(4) |
21
(10) |
22
(6) |
23
|
24
(7) |
25
|
|
26
(6) |
27
(6) |
28
(2) |
29
(4) |
30
(5) |
31
(7) |
|
|
From: Julian S. <js...@ac...> - 2006-03-07 02:03:09
|
I'd like to release 3.1.1 some time around Friday, if possible. Many bug fixes have been merged in now and I'm hoping to be in a code freeze state soon. A good summary of the bugs that have been fixed are in trunk/docs/internals/3_1_BUGSTATUS.txt. If you're a packager, or you want to check that 3.1.1 fixes your showstopping bug in 3.1.0, now would be a good time to check out the 3.1.X line and test it: svn co svn://svn.valgrind.org/valgrind/branches/VALGRIND_3_1_BRANCH \ branch31 cd branch31 ./autogen.sh # then configure and build as usual Let me know of any critical breakage ASAP. J |
|
From: Olly B. <ol...@su...> - 2006-03-07 00:08:06
|
On 2006-03-06, Ed Peschko <es...@pg...> wrote:
> I notice that gdb is called with
>
> gdb -nw %f %p
>
> by default. in other words, it has the ability to write into the executable
> or core file.
Erm, for gdb "-nw" means "don't use a window interface". You seem to be
confusing it with "--write".
Cheers,
Olly
|
|
From: Ed P. <es...@pg...> - 2006-03-06 23:53:38
|
hey all, I was wondering if gdbserver could be used with valgrind - ie: I have a process that I'd like to debug but it is run through xinetd. Hence I'd like valgrind to spawn off a gdbserver process which I would attach to inside another window on the event of a memory leak. I've already had to modify valgrind once for this (taking away the prompt to start the debugger) - now I notice that gdb is called with gdb -nw %f %p by default. in other words, it has the ability to write into the executable or core file. However, I don't think that gdbserver has this ability. Anyways, I was wondering if anyone had done this - used gdbserver to debug with valgrind. Technically this is probably a gdb question, but I thought I would cover all bases.. Thanks much for any help, and if you could CC me personally with any feedback I'd appreciate it. Ed |
|
From: John S. <joh...@ya...> - 2006-03-06 18:58:29
|
Hi, I have been trying to run my code under valgrind for memory leaks. Have been cross compiling on Red Hat Linux with Monta Vista to cross compile for ppc32 target. However I am getting the following error: WARNING: unhandled syscallL 72 You may be able to write your own handler. Read the file README_MISSING_SYSCALL_OR_IOCTL Tried to read the above file and implement on my own, but got lost on the way. Can anyone help? Thanks, John __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |
|
From: Leung Ngai-H. Z. <leu...@co...> - 2006-03-04 01:18:17
|
On Fri, 3 Mar 2006, Julian Seward wrote: > > > > r 0x45BE31 1 > > > r 0x45F248 0 > > Why doesn't it look like the text region? That looks like exactly the > > sort of address that a 32 bit program loads at on x86 to me. > > Indeed, 0x8048xxx is the classic text region on x86-linux. > > Try running with -d -d. This will show the memory layout at > client startup, which might make more sense of it. I'd guess > 0x45xxxx is your ld.so and 0x8048xxx is the executable. Oh, I understand now. I was confused because there are two text regions: ld.so and the executable. Thanks for your help! Zac |
|
From: Julian S. <js...@ac...> - 2006-03-03 19:14:43
|
> ==15561== Using valgrind-2.2.0, a program supervision framework for > x86-linux. Whoa! That's ancient. I suggest you upgrade to 3.1.0 and try again. J |
|
From: Mayukh B. <ma...@gm...> - 2006-03-03 19:08:55
|
Julian Seward <jseward <at> acm.org> writes: > > > > For some reason, valgrind (first with the cachegrind tool) didn't like this > > part of our code and simply choked. > > Choked in what sense? Died and spewed out a load of messages in the > process? If so, just send them (and tell us what version of V you > are using.) > > J > > It got stuck for a very long time (several hours vs. 2 seconds without valgrind) before I killed it. Version: ==15561== Using valgrind-2.2.0, a program supervision framework for x86-linux. I will try to reproduce the problem and send it over the weekend. Thank you, -Mayukh. |
|
From: Mayukh B. <ma...@gm...> - 2006-03-03 19:01:40
|
Michael Smith <msmith <at> xiph.org> writes: > You can #include <valgrind/valgrind.h>, then use the > RUNNING_ON_VALGRIND macro, like: > > if (RUNNING_ON_VALGRIND) { > do_special_thing(); > } > else { > do_normal_thing(); > } Thank you! I verified that this works. -Mayukh. |
|
From: Julian S. <js...@ac...> - 2006-03-03 18:59:49
|
> For some reason, valgrind (first with the cachegrind tool) didn't like this > part of our code and simply choked. Choked in what sense? Died and spewed out a load of messages in the process? If so, just send them (and tell us what version of V you are using.) J |
|
From: Mayukh B. <ma...@gm...> - 2006-03-03 18:53:49
|
Julian Seward <jseward <at> acm.org> writes: > > > > One of the requirements for migrating is that my program "foo" absolutely > > needs to know that it is being run by valgrind. > > Why is that? Timing issues, or something else? > > J > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting language > that extends applications into web and mobile media. Attend the live webcast > and join the prime developer group breaking into this new coding territory! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 > We have a portion of our code where we try to figure out the cache-size, cpuspeed, etc., of the machine it is running on. For learning about the cache-size and miss-ratio etc, we generate larger and larger vectors. This process usually takes about a second of cpu. This part of our code is simply for precise benchmarking and QA'ing of our code. Otherwise it is useless. For some reason, valgrind (first with the cachegrind tool) didn't like this part of our code and simply choked. We got around by disabling that part of the code. Later, we tried running memcheck and again it had the same problem with this piece of code. I could try to reproduce this in a smaller C program, if you are interested. It might take me a couple of days to get to it, though. -Mayukh. |
|
From: Julian S. <js...@ac...> - 2006-03-03 18:24:45
|
> One of the requirements for migrating is that my program "foo" absolutely > needs to know that it is being run by valgrind. Why is that? Timing issues, or something else? J |
|
From: Michael S. <ms...@xi...> - 2006-03-03 18:16:57
|
On 3/3/06, Mayukh Bhattacharya <ma...@gm...> wrote:
>
> Hi,
>
> I am a IBM Purify user looking to start serious valgrind memchecking.
>
> One of the requirements for migrating is that my program "foo" absolutely
> needs to know that it is being run by valgrind. Using that knowledge,
> it will not do certain things. Purify would give me that information
> through a variable and foo would know easily that "purify_is_running"
> or not.
You can #include <valgrind/valgrind.h>, then use the
RUNNING_ON_VALGRIND macro, like:
if (RUNNING_ON_VALGRIND) {
do_special_thing();
}
else {
do_normal_thing();
}
You need the header file for this, but the application will run
normally without valgrind; it adds no runtime dependencies.
Mike
|
|
From: Mayukh B. <ma...@gm...> - 2006-03-03 18:11:21
|
Hi, I am a IBM Purify user looking to start serious valgrind memchecking. One of the requirements for migrating is that my program "foo" absolutely needs to know that it is being run by valgrind. Using that knowledge, it will not do certain things. Purify would give me that information through a variable and foo would know easily that "purify_is_running" or not. What could be possible ways of getting the same effect in valgrind? Is there an environment variable that valgrind would set that foo can look for? Thanks, -Mayukh. |
|
From: Julian S. <js...@ac...> - 2006-03-03 11:48:22
|
> > r 0x45BE31 1 > > r 0x45F248 0 > > r 0x8048114 1 > > > > If my understanding is correct, 1 means it's the text region. 0 should > > mean that it's either the stack or the heap. The first instruction looks > > like the text region, the second looks like the heap, but the third one > > doesn't at all look like the text region though it's labelled as such. > > Any idea what happened? > > Why doesn't it look like the text region? That looks like exactly the > sort of address that a 32 bit program loads at on x86 to me. Indeed, 0x8048xxx is the classic text region on x86-linux. Try running with -d -d. This will show the memory layout at client startup, which might make more sense of it. I'd guess 0x45xxxx is your ld.so and 0x8048xxx is the executable. J |
|
From: Tom H. <to...@co...> - 2006-03-03 08:31:41
|
In message <Pin...@sf...>
Leung Ngai-Hang Zachary <leu...@co...> wrote:
> I instrumented each basic block such that I call this function whenever I
> encounter a load instruction:
>
> static VG_REGPARM(1) void trace_load(Addr addr)
> {
> VG_(printf)("r %p %d\n", addr, VG_(seginfo_sect_kind)(addr));
> }
>
> It gives me the output I want, mostly. I can't understand though why I
> get output like the following:
>
> r 0x45BE31 1
> r 0x45F248 0
> r 0x8048114 1
>
> If my understanding is correct, 1 means it's the text region. 0 should
> mean that it's either the stack or the heap. The first instruction looks
> like the text region, the second looks like the heap, but the third one
> doesn't at all look like the text region though it's labelled as such.
> Any idea what happened?
Why doesn't it look like the text region? That looks like exactly the
sort of address that a 32 bit program loads at on x86 to me.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Leung Ngai-H. Z. <leu...@co...> - 2006-03-03 05:33:49
|
Hi,
I instrumented each basic block such that I call this function whenever I
encounter a load instruction:
static VG_REGPARM(1) void trace_load(Addr addr)
{
VG_(printf)("r %p %d\n", addr, VG_(seginfo_sect_kind)(addr));
}
It gives me the output I want, mostly. I can't understand though why I
get output like the following:
r 0x45BE31 1
r 0x45F248 0
r 0x8048114 1
If my understanding is correct, 1 means it's the text region. 0 should
mean that it's either the stack or the heap. The first instruction looks
like the text region, the second looks like the heap, but the third one
doesn't at all look like the text region though it's labelled as such.
Any idea what happened?
Zac
|
|
From: Anne D. <adu...@gm...> - 2006-03-02 21:30:25
|
Hi, I am having trouble compiling valgrind on my opteron box. The
error given is:
if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../coregrind -I..
-I../coregrind/x86 -I../coregrind/linux -I../coregrind/x86-linux
-I../include -I../VEX/pub -DVG_PLATFORM=3D"\"x86-linux\"" -DVGA_x86=3D1
-DVGO_linux=3D1 -DVGP_x86_linux=3D1
-DVG_LIBDIR=3D"\"/usr/local/lib/valgrind"\" -m32 -O -g
-Wmissing-prototypes -Winline -Wall -Wshadow -Wpointer-arith
-Wstrict-prototypes -Wmissing-declarations -Wno-long-long
-Wno-pointer-sign -Wdeclaration-after-statement -MT
libcoregrind_x86_linux_a-m_commandline.o -MD -MP -MF
".deps/libcoregrind_x86_linux_a-m_commandline.Tpo" -c -o
libcoregrind_x86_linux_a-m_commandline.o `test -f 'm_commandline.c' ||
echo './'`m_commandline.c; \
then mv -f ".deps/libcoregrind_x86_linux_a-m_commandline.Tpo"
".deps/libcoregrind_x86_linux_a-m_commandline.Po"; else rm -f
".deps/libcoregrind_x86_linux_a-m_commandline.Tpo"; exit 1; fi
In file included from /usr/include/features.h:337,
from /usr/include/setjmp.h:26,
from pub_core_basics.h:63,
from m_commandline.c:31:
/usr/include/gnu/stubs.h:7:27: error: gnu/stubs-32.h: No such file or direc=
tory
make[3]: *** [libcoregrind_x86_linux_a-m_commandline.o] Error 1
A quick internet search recommends adding the --disable-multilb flag.
However, it looks like this particular compile is trying to compile
for a 32bit architecture. Is there a way I can disable this via
configure or some such?
thanks,
Anne
|
|
From: Angel T. <fn...@fm...> - 2006-03-02 19:34:50
|
> Is your app dynamically linked (it needs to be)? And if you try to run valgrind on something like "ls -l"?
First, I get the same resutls with "ls -l" as I do with "ls" alone.
Second, I get a SIGSEGV (segmentation fault) even with the simplest C++ program:
int main( )
{
}
In my first post I can see that Valgrind says:
object doesn't have a dynamic symbol table
What does this mean and could it be the cause of the segmentation fault?
|
|
From: Angel T. <fn...@fm...> - 2006-03-02 18:41:55
|
>> Can anyone tell what might be wrong? Is it the program being debugged or is it Valgrind? > > What does the current version from SVN do ? Well, I just checked out the latest version (revisions 1579 of VEX and 5708 of Valgrind) from the SVN repository (by executing svn co svn://svn.valgrind.org/valgrind/trunk valgrind). Then I added execute permissions to autogen.sh and executed it to get this: running: aclocal running: autoheader ' is already registered with AC_CONFIG_FILES. autoconf/status.m4:848: AC_CONFIG_FILES is expanded from... configure.in:709: the top level autom4te: /usr/bin/m4 failed with exit status: 1 autoheader: /usr/local/bin/autom4te failed with exit status: 1 error: while running 'autoheader' It seems that smth is wrong and I cannot figure out what. Any ideas are welcome. |
|
From: Igmar P. <mai...@jd...> - 2006-03-02 15:29:34
|
> Can anyone tell what might be wrong? Is it the program being debugged or is it Valgrind? What does the current version from SVN do ? Igmar |
|
From: Angel T. <fn...@fm...> - 2006-03-02 13:32:22
|
Every time I start valgrind on a command I get a sementation fault error, e.g.: valgrind -v --tool=none ls ==15208== Nulgrind, a binary JIT-compiler. ==15208== Copyright (C) 2002-2005, and GNU GPL'd, by Nicholas Nethercote. ==15208== Using LibVEX rev 1471, a library for dynamic binary translation. ==15208== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP. ==15208== Using valgrind-3.1.0, a dynamic binary instrumentation framework. ==15208== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al. ==15208== --15208-- Command line --15208-- ls --15208-- Startup, with flags: --15208-- -v --15208-- --tool=none --15208-- Contents of /proc/version: --15208-- Linux version 2.4.19-4asmp (ro...@ka...) (gcc version 2.95.4 20010319 (prerelease/franzo/20011204)) #1 SMP Wed Jun 5 00:59:38 EDT 2002 --15208-- Arch and subarch: PPC32, ppc32-int-fp-and-AV --15208-- Valgrind library directory: /home/angel/installed/Valgrind/lib/valgrind --15208-- Reading syms from /lib/ld-2.2.5.so (0x4000000) --15208-- Reading syms from /home/angel/installed/coreutils/bin/ls (0x10000000) --15208-- Reading syms from /home/angel/installed/Valgrind/lib/valgrind/ppc32-linux/none (0x70000000) --15208-- object doesn't have a dynamic symbol table ==15208== ==15208== Process terminating with default action of signal 11 (SIGSEGV) ==15208== Bad permissions for mapped region at address 0x4025D30 ==15208== at 0x4025D30: ??? ==15208== by 0x4010F20: _start (in /lib/ld-2.2.5.so) ==15208== --15208-- tt/tc: 5 tt lookups requiring 4 probes --15208-- tt/tc: 4 fast-cache updates, 2 flushes --15208-- translate: new 2 (100 -> 468; ratio 46:10) [0 scs] --15208-- translate: dumped 0 (0 -> ??) --15208-- translate: discarded 0 (0 -> ??) --15208-- scheduler: 2 jumps (bb entries). --15208-- scheduler: 0/3 major/minor sched events. --15208-- sanity: 1 cheap, 1 expensive checks. --15208-- exectx: 30,011 lists, 0 contexts (avg 0 per list) --15208-- exectx: 0 searches, 0 full compares (0 per 1000) --15208-- exectx: 0 cmp2, 0 cmp4, 0 cmpAll Segmentation fault Can anyone tell what might be wrong? Is it the program being debugged or is it Valgrind? |
|
From: gerhard s. <pos...@in...> - 2006-03-02 11:11:26
|
Hi, with valgrind: ==2886== Memcheck, a memory error detector. ==2886== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al. ==2886== Using LibVEX rev 1471, a library for dynamic binary translation. ==2886== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP. ==2886== Using valgrind-3.1.0, a dynamic binary instrumentation framework. ==2886== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al. I get a similar error (Assertion 'cfisi->len > 0...) (see below). A bzip2 ed log with --trace-cfi=yes can be provided. Any help would be great. Greetings G. Schabel valgrind: m_debuginfo/symtab.c:511 (vgModuleLocal_addCfiSI): Assertion 'cfisi->len > 0 && cfisi->len < 2000000' failed. ==2886== at 0xB000E3D8: report_and_quit (in /usr/lib/valgrind/x86-linux/memcheck) ==2886== by 0xB000E57A: vgPlain_assert_fail (in /usr/lib/valgrind/x86-linux/memcheck) ==2886== by 0xB0025771: vgModuleLocal_addCfiSI (in /usr/lib/valgrind/x86-linux/memcheck) ==2886== by 0xB00481F7: run_CF_instructions (in /usr/lib/valgrind/x86-linux/memcheck) ==2886== by 0xB00489FA: vgModuleLocal_read_callframe_info_dwarf2 (in /usr/lib/valgrind/x86-linux/memcheck) ==2886== by 0xB0028028: read_lib_symbols (in /usr/lib/valgrind/x86-linux/memcheck) ==2886== by 0xB00281CD: vgPlain_read_seg_symbols (in /usr/lib/valgrind/x86-linux/memcheck) ==2886== by 0xB0025119: vgPlain_di_notify_mmap (in /usr/lib/valgrind/x86-linux/memcheck) ==2886== by 0xB002EB64: vgModuleLocal_generic_PRE_sys_mmap (in /usr/lib/valgrind/x86-linux/memcheck) ==2886== by 0xB0043661: vgSysWrap_x86_linux_sys_mmap2_before (in /usr/lib/valgrind/x86-linux/memcheck) ==2886== by 0xB0039584: vgPlain_client_syscall (in /usr/lib/valgrind/x86-linux/memcheck) ==2886== by 0xB002B80B: handle_syscall (in /usr/lib/valgrind/x86-linux/memcheck) ==2886== by 0xB002BAC0: vgPlain_scheduler (in /usr/lib/valgrind/x86-linux/memcheck) ==2886== by 0xB003A708: thread_wrapper (in /usr/lib/valgrind/x86-linux/memcheck) ==2886== by 0xB003A7C8: run_a_thread_NORETURN (in /usr/lib/valgrind/x86-linux/memcheck) sched status: running_tid=1 Thread 1: status = VgTs_Runnable ==2886== at 0x40100D3: mmap (mmap.S:56) |
|
From: Julian S. <js...@ac...> - 2006-03-01 23:43:27
|
> > (random idea) If you re-run with --alignment=16, do you get > > different results? > Still the same. Valgrind reports with intel fortran compiler problem. > Someone else told me that valgrind has problem with Intel compiler. Is that > true? From the message below, could you please tell me what is wrong with > my code? It is impossible to say. It looks like you have an array indexing error. This would be easier if there was some line number info for MAIN__. It would help if you can check out and build the latest development sources of Valgrind. This is very easy; see http://valgrind.org/downloads/repository.html for details on how to do so. J |
|
From: Julian S. <js...@ac...> - 2006-03-01 22:32:05
|
> > Thank you very much for your email. I have compiled my code with "-g > > -O0" switches but valgrind doesn't point me a line number for the > > memory leak. Do you know how to detect the memory leak here? The > > output is not helpful at all. (random idea) If you re-run with --alignment=16, do you get different results? J |
|
From: Joe M. <joe...@me...> - 2006-03-01 21:15:26
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Brendan Drew wrote: >> Some portions are, yes. Although I'll admit right now that I'm surprised >> if this were the case. The variables are initialized as they are >> declared. I believe (and please, correct me if I'm wrong) that static >> variables which are initialized in place (e.g. static int foo = 0; ) >> result in the compiler emitting code which has the static variable >> allocated and initialized in the data section (i.e. initialized as the >> program is read into memory). The C++ FAQ says, "static local objects are constructed the first time control flows over their declaration" (http://www.parashift.com/c++-faq-lite/ctors.html#faq-10.12). This is important because it allows the programmer to specify exactly the initialization order. (This only really matters if the initializer is a function call, or otherwise depends on other variables which need initialization.) I assume the compiler's allowed to initialize statics in the data section only if they're initialized with a compile-time constant. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEBg7jq5NnQEnPdLcRAsTBAJ4lY0W1z1rkEd69Sv5sQ0dJg5mTowCfVjWG yvWKNabIH3D6RN/oGFGYlNw= =WIXa -----END PGP SIGNATURE----- |