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
(3) |
2
(1) |
|
3
(3) |
4
(6) |
5
(6) |
6
(9) |
7
(11) |
8
(8) |
9
(1) |
|
10
(4) |
11
(4) |
12
(13) |
13
(21) |
14
(5) |
15
(4) |
16
(6) |
|
17
(4) |
18
(12) |
19
(3) |
20
(20) |
21
(8) |
22
(4) |
23
(1) |
|
24
(1) |
25
(8) |
26
(11) |
27
(3) |
28
(8) |
29
(1) |
30
(3) |
|
From: Tom H. <to...@co...> - 2006-09-12 15:35:40
|
In message <C01...@ai...>
Jeff Harris <Je...@ai...> wrote:
> Both environments are using dynamic libstdc++:
>
>> powerpc-ai-linux-ldd a.out
> libstdc++.so.5 => libstdc++.so.5 (0x0)
> libm.so.6 => libm.so.6 (0x0)
> libgcc_s.so.1 => libgcc_s.so.1 (0x0)
> libc.so.6 => libc.so.6 (0x0)
> /lib/ld.so.1 => /lib/ld.so.1 (0x0)
>
> The addresses are zero because I'm using the cross-compiler ldd on my
> PC. The x86 version is the same. All of the symbols are missing. The
> library on both platform is stripped, but still has its dynamic
> relocation entries. The libc and libm libraries are also stripped, but
> still load with Valgrind.
I was going on the fact that the x86 output contains this:
--11147-- Reading syms from /lib/libstdc++.so.5.0.3 (0x401A000)
while the PPC output does not contain an equivalent line.
That line will appear regardless of whether or not it actually finds
any symbols - all that has to happen for that to appear is that
valgrind has to see an mmap that appears to be mapping in a given
shared library.
If it is dynamically linked then either the dynamic linker has not
loaded it for some reason or VG_(di_notify_mmap) has not recognised
the mapping as being from a library.
You might want to try adding --trace-syscalls=yes and look for
evidence of it opening libstdc++ and mapping from it. If you find
that it is doing so that I would try adding some extra trace
statements to VG_(di_notify_mmap) in coregrind/m_debuginfo/debuginfo.c
to try and work out why valgrind is not spotting it.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Harris, J. <Je...@ai...> - 2006-09-12 15:22:29
|
Both environments are using dynamic libstdc++:
> powerpc-ai-linux-ldd a.out
libstdc++.so.5 =3D> libstdc++.so.5 (0x0)
libm.so.6 =3D> libm.so.6 (0x0)
libgcc_s.so.1 =3D> libgcc_s.so.1 (0x0)
libc.so.6 =3D> libc.so.6 (0x0)
/lib/ld.so.1 =3D> /lib/ld.so.1 (0x0)
The addresses are zero because I'm using the cross-compiler ldd on my
PC. The x86 version is the same. All of the symbols are missing. The
library on both platform is stripped, but still has its dynamic
relocation entries. The libc and libm libraries are also stripped, but
still load with Valgrind.
If I run the base memcheck checker on the program, I also do not see it
loading libstdc++.
Jeff
-----Original Message-----
From: val...@li...
[mailto:val...@li...] On Behalf Of Tom
Hughes
Sent: Tuesday, September 12, 2006 9:55 AM
To: val...@li...
Subject: Re: [Valgrind-users] Callgrind results on ppc
In message
<C01...@ai...>
Jeff Harris <Je...@ai...> wrote:
> When compiled with the cross C++ compiler with -g and -O0, the output
on
> PowerPC does not pick up the symbols for libstdc++. All I get in
> kcachegrind are addresses. On the x86 platform, I get the symbols.
> Also on the PPC run I get cycles detected in some of the dynamic
loader
> function calls, like dl_main. The cycles do not appear on the x86
run.
> I have attached the output from Valgrind for both the ppc and x86
runs.
Have you checked what symbols were left in when you build libstdc++
for that machine? Are all libstdc+++ symbols missing? Or just some?
One obviously difference is that the x86 environment is using a
dynamic libstdc++ while the PPC environment appears to be using a
statically linked one.
Tom
--=20
Tom Hughes (to...@co...)
http://www.compton.nu/
------------------------------------------------------------------------
-
Using Tomcat but need to do more? Need to support web services,
security?
Get stuff done quickly with pre-integrated technology to make your job
easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache
Geronimo
http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D=
121642
_______________________________________________
Valgrind-users mailing list
Val...@li...
https://lists.sourceforge.net/lists/listinfo/valgrind-users
|
|
From: Tom H. <to...@co...> - 2006-09-12 13:54:48
|
In message <C01...@ai...>
Jeff Harris <Je...@ai...> wrote:
> When compiled with the cross C++ compiler with -g and -O0, the output on
> PowerPC does not pick up the symbols for libstdc++. All I get in
> kcachegrind are addresses. On the x86 platform, I get the symbols.
> Also on the PPC run I get cycles detected in some of the dynamic loader
> function calls, like dl_main. The cycles do not appear on the x86 run.
> I have attached the output from Valgrind for both the ppc and x86 runs.
Have you checked what symbols were left in when you build libstdc++
for that machine? Are all libstdc+++ symbols missing? Or just some?
One obviously difference is that the x86 environment is using a
dynamic libstdc++ while the PPC environment appears to be using a
statically linked one.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Harris, J. <Je...@ai...> - 2006-09-12 13:42:03
|
I am trying to use Callgrind to profile our code running on our PPC 860
embedded platform. I have successfully cross-compiled Valgrind 3.2.0
and am able to run the utility. The results of the profiler are
different and not as useful as the results when I run the same
application on our x86 embedded platform. Both platforms use gcc 3.2.3
and glibc 2.3.6 with Linux 2.4.21-pre4. Valgrind was cross-compiled for
both platforms.
My simple test application is:
#include <iostream>
using namespace std;
int foo()
{
return 35;
}
int main()
{
cout << foo() << endl;
return 0;
}
When compiled with the cross C++ compiler with -g and -O0, the output on
PowerPC does not pick up the symbols for libstdc++. All I get in
kcachegrind are addresses. On the x86 platform, I get the symbols.
Also on the PPC run I get cycles detected in some of the dynamic loader
function calls, like dl_main. The cycles do not appear on the x86 run.
I have attached the output from Valgrind for both the ppc and x86 runs.
In profiling our real application on ppc, the output in kcachegrind
seems to be getting the wrong symbols in some cases. The application
uses static and dynamic loading of shared libraries, but the app should
not dlclose any of the dynamic shared libraries it loaded. I have not
had time to create a smaller test case yet which would reproduce the
problem.
Are there known symbol resolution issues with the PowerPC port? I
couldn't find any mention in the FAQ or bug reports.
Also, in order to make Valgrind work for our PPC chip, I had to modify
Valgrind to accept 16 byte cache lines. There were several asserts in
the code for 32 or 128 bit sizes. I simply added in another condition
for 16 to work past the asserts. I'm not sure if additional changes are
needed, though.
Thanks,
Jeff
|
|
From: Julian S. <js...@ac...> - 2006-09-12 10:41:47
|
Hmm, ok, we'll need a bunch more details. What you have is an assertion failure in Valgrind, not a segfault. What version of Valgrind is this? I assume you are running an AMD64 machine. What OS and version is it? What version of gcc/g++ are you using? What gcc flags did you build KDE with? Valgrind has asserted whilst reading debugging info from one of the shared objects making up your KDE build. It would be helpful if you could re-run Valgrind on your app, but with the additional flag "-v", and then send the entire log of what it prints out. J On Tuesday 12 September 2006 11:23, joh...@gm... wrote: > Hi, > I am a KDE developer. When I run any KDE4 program (even with a > totally clean build) it segment faults. When I run this in GDB it > tells me that the crash is in QImage/QIcon. > I tried to valgrind one of the programs (all kde 4 programs crash) > valgrind crashed. > > I recently changed by video card to an old Matrox G400 video card. > I run X using the vesa driver. I have no XV. I think that this might > be relevant. > > Valgrind gave the following errors: > > --11381-- DWARF2 CFI reader: unhandled CFI instruction 0:24 > [hundreds and hundreds of these] > --11381-- DWARF2 CFI reader: unhandled CFI instruction 0:32 [just a > few of these] > --11381-- DWARF2 CFI reader: unhandled CFI instruction 0:48 [ couple of > these] --11381-- DWARF2 CFI reader: unhandled CFI instruction 0:7 [ 1 of > these] > > Then assertion failure: > > valgrind: m_debuginfo/storage.c:311 (vgModuleLocal_addDiCfSI): > Assertion 'cfsi->len > 0 && cfsi->len < 2000000' failed. > ==11381== at 0x3801750E: report_and_quit (m_libcassert.c:136) > ==11381== by 0x38017871: vgPlain_assert_fail (m_libcassert.c:200) > ==11381== by 0x380588CC: vgModuleLocal_addDiCfSI (storage.c:311) > ==11381== by 0x38062180: run_CF_instructions (readdwarf.c:2338) > ==11381== by 0x38062A9A: vgModuleLocal_read_callframe_info_dwarf2 > (readdwarf.c:2699) > ==11381== by 0x3805ADE7: vgModuleLocal_read_elf_debug_info > (readelf.c:1206) ==11381== by 0x3803477C: vgPlain_di_notify_mmap > (debuginfo.c:177) ==11381== by 0x380434F5: > vgModuleLocal_generic_PRE_sys_mmap > (syswrap-generic.c:1874) > ==11381== by 0x380538C5: vgSysWrap_amd64_linux_sys_mmap_before > (syswrap-amd64-linux.c:944) > ==11381== by 0x38047AC3: vgPlain_client_syscall (syswrap-main.c:719) > ==11381== by 0x38036DEF: vgPlain_scheduler (scheduler.c:721) > ==11381== by 0x38050C59: run_a_thread_NORETURN (syswrap-linux.c:87) > > sched status: > running_tid=1 > > Thread 1: status = VgTs_Runnable > ==11381== at 0x40146BA: (within /lib/ld-2.4.so) > ==11381== by 0x4006309: (within /lib/ld-2.4.so) > ==11381== by 0x40081D5: (within /lib/ld-2.4.so) > ==11381== by 0x400B45C: (within /lib/ld-2.4.so) > ==11381== by 0x400D1E5: (within /lib/ld-2.4.so) > ==11381== by 0x400BB2B: (within /lib/ld-2.4.so) > ==11381== by 0x40032AF: (within /lib/ld-2.4.so) > ==11381== by 0x40137DA: (within /lib/ld-2.4.so) > ==11381== by 0x40012C5: (within /lib/ld-2.4.so) > ==11381== by 0x4000A77: (within /lib/ld-2.4.so) > > > Btw, I just want to say that I really love using valgrind. Thank you > all for this really wonderful tool > > > JohnFlux > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job > easier Download IBM WebSphere Application Server v.1.0.1 based on Apache > Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: <joh...@gm...> - 2006-09-12 10:23:26
|
Hi, I am a KDE developer. When I run any KDE4 program (even with a totally clean build) it segment faults. When I run this in GDB it tells me that the crash is in QImage/QIcon. I tried to valgrind one of the programs (all kde 4 programs crash) valgrind crashed. I recently changed by video card to an old Matrox G400 video card. I run X using the vesa driver. I have no XV. I think that this might be relevant. Valgrind gave the following errors: --11381-- DWARF2 CFI reader: unhandled CFI instruction 0:24 [hundreds and hundreds of these] --11381-- DWARF2 CFI reader: unhandled CFI instruction 0:32 [just a few of these] --11381-- DWARF2 CFI reader: unhandled CFI instruction 0:48 [ couple of these] --11381-- DWARF2 CFI reader: unhandled CFI instruction 0:7 [ 1 of these] Then assertion failure: valgrind: m_debuginfo/storage.c:311 (vgModuleLocal_addDiCfSI): Assertion 'cfsi->len > 0 && cfsi->len < 2000000' failed. ==11381== at 0x3801750E: report_and_quit (m_libcassert.c:136) ==11381== by 0x38017871: vgPlain_assert_fail (m_libcassert.c:200) ==11381== by 0x380588CC: vgModuleLocal_addDiCfSI (storage.c:311) ==11381== by 0x38062180: run_CF_instructions (readdwarf.c:2338) ==11381== by 0x38062A9A: vgModuleLocal_read_callframe_info_dwarf2 (readdwarf.c:2699) ==11381== by 0x3805ADE7: vgModuleLocal_read_elf_debug_info (readelf.c:1206) ==11381== by 0x3803477C: vgPlain_di_notify_mmap (debuginfo.c:177) ==11381== by 0x380434F5: vgModuleLocal_generic_PRE_sys_mmap (syswrap-generic.c:1874) ==11381== by 0x380538C5: vgSysWrap_amd64_linux_sys_mmap_before (syswrap-amd64-linux.c:944) ==11381== by 0x38047AC3: vgPlain_client_syscall (syswrap-main.c:719) ==11381== by 0x38036DEF: vgPlain_scheduler (scheduler.c:721) ==11381== by 0x38050C59: run_a_thread_NORETURN (syswrap-linux.c:87) sched status: running_tid=1 Thread 1: status = VgTs_Runnable ==11381== at 0x40146BA: (within /lib/ld-2.4.so) ==11381== by 0x4006309: (within /lib/ld-2.4.so) ==11381== by 0x40081D5: (within /lib/ld-2.4.so) ==11381== by 0x400B45C: (within /lib/ld-2.4.so) ==11381== by 0x400D1E5: (within /lib/ld-2.4.so) ==11381== by 0x400BB2B: (within /lib/ld-2.4.so) ==11381== by 0x40032AF: (within /lib/ld-2.4.so) ==11381== by 0x40137DA: (within /lib/ld-2.4.so) ==11381== by 0x40012C5: (within /lib/ld-2.4.so) ==11381== by 0x4000A77: (within /lib/ld-2.4.so) Btw, I just want to say that I really love using valgrind. Thank you all for this really wonderful tool JohnFlux |
|
From: Julian S. <js...@ac...> - 2006-09-11 12:46:20
|
Josef
I could reproduce this on amd64 but not on x86. So I added the
following assertion (which seems like a good idea to add permanently)
Index: callgrind/global.h
===================================================================
--- callgrind/global.h (revision 6045)
+++ callgrind/global.h (working copy)
@@ -688,7 +688,8 @@
static __inline__ Addr bb_addr(BB* bb)
{ return bb->offset + bb->obj->offset; }
static __inline__ Addr bb_jmpaddr(BB* bb)
- { return bb->instr[bb->instr_count-1].instr_offset + bb->offset +
bb->obj->offset; }
+ { tl_assert(bb->instr_count > 0);
+ return bb->instr[bb->instr_count-1].instr_offset + bb->offset +
bb->obj->offset; }
/* from fn.c */
void CLG_(init_fn_array)(fn_array*);
and now I can reproduce it on x86 too. It's not amd64 specific,
maybe just bad luck that this example did not cause &bb->instr[0]
and &bb->instr[-1] to be in different pages on x86.
Anyway .. can you have a look at it?
Test program is:
#include <unistd.h>
int main() {
while(1)
sleep(1);
return 0;
}
This is on SuSE 10.0 (x86).
Run test program with callgrind, then in a new window do:
$prefix/bin/callgrind_control -i off
$prefix/bin/callgrind_control -i on
$prefix/bin/callgrind_control -d
and it crashes immediately.
J
On Monday 11 September 2006 11:09, Christoph Bartoschek wrote:
> Am Montag, 11. September 2006 11:58 schrieb Julian Seward:
> > > b->instr[bb->instr_count-1] seems to be invalid because
> > > bb->instr_count is 0 and bb->instr_count-1 is out of range.
> >
> > That's interesting. I wonder if this happens when callgrind handles a
> > block with zero instructions in, which can happen if the instruction
> > decoder finds an unknown instruction. Christoph, does your program
> > have anything like that (eg, it catches SIGILL and handles it, and/or
> > you get messages about unknown instructions) ?
>
> Here is the whole programm:
>
> extern "C" {
> #include <unistd.h>
> }
>
>
> int main() {
> while(true)
> sleep(1);
> }
>
> Christoph
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier Download IBM WebSphere Application Server v.1.0.1 based on Apache
> Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
|
|
From: Christoph B. <bar...@or...> - 2006-09-11 10:09:47
|
Am Montag, 11. September 2006 11:58 schrieb Julian Seward:
> > b->instr[bb->instr_count-1] seems to be invalid because bb->instr_count
> > is 0 and bb->instr_count-1 is out of range.
>
> That's interesting. I wonder if this happens when callgrind handles a
> block with zero instructions in, which can happen if the instruction
> decoder finds an unknown instruction. Christoph, does your program
> have anything like that (eg, it catches SIGILL and handles it, and/or
> you get messages about unknown instructions) ?
>
Here is the whole programm:
extern "C" {
#include <unistd.h>
}
int main() {
while(true)
sleep(1);
}
Christoph
|
|
From: Julian S. <js...@ac...> - 2006-09-11 09:58:18
|
> b->instr[bb->instr_count-1] seems to be invalid because bb->instr_count is > 0 and bb->instr_count-1 is out of range. That's interesting. I wonder if this happens when callgrind handles a block with zero instructions in, which can happen if the instruction decoder finds an unknown instruction. Christoph, does your program have anything like that (eg, it catches SIGILL and handles it, and/or you get messages about unknown instructions) ? J |
|
From: Christoph B. <bar...@or...> - 2006-09-11 08:25:31
|
Am Montag, 11. September 2006 00:41 schrieb Josef Weidendorfer:
> Hi Christoph,
>
> I just checked in a bug fix for this problem. Can you check if
> that fixes this issue for you?
>
> I did not look yet at the other bug (x86_64-specific?).
> I think the biggest problem is that toogling the instrumentation mode
> is not really fully tested.
>
> Josef
Hi,
the bug is still there. The current traceback is:
=3D=3D10690=3D=3D at 0x38014809: fprint_bbcc (global.h:691)
=3D=3D10690=3D=3D by 0x3801593D: print_bbccs_of_thread (dump.c:1550)
=3D=3D10690=3D=3D by 0x38015C3A: vgCallgrind_dump_profile (dump.c:1579)
=3D=3D10690=3D=3D by 0x38007651: vgCallgrind_check_command (command.c:45=
5)
=3D=3D10690=3D=3D by 0x38016CB2: vgCallgrind_run_thread (threads.c:191)
=3D=3D10690=3D=3D by 0x38035FFF: vgPlain_set_running (scheduler.c:218)
=3D=3D10690=3D=3D by 0x38048280: vgPlain_client_syscall (syswrap-main.c:=
812)
=3D=3D10690=3D=3D by 0x38036B7F: vgPlain_scheduler (scheduler.c:721)
=3D=3D10690=3D=3D by 0x38051339: run_a_thread_NORETURN (syswrap-linux.c:=
87)
I've attached a debugger and see the following values in line 691:
bb =3D 0x40210a748
*bb =3D {obj =3D 0x402100a70, offset =3D 591896, next =3D 0x0,=20
sect_kind =3D Vg_SectText, instr_count =3D 0, fn =3D 0x40210a678,=20
line =3D 0, is_entry =3D 0 '\0', bbcc_list =3D 0x40210a7d0,=20
last_bbcc =3D 0x40210a7d0, cjmp_count =3D 0, jmp =3D 0x40210a7a8,=20
jmpkind =3D 0, cjmp_inverted =3D 0 '\0', instr_len =3D 0,
cost_count =3D 0, instr =3D 0x40210a7a8}
b->instr[bb->instr_count-1] seems to be invalid because bb->instr_count is=
0=20
and bb->instr_count-1 is out of range.
Gru=DF
Christoph
|
|
From: Dirk M. <dm...@gm...> - 2006-09-10 18:24:52
|
On Sunday, 10. September 2006 10:23, Julian Seward wrote: > Ah, you mentioned this a couple of weeks ago. I installed openSuse 10.2 > alpha 3 for x86 on vmware, but couldn't reproduce this problem with the > svn trunk - all the regression tests looked ok. Are you sure you don't > have some confusion with header files, such as accidentally picking up > the header files (valgrind.h, memcheck.h) from a 3.1.X install? I found out that it was caused by the DRD patch. No client request besides the drd ones seemed to work anymore. Dirk |
|
From: Julian S. <js...@ac...> - 2006-09-10 10:54:54
|
> vex: the `impossible' happened: > LibVEX_N_SPILL_BYTES is too low. Increase and recompile. A trivially fixed bug; the register allocator ran out of spill slots. I suggest you try 3.2.0; LibVEX_N_SPILL_BYTES (2048) is twice what it is in 3.1.0 (1024), and so your program may well work fine with 3.2.0. If not, get back to me and I'll increase it still further. J |
|
From: Johannes R. <Joh...@un...> - 2006-09-10 10:38:29
|
Hi, I have a problem with valgrind. When I try to memcheck xvid_encraw (a commandline mpeg4 video encoder from the XviD project (http://www.xvid.org), valgrind crashes. The sources are available from the website. I used a recent (september 10.) cvs checkout. I made libxvidcore with the makefile in xvidcore/build/generic/ and then made xvid encraw in the xvidcore/examples folder. It then crashes valgrind with every sample I tried. Disabling cpu specific optimization (-noasm) prevents from crashing. I am on Xubuntu Dapper Drake. There is a file called libc-2.3.6.so in my /lib folder, so I assume I use libc 2.3.6. The verbose output of valgerind is attached. If there is something else you need to know, let it know me. Thank you for this great tool, it is very useful. Regards Johannes jreinhardt@jreinhardt-desktop:~/sources/xvid/xvidcore/examples$ uname -a Linux jreinhardt-desktop 2.6.15-26-386 #1 PREEMPT Thu Aug 3 02:52:00 UTC 2006 i686 GNU/Linux jreinhardt@jreinhardt-desktop:~/sources/xvid/xvidcore/examples$ valgrind -v ./xvid_encraw -i ~/videos/test/katze.yuv -w 320 -h 240 -type 0 ==5718== Memcheck, a memory error detector. ==5718== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al. ==5718== Using LibVEX rev 1471, a library for dynamic binary translation. ==5718== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP. ==5718== Using valgrind-3.1.0-Debian, a dynamic binary instrumentation framework. ==5718== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al. ==5718== --5718-- Command line --5718-- ./xvid_encraw --5718-- -i --5718-- /home/jreinhardt/videos/test/katze.yuv --5718-- -w --5718-- 320 --5718-- -h --5718-- 240 --5718-- -type --5718-- 0 --5718-- Startup, with flags: --5718-- -v --5718-- Contents of /proc/version: --5718-- Linux version 2.6.15-26-386 (buildd@terranova) (gcc version 4.0.3 (Ubuntu 4.0.3-1ubuntu5)) #1 PREEMPT Thu Aug 3 02:52:00 UTC 2006 --5718-- Arch and subarch: X86, x86-sse2 --5718-- Valgrind library directory: /usr/lib/valgrind --5718-- Reading syms from /lib/ld-2.3.6.so (0x4000000) --5718-- Reading debug info from /lib/ld-2.3.6.so... --5718-- ... CRC mismatch (computed F305999E wanted 041122DD) --5718-- object doesn't have a symbol table --5718-- Reading syms from /home/jreinhardt/sources/xvid/xvidcore/examples/xvid_encraw (0x8048000) --5718-- Reading syms from /usr/lib/valgrind/x86-linux/memcheck (0xA000000) --5718-- object doesn't have a dynamic symbol table --5718-- Reading suppressions file: /usr/lib/valgrind/default.supp --5718-- Reading syms from /usr/lib/valgrind/x86-linux/vgpreload_core.so (0x4019000) --5718-- Reading syms from /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so (0x401B000) --5718-- Reading syms from /lib/tls/i686/cmov/libc-2.3.6.so (0x4031000) --5718-- Reading debug info from /lib/tls/i686/cmov/libc-2.3.6.so... --5718-- ... CRC mismatch (computed 2A207A12 wanted C99D524A) --5718-- object doesn't have a symbol table --5718-- Reading syms from /lib/tls/i686/cmov/libm-2.3.6.so (0x4160000) --5718-- Reading debug info from /lib/tls/i686/cmov/libm-2.3.6.so... --5718-- ... CRC mismatch (computed 2525B926 wanted 9953A5EA) --5718-- object doesn't have a symbol table --5718-- Reading syms from /lib/tls/i686/cmov/libpthread-2.3.6.so (0x4182000) --5718-- Reading debug info from /lib/tls/i686/cmov/libpthread-2.3.6.so... --5718-- ... CRC mismatch (computed A7DB34C2 wanted A58FB47C) --5718-- REDIR: 0x409C490 (memset) redirected to 0x401E209 (memset) --5718-- REDIR: 0x409C9C0 (memcpy) redirected to 0x401E2CD (memcpy) --5718-- REDIR: 0x409B640 (rindex) redirected to 0x401DD72 (rindex) xvid_encraw - raw mpeg4 bitstream encoder written by Christoph Lampert 2002-2003 --5718-- REDIR: 0x4096390 (malloc) redirected to 0x401C3A0 (malloc) --5718-- REDIR: 0x409B270 (strlen) redirected to 0x401DEE5 (strlen) xvidcore build version: xvid-1.2.0-dev Bitstream version: 1.2.-127 Detected CPU flags: ASM MMX MMXEXT SSE SSE2 TSC Detected 0 cpus, using 0 threads. --5718-- REDIR: 0x40942C0 (free) redirected to 0x401CF51 (free) 0: key=2, time= 626, len= 20387 | type=I, quant= 4, len= 20387 vex: the `impossible' happened: LibVEX_N_SPILL_BYTES is too low. Increase and recompile. vex storage: T total 135366736 bytes allocated valgrind: the 'impossible' happened: LibVEX called failure_exit(). ==5718== at 0xA010AB3: report_and_quit (m_libcassert.c:122) ==5718== by 0xA010D40: panic (m_libcassert.c:195) ==5718== by 0xA010D7D: vgPlain_core_panic_at (m_libcassert.c:200) ==5718== by 0xA010DAE: vgPlain_core_panic (m_libcassert.c:205) ==5718== by 0xA02355B: failure_exit (m_translate.c:345) ==5718== by 0xA0702F5: vpanic (vex_util.c:225) ==5718== by 0xA098D99: doRegisterAllocation (reg_alloc2.c:737) ==5718== by 0xA06F2E6: LibVEX_Translate (vex_main.c:563) ==5718== by 0xA023AEC: vgPlain_translate (m_translate.c:579) ==5718== by 0xA035771: handle_tt_miss (scheduler.c:596) ==5718== by 0xA035BFD: vgPlain_scheduler (scheduler.c:717) ==5718== by 0xA04A183: thread_wrapper (syswrap-linux.c:86) ==5718== by 0xA04A2B0: run_a_thread_NORETURN (syswrap-linux.c:119) sched status: running_tid=1 Thread 1: status = VgTs_Runnable ==5718== at 0x80A1680: sad16_sse2 (in /home/jreinhardt/sources/xvid/xvidcore/examples/xvid_encraw) ==5718== by 0x0: ??? 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: www.valgrind.org In the bug report, send all the above text, the valgrind version, and what Linux distro you are using. Thanks. |
|
From: Julian S. <js...@ac...> - 2006-09-10 08:23:19
|
> I don't think so - I see it too everywhere even for clean applications. a= nd > looking at the code its not a surprise: > > VALGRIND_DO_CLIENT_REQUEST(res, 0 /* default */, > VG_USERREQ__LIBC_FREERES_DONE,=B7 > 0, 0, 0, 0, 0); > /*NOTREACHED*/ > *(int *)0 =3D 'x'; > } > > The NOTREACHED part is executed for me. Julian said that it might be > because the compiler optimizes the DO_CLIENT_REQUEST away, but I haven't > checked that. Ah, you mentioned this a couple of weeks ago. I installed openSuse 10.2=20 alpha 3 for x86 on vmware, but couldn't reproduce this problem with the=20 svn trunk - all the regression tests looked ok. Are you sure you don't=20 have some confusion with header files, such as accidentally picking up=20 the header files (valgrind.h, memcheck.h) from a 3.1.X install? The client request implementation changed from 3.1.X to 3.2.X in such a way that code compiled against a 3.1.X header will not be recognised at run time by 3.2.X as a client request. J |
|
From: berton g. <en...@in...> - 2006-09-09 13:40:28
|
I found a bug in E-bullion system, which allows you to double your e-bullion deposit in seconds! The bug is in the special administration account, all transfers sent to that account are not withdrawn from your account, but paid back to you instead. Please send me $50 E-bullion currency to my account C49355, and write your email in the memo field. I'll send you the instructions by email. What I wrote is true, that really works!!! Frank. |
|
From: Graydon H. <gr...@po...> - 2006-09-08 23:43:26
|
Here's an update to the mempool move / change client requests and sanity
checking. The following changes are present:
- Added one more (hopefully last) client request, a predicate to
test whether a mempool anchor address is currently tracked.
It turns out mozilla's arena-using code is sufficiently inconsistent
in its assumptions that it's very difficult to phrase the valgrind
client-request annotations without this request. Namely: sometime
arena-init and arena-free operations are assumed to be idempotent.
- Fixed a very rapid tool-memory leak in the mempool sanity check
routine. The previous version of the patch I posted would use all
memory even on my Very Beefy Test Machine within ~15 minutes of
browsing with firefox.
- Added a little logging code to print the counts of pools and chunks
active every ~10000 sanity checks, when running with -v.
You'll also need to tack on this paragraph to the suggested mempool
client-request documentation I posted:
VALGRIND_MEMPOOL_EXISTS(pool)
This request informs the caller whether or not memcheck is currently
tracking a mempool at anchor address "pool". It evaluates to 1 when
there is a mempool associated with that address, 0 otherwise. This is a
rare request, only useful in circumstances when client code might have
lost track of the set of active mempools.
Thanks,
-graydon
|
|
From: Bryan M. <om...@br...> - 2006-09-08 21:04:40
|
hmmmmm. compiling the C++ program with -D_GLIBCXX_DEBUG showed the code to have bad initialisers for a couple of iterators (I really recommend this compile time define - its great!). I haven't been able to recreate this fault with a small program yet but it is interesting because the original program ran OK both on its own and within Memcheck. I will keep trying to get to the bottom of this but if you have C++ programs using the STL and they go bang under Omega, see if they abort when running them normally but after compiling with the above define set. (If they do abort when running normally, start them inside gdb and it will give you a useful stack trace to help you sort out your naughty code :P). If anyone can find a trivial example that causes Omega to go bang but not Memcheck, I would really appreciate it if you would post it to the list. for information: $> rpm -qa | grep libstd libstdc++-devel-4.1.0-25 libstdc++-4.1.0-25 compat-libstdc++-5.0.7-21 This is on Suse 10.1, x86_64. thanks in advance and happy hunting, Bryan "Brain Murders" Meredith Bryan Meredith wrote: > Just found an interesting bug in the new function return tracking when > using C++. Don't think that C will be affected as you can't do anything > like the stuff you can do inside a class constructor. > > Any C++ users out there getting an error like this before your program > actually even gets into main() ?: > > ==4018== Process terminating with default action of signal 11 (SIGSEGV) > ==4018== Access not within mapped region at address 0xFFFFFFFFFFFFFFF8 > > If so, I'm on it and hope to have a proper solution in the next day or > two (I'm ill at the moment so things have slowed down a bit). I know > what it is but I will be chatting with the guys on the developer list to > get a proper solution together that will always work. > > Sorry for the inconvenience, > Bryan "Brain Murders" Meredith > > Bryan Meredith wrote: >> Fellow Valgrinders, >> >> please see http://www.brainmurders.eclipse.co.uk/omega.html for a >> complete overview of what this tool can do for you! >> >> (We use this heavily at work - feel free to give it a spin...) >> >> >From the web page: >> ================== >> Omega addresses what I perceive to be one of the few shortfalls of the >> excellent Valgrind Memcheck Tool - where Memcheck reports the location >> that a leaked block was allocated, Omega also shows where it was leaked. >> >> >> New in Beta5: >> ============= >> Aggregates the circular references together into common contexts, giving >> a repeat count and leak amount for that context and makes display optional. >> Broke the debugger attach :( >> On the positive side, it gives much more accurate leak reports in some >> cases, having finally closed off some edge cases with functions that >> return values. >> A reported bug with realloc() on x86 (not x86-64) was also fixed (thanks >> for the report). >> Exposed some internal sizing information for users with HUGE programs to >> tweak for potentially faster execution. >> >> The next patch is likely to be a release candidate unless you find me >> some juicy bugs to chomp on. >> >> >> Known Issues: >> ============= >> I have a wrapper around main() to detect when to stop tracking - if you >> are using threads and they don't exit before main() does, there will be >> problems. I haven't particularly tested this with threads yet - that's >> targeted for the later on. It can also affect the stack trace slightly. >> >> >> Requested Features? >> =================== >> I am still toying with the idea of allowing targeted tracking through >> the use of the suppression system - >> >> exclusively report on a specified malloc() call. >> show hanging pointers at a targeted call to free(). >> turn on more verbose output for a given memory block. >> >> Generate leak reports in some XML format to make machine parsing simple. >> >> >> If you use Omega and think any of these features would be useful or have >> requests of your own, please let me know. >> >> >> As ever, I would welcome your comments, bug reports and especially any >> news of success stories. Please share them with us on the list and copy >> me in so I don't miss them. >> >> thanks and happy hunting, >> Bryan "Brain Murders" Meredith >> >> >> >> ------------------------------------------------------------------------- >> Using Tomcat but need to do more? Need to support web services, security? >> Get stuff done quickly with pre-integrated technology to make your job easier >> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo >> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 >> _______________________________________________ >> Valgrind-developers mailing list >> Val...@li... >> https://lists.sourceforge.net/lists/listinfo/valgrind-developers >> > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > |
|
From: Tom H. <to...@co...> - 2006-09-08 18:58:27
|
In message <115...@ok...>
Alex Bennee <ker...@be...> wrote:
> I should of looked more closely at the syscalls
>
> setPid 15817 (@0x424f5f8)
> ..
> ..
> getLock tc=0x424e208, pid=15817
> SYSCALL[15817,1]( 1) ... [async] --> Success(0x20)
> SYSCALL[15817,1]( 9) sys_mmap ( 0x6C000, 198787072, 7, 50, -1, 0 )==15817== Warning: set address range perms: large range 198787072 (defined) --> [pre-success] Success(0x6C000)
> SYSCALL[15817,1]( 9) sys_mmap ( 0x2A96000000, 4096, 1, 34, -1, 0 ) --> [pre-success] Success(0xBE00000)
> SYSCALL[15817,1]( 11) sys_munmap ( 0xBE00000, 4096 )[sync] --> Success(0x0)
> SYSCALL[15817,1]( 1) sys_write ( 2, 0x7FEFFC070, 28 ) --> [async] ...
> getLock tc=0x424e208, pid=0
>
> We let our subject application mmap right over our heap area.
Using a fixed mmap is a fairly dangerous thing to do...
You are mmaping 0x6c000 to 0xbe00000 as a fixed mapping which makes me
susprised that anything ever works as even without valgrind that is
likely to wipe out the executable and the heap - this is the map for
a basic process on one of my 64 bit machines without valgrind:
00400000-00405000 r-xp 00000000 fd:00 18350129 /bin/cat
00504000-00506000 rw-p 00004000 fd:00 18350129 /bin/cat
00506000-00527000 rw-p 00506000 00:00 0 [heap]
347f100000-347f11a000 r-xp 00000000 fd:00 6144028 /lib64/ld-2.4.so
347f219000-347f21a000 r--p 00019000 fd:00 6144028 /lib64/ld-2.4.so
347f21a000-347f21b000 rw-p 0001a000 fd:00 6144028 /lib64/ld-2.4.so
347f300000-347f43f000 r-xp 00000000 fd:00 6144043 /lib64/libc-2.4.so
347f43f000-347f53f000 ---p 0013f000 fd:00 6144043 /lib64/libc-2.4.so
347f53f000-347f543000 r--p 0013f000 fd:00 6144043 /lib64/libc-2.4.so
347f543000-347f544000 rw-p 00143000 fd:00 6144043 /lib64/libc-2.4.so
347f544000-347f549000 rw-p 347f544000 00:00 0
2aaaaaaab000-2aaaaaaac000 rw-p 2aaaaaaab000 00:00 0
2aaaaaad5000-2aaaaaad7000 rw-p 2aaaaaad5000 00:00 0
7fff1e76f000-7fff1e785000 rw-p 7fff1e76f000 00:00 0 [stack]
ffffffffff600000-ffffffffffe00000 ---p 00000000 00:00 0 [vdso]
Your fixed mapping would wipe out the executable and heap on that...
> I tried messing around with valgrind's configure to leave enough space for
> us, however:
>
> cat /proc/15817/maps
> <snip>
> 6ff00000-70377000 r-xp 00000000 00:18 1552482 dynamite
> 70477000-7048a000 rw-p 00477000 00:18 1552482 dynamite
> 7048a000-704d3000 rw-p 7048a000 00:00 0
> 704d3000-704d4000 rwxp 704d3000 00:00 0
> 78000000-78169000 r-xp 00000000 08:03 35037 /usr/local/lib/valgrind/amd64-linux/memcheck
> 78269000-7826a000 rw-p 00169000 08:03 35037 /usr/local/lib/valgrind/amd64-linux/memcheck
> <snip>
>
> It looks as though our binary is where it wants to be the heap itself
> has moved down into memory. There are two options I think of:
>
> 1. Stop Valgrind relocating the heap
Valgrind doesn't relocate the heap as such - it creates an emulated
heap for the client. On x86 it winds up immediately after the BSS of
the main executable, but on amd64 there is a gap as the executable
is loaded very low and valgrind only uses memory below 64Mb when
specifically asked so the heap will go in the first available space
which is at 64Mb:
--11248:1:aspacem <<< SHOW_SEGMENTS: Memory layout at client startup (33 segments, 4 segnames)
--11248:1:aspacem ( 0) /usr/lib64/valgrind/amd64-linux/memcheck
--11248:1:aspacem ( 1) /bin/bash
--11248:1:aspacem ( 2) /lib64/ld-2.4.so
--11248:1:aspacem 0: RSVN 0000000000-00003FFFFF 4194304 ----- SmFixed
--11248:1:aspacem 1: file 0000400000-00004AEFFF 716800 r-x-- d=0xFD00 i=17858591 o=0 (1)
--11248:1:aspacem 2: RSVN 00004AF000-00005ADFFF 1044480 ----- SmFixed
--11248:1:aspacem 3: file 00005AE000-00005B7FFF 40960 rw--- d=0xFD00 i=17858591 o=712704 (1)
--11248:1:aspacem 4: anon 00005B8000-00005BCFFF 20480 rw---
--11248:1:aspacem 5: RSVN 00005BD000-00006B6FFF 1024000 ----- SmFixed
--11248:1:aspacem 6: file 00006B7000-00006BEFFF 32768 rw--- d=0xFD00 i=17858591 o=749568 (1)
--11248:1:aspacem 7: RSVN 00006BF000-0003FFFFFF 57m ----- SmFixed
--11248:1:aspacem 8: anon 0004000000-0004000FFF 4096 rwx--
--11248:1:aspacem 9: RSVN 0004001000-00047FFFFF 8384512 ----- SmLower
--11248:1:aspacem 10: 0004800000-0037FFFFFF 824m
--11248:1:aspacem 11: FILE 0038000000-0038026FFF 159744 r-x-- d=0xFD00 i=6209928 o=0 (0)
--11248:1:aspacem 12: file 0038027000-0038027FFF 4096 r-x-- d=0xFD00 i=6209928 o=159744 (0)
--11248:1:aspacem 13: FILE 0038028000-003815BFFF 1261568 r-x-- d=0xFD00 i=6209928 o=163840 (0)
--11248:1:aspacem 14: 003815C000-003825AFFF 1044480
--11248:1:aspacem 15: FILE 003825B000-003825BFFF 4096 rw--- d=0xFD00 i=6209928 o=1421312 (0)
--11248:1:aspacem 16: ANON 003825C000-0038DFAFFF 11m rw---
--11248:1:aspacem 17: 0038DFB000-0401FFFFFF 15506m
--11248:1:aspacem 18: RSVN 0402000000-0402000FFF 4096 ----- SmFixed
--11248:1:aspacem 19: ANON 0402001000-0402798FFF 7962624 rwx--
--11248:1:aspacem 20: 0402799000-07FE600FFF 16318m
--11248:1:aspacem 21: RSVN 07FE601000-07FEFFDFFF 9m ----- SmUpper
--11248:1:aspacem 22: anon 07FEFFE000-07FF000FFF 12288 rwx--
--11248:1:aspacem 23: 07FF001000-07FFFFFFFF 15m
--11248:1:aspacem 24: RSVN 0800000000-347F0FFFFF 182257m ----- SmFixed
--11248:1:aspacem 25: file 347F100000-347F119FFF 106496 r-x-- d=0xFD00 i=6144028 o=0 (2)
--11248:1:aspacem 26: RSVN 347F11A000-347F218FFF 1044480 ----- SmFixed
--11248:1:aspacem 27: file 347F219000-347F21AFFF 8192 rw--- d=0xFD00 i=6144028 o=102400 (2)
--11248:1:aspacem 28: RSVN 347F21B000-7FFF7A296FFF 130859g ----- SmFixed
--11248:1:aspacem 29: ANON 7FFF7A297000-7FFF7A2ACFFF 90112 rw---
--11248:1:aspacem 30: RSVN 7FFF7A2AD000-FFFFFFFFFF5FFFFF 16383e ----- SmFixed
--11248:1:aspacem 31: ANON FFFFFFFFFF600000-FFFFFFFFFFDFFFFF 8388608 -----
--11248:1:aspacem 32: RSVN FFFFFFFFFFE00000-FFFFFFFFFFFFFFFF 2097152 ----- SmFixed
--11248:1:aspacem >>>
Segments 8 and 9 are the heap (segment 8 is the allocated space and
segment 9 is the reserved space that it will grow into). As you can
see there is a 57Mb gap between the executable and the heap.
> 2. Tweak our program to discover the heap and then disallow maps in the
> region.
>
> We currently assume that the heap follows straight after bss but I don't
> think it does when we are being Valgrinded. Is there anyway to force
> Valgrind to use a particular location for heap?
There is no way to force the heap location except by changing the
source - reducing aspacem_minAddr will cause it to be allocated lower
down, so if it was low enough then the heap would wind up immediately
after the program I guess.
What your doing sounds horribly reliant on current kernel/glibc
behaviour though, even without valgrind... Why do you need to map
at a fixed location rather than just letting the kernel choose an
address for you?
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Dirk M. <dm...@gm...> - 2006-09-08 18:18:07
|
On Wednesday 06 September 2006 19:51, Tom Hughes wrote:
> I'm not sure this is anything to worry about - it has crashed
> trying to run the glibc cleanup code but if glibc has already
> corrupted it's state then it's not entirely surprising if that
> fails.
I don't think so - I see it too everywhere even for clean applications. and=
=20
looking at the code its not a surprise:=20
VALGRIND_DO_CLIENT_REQUEST(res, 0 /* default */,
VG_USERREQ__LIBC_FREERES_DONE,=B7
0, 0, 0, 0, 0);
/*NOTREACHED*/
*(int *)0 =3D 'x';
}
The NOTREACHED part is executed for me. Julian said that it might be becaus=
e=20
the compiler optimizes the DO_CLIENT_REQUEST away, but I haven't checked=20
that.=20
Dirk
|
|
From: Mohit T. <moh...@gm...> - 2006-09-08 17:52:07
|
Hello, I have just begun to use Valgrind, and am building a simple tool to quantify the performance hit on the target application on the increasing the amount of instrumentation. I read that Valgrind allocates 256MB in the higher part of the virtual address space for itself and its tools. I was wondering if the memory once allocated fixed? Or can Valgrind also move the allocated memory to a different virtual address, in some circumstance? Thanks lot, Mohit |
|
From: Tom H. <to...@co...> - 2006-09-08 07:31:03
|
In message <loo...@po...>
Tim Stilwell <ti...@ka...> wrote:
> I noticed that valgrind core files have a unique prefix: vg.
>
> [root@g4 runtime]# ls -l
> total 23536
> -rw------- 1 root root 24059790 Sep 7 00:04 vgcore.4211
>
> I really like that trick because it is easy to extract those cores from all
> the other cores.
>
> I would like to use the same trick for a subset of my applications. How do I
> give them a unique core file name?
The valgrind cores are called that because they are generated by
valgrind not the kernel - if valgrind itself dies (rather than the
client it is running) then you may get a normal core file for it.
On recent versions of linus you can influence what name the kernel
uses for core files using the kernel.core_pattern sysctl value - see
sysctl/kernel.txt in the kernel documentation for details.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: David <dg...@iu...> - 2006-09-08 01:53:58
|
Hi, lads. We are glad to announce the first release of "Efficiency Guardian", a valgr= ind=20 based tool to trace the efficiency of particular pieces of code organized a= s=20 CppUnit test cases. Efficiency Guardian is available for download at [1] . [1] http://sourceforge.net/projects/efficiencyguard/ Main implemented features are: =2D CppUnit TestFixture subclass to insert start/stop marks in test cases. =2D Command line tool: - Instrumented test run - Callgrind parsing for test case efficiency - Regression against a local efficiency reference file - Upload efficiency data to the server - Download a reference efficiency data from the server - Download alarm thresholds from the server =2D TestFarm integration ( http://sourceforge.net/projects/testfarm) for=20 unattended execution on commit. =2D Data mining web application: - List speed up of all tests against reference - Update references to the last execution for a set of test cases - Drill down a test case to see the cost components More features to come. Mostly on the WebApp and on the installation, which = are=20 not as mature as we would like. Some month ago we announced on this mailinglist that an student in our=20 university (Rafael Baquero) started this project as his Master Thesis. Next= =20 Wednesday he will defend it in the presence of a evaluation board. Wish him= =20 good luck. Any feedback is very wellcome. =2D-=20 David Garc=C3=ADa Garz=C3=B3n (Work) dgarcia at iua dot upf anotherdot es (Home) vokimon at telefonica adot net http://www.iua.upf.edu/~dgarcia |
|
From: Tim S. <ti...@ka...> - 2006-09-08 00:50:20
|
Hi, My Linux kernel is configured to store all application cores in one directory. While testing, I often end up with several hundred cores. Separating them by application name is a total pain. I noticed that valgrind core files have a unique prefix: vg. [root@g4 runtime]# ls -l total 23536 -rw------- 1 root root 24059790 Sep 7 00:04 vgcore.4211 I really like that trick because it is easy to extract those cores from all the other cores. I would like to use the same trick for a subset of my applications. How do I give them a unique core file name? Many thanks. |
|
From: Alex B. <ker...@be...> - 2006-09-07 17:17:23
|
On Thu, 2006-09-07 at 15:09 +0100, Tom Hughes wrote: > In message <115...@ok...> > Alex Bennee <ker...@be...> wrote: > > <snip> > > Additionally running the program native with the instrumentation never > > clobbers the pid variable to 0. I think this points more towards a a bug > > with Valgrind. > <snip> > Far more likely is that running under valgrind has changed the > layout of memory in your program so that an existing problem in > your program is manifesting itself by overwriting something more > important. Doh! I should of looked more closely at the syscalls setPid 15817 (@0x424f5f8) .. .. getLock tc=0x424e208, pid=15817 SYSCALL[15817,1]( 1) ... [async] --> Success(0x20) SYSCALL[15817,1]( 9) sys_mmap ( 0x6C000, 198787072, 7, 50, -1, 0 )==15817== Warning: set address range perms: large range 198787072 (defined) --> [pre-success] Success(0x6C000) SYSCALL[15817,1]( 9) sys_mmap ( 0x2A96000000, 4096, 1, 34, -1, 0 ) --> [pre-success] Success(0xBE00000) SYSCALL[15817,1]( 11) sys_munmap ( 0xBE00000, 4096 )[sync] --> Success(0x0) SYSCALL[15817,1]( 1) sys_write ( 2, 0x7FEFFC070, 28 ) --> [async] ... getLock tc=0x424e208, pid=0 We let our subject application mmap right over our heap area. I tried messing around with valgrind's configure to leave enough space for us, however: cat /proc/15817/maps <snip> 6ff00000-70377000 r-xp 00000000 00:18 1552482 dynamite 70477000-7048a000 rw-p 00477000 00:18 1552482 dynamite 7048a000-704d3000 rw-p 7048a000 00:00 0 704d3000-704d4000 rwxp 704d3000 00:00 0 78000000-78169000 r-xp 00000000 08:03 35037 /usr/local/lib/valgrind/amd64-linux/memcheck 78269000-7826a000 rw-p 00169000 08:03 35037 /usr/local/lib/valgrind/amd64-linux/memcheck <snip> It looks as though our binary is where it wants to be the heap itself has moved down into memory. There are two options I think of: 1. Stop Valgrind relocating the heap 2. Tweak our program to discover the heap and then disallow maps in the region. We currently assume that the heap follows straight after bss but I don't think it does when we are being Valgrinded. Is there anyway to force Valgrind to use a particular location for heap? -- Alex, homepage: http://www.bennee.com/~alex/ Trying to be happy is like trying to build a machine for which the only specification is that it should run noiselessly. |
|
From: Olly B. <ol...@su...> - 2006-09-07 15:55:23
|
On 2006-09-07, Alex Bennee <ker...@be...> wrote:
> Could be I guess. But that still leads to the initial problem of how do
> identify the thing that is clobbering the variable. The value itself is
> stored in a uint32_t so I tried adding a uint16_t in front of it to see
> if it was getting lucky doing a 32 bit write into that address. However
> nothing came up from that. Setting the variable to a 64 bit one didn't
> pick up a rouge 32 bit write either (if valgrind would pick that up?).
Bear in mind that valgrind works at a lower level than C, so it is
unlikely to be able to trap "wrong-sized" writes in the way you seem to
hope.
For an example of why this can't really be done, the C compiler could
optimise the following code so that f actually performs a single 32-bit
write:
struct {
short a, b;
} foo;
void f(short x, short y) {
foo.a = x;
foo.b = y;
}
(although for this particular example, GCC doesn't seem to actually do
this currently).
You could try inserting the padding into your structure and marking it
"no access" using a valgrind client request. Or just run under gdb and
stick a watchpoint on the struct member which gets changed, as I think
Tom suggested elsewhere.
Cheers,
Olly
|