You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
(58) |
Apr
(261) |
May
(169) |
Jun
(214) |
Jul
(201) |
Aug
(219) |
Sep
(198) |
Oct
(203) |
Nov
(241) |
Dec
(94) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(137) |
Feb
(149) |
Mar
(150) |
Apr
(193) |
May
(95) |
Jun
(173) |
Jul
(137) |
Aug
(236) |
Sep
(157) |
Oct
(150) |
Nov
(136) |
Dec
(90) |
| 2005 |
Jan
(139) |
Feb
(130) |
Mar
(274) |
Apr
(138) |
May
(184) |
Jun
(152) |
Jul
(261) |
Aug
(409) |
Sep
(239) |
Oct
(241) |
Nov
(260) |
Dec
(137) |
| 2006 |
Jan
(191) |
Feb
(142) |
Mar
(169) |
Apr
(75) |
May
(141) |
Jun
(169) |
Jul
(131) |
Aug
(141) |
Sep
(192) |
Oct
(176) |
Nov
(142) |
Dec
(95) |
| 2007 |
Jan
(98) |
Feb
(120) |
Mar
(93) |
Apr
(96) |
May
(95) |
Jun
(65) |
Jul
(62) |
Aug
(56) |
Sep
(53) |
Oct
(95) |
Nov
(106) |
Dec
(87) |
| 2008 |
Jan
(58) |
Feb
(149) |
Mar
(175) |
Apr
(110) |
May
(106) |
Jun
(72) |
Jul
(55) |
Aug
(89) |
Sep
(26) |
Oct
(96) |
Nov
(83) |
Dec
(93) |
| 2009 |
Jan
(97) |
Feb
(106) |
Mar
(74) |
Apr
(64) |
May
(115) |
Jun
(83) |
Jul
(137) |
Aug
(103) |
Sep
(56) |
Oct
(59) |
Nov
(61) |
Dec
(37) |
| 2010 |
Jan
(94) |
Feb
(71) |
Mar
(53) |
Apr
(105) |
May
(79) |
Jun
(111) |
Jul
(110) |
Aug
(81) |
Sep
(50) |
Oct
(82) |
Nov
(49) |
Dec
(21) |
| 2011 |
Jan
(87) |
Feb
(105) |
Mar
(108) |
Apr
(99) |
May
(91) |
Jun
(94) |
Jul
(114) |
Aug
(77) |
Sep
(58) |
Oct
(58) |
Nov
(131) |
Dec
(62) |
| 2012 |
Jan
(76) |
Feb
(93) |
Mar
(68) |
Apr
(95) |
May
(62) |
Jun
(109) |
Jul
(90) |
Aug
(87) |
Sep
(49) |
Oct
(54) |
Nov
(66) |
Dec
(84) |
| 2013 |
Jan
(67) |
Feb
(52) |
Mar
(93) |
Apr
(65) |
May
(33) |
Jun
(34) |
Jul
(52) |
Aug
(42) |
Sep
(52) |
Oct
(48) |
Nov
(66) |
Dec
(14) |
| 2014 |
Jan
(66) |
Feb
(51) |
Mar
(34) |
Apr
(47) |
May
(58) |
Jun
(27) |
Jul
(52) |
Aug
(41) |
Sep
(78) |
Oct
(30) |
Nov
(28) |
Dec
(26) |
| 2015 |
Jan
(41) |
Feb
(42) |
Mar
(20) |
Apr
(73) |
May
(31) |
Jun
(48) |
Jul
(23) |
Aug
(55) |
Sep
(36) |
Oct
(47) |
Nov
(48) |
Dec
(41) |
| 2016 |
Jan
(32) |
Feb
(34) |
Mar
(33) |
Apr
(22) |
May
(14) |
Jun
(31) |
Jul
(29) |
Aug
(41) |
Sep
(17) |
Oct
(27) |
Nov
(38) |
Dec
(28) |
| 2017 |
Jan
(28) |
Feb
(30) |
Mar
(16) |
Apr
(9) |
May
(27) |
Jun
(57) |
Jul
(28) |
Aug
(43) |
Sep
(31) |
Oct
(20) |
Nov
(24) |
Dec
(18) |
| 2018 |
Jan
(34) |
Feb
(50) |
Mar
(18) |
Apr
(26) |
May
(13) |
Jun
(31) |
Jul
(13) |
Aug
(11) |
Sep
(15) |
Oct
(12) |
Nov
(18) |
Dec
(13) |
| 2019 |
Jan
(12) |
Feb
(29) |
Mar
(51) |
Apr
(22) |
May
(13) |
Jun
(20) |
Jul
(13) |
Aug
(12) |
Sep
(21) |
Oct
(6) |
Nov
(9) |
Dec
(5) |
| 2020 |
Jan
(13) |
Feb
(5) |
Mar
(25) |
Apr
(4) |
May
(40) |
Jun
(27) |
Jul
(5) |
Aug
(17) |
Sep
(21) |
Oct
(1) |
Nov
(5) |
Dec
(15) |
| 2021 |
Jan
(28) |
Feb
(6) |
Mar
(11) |
Apr
(5) |
May
(7) |
Jun
(8) |
Jul
(5) |
Aug
(5) |
Sep
(11) |
Oct
(9) |
Nov
(10) |
Dec
(12) |
| 2022 |
Jan
(7) |
Feb
(13) |
Mar
(8) |
Apr
(7) |
May
(12) |
Jun
(27) |
Jul
(14) |
Aug
(27) |
Sep
(27) |
Oct
(17) |
Nov
(17) |
Dec
|
| 2023 |
Jan
(10) |
Feb
(18) |
Mar
(9) |
Apr
(26) |
May
|
Jun
(13) |
Jul
(18) |
Aug
(5) |
Sep
|
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
1
(1) |
2
(9) |
3
(6) |
4
(4) |
5
(2) |
|
6
(6) |
7
(6) |
8
(4) |
9
(8) |
10
(4) |
11
(5) |
12
(2) |
|
13
(1) |
14
(11) |
15
(3) |
16
(12) |
17
(2) |
18
(12) |
19
(6) |
|
20
|
21
(11) |
22
(10) |
23
(7) |
24
(6) |
25
(11) |
26
(6) |
|
27
(1) |
28
(11) |
29
(3) |
30
(3) |
|
|
|
|
From: Simon E. <si...@es...> - 2004-06-10 07:42:23
|
On Thursday 10 June 2004 09:26, Dimitri Papadopoulos-Orfanos wrote: > Hi, > > > Hello list, I'm trying to valgrind my application, which is a 3d > > graphics program running on Linux 2.4. I'm using SDL and OpenGL for the > > 3d graphics. > > Which exact Linux distribution and version is this? Gentoo Linux, the 2.4 version was for the kernel (2.4.20-gentoo-r9 is the full version). -- Simon Ejsing, Systemudvikler esoft ApS, http://www.esoft.dk Skibhusvej 52C, DK-5000 Odense C. Tlf: 70 222 466, Fax: 63 122 466 |
|
From: Dimitri Papadopoulos-O. <pap...@sh...> - 2004-06-10 07:26:59
|
Hi, > Hello list, I'm trying to valgrind my application, which is a 3d graphics > program running on Linux 2.4. I'm using SDL and OpenGL for the 3d graphics. Which exact Linux distribution and version is this? > [...] > Does anyone else experience this problem/bug? I'm thinking it might be linked > to the gfx drivers (ATI). Indeed I would suggest trying without ATI drivers. http://search.gmane.org/search.php?query=ATI+driver&email=&group=gmane.comp.debugging.valgrind There used to be problems with Nvidia drivers too: http://article.gmane.org/gmane.comp.debugging.valgrind/684/ Dimitri |
|
From: Elijah P N. <ne...@ma...> - 2004-06-09 17:14:48
|
On Wed, 2004-06-09 at 10:41, Tom Hughes wrote: > In message <108...@am...> > Elijah P Newren <ne...@ma...> wrote: > > > 2. So, I try downloading CVS HEAD. I build it and get a segfault when > > trying to run valgrind on ls just as with Dag's package. > > This should work find so long as you turn off vdso support, which you > can do with this command: > > sysctl -w kernel.vdso=0 Works like a charm. Thanks! Elijah |
|
From: Tom H. <th...@cy...> - 2004-06-09 16:41:37
|
In message <108...@am...>
Elijah P Newren <ne...@ma...> wrote:
> 2. So, I try downloading CVS HEAD. I build it and get a segfault when
> trying to run valgrind on ls just as with Dag's package.
This should work find so long as you turn off vdso support, which you
can do with this command:
sysctl -w kernel.vdso=0
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Elijah P N. <ne...@ma...> - 2004-06-09 16:15:14
|
Hi, I would like to get valgrind to run under Fedora Core 2 (uses kernel-2.6.5, glibc-2.3.3, and gcc-3.3.3), but now I'm wondering whether it's possible. Is it? I thought it should be possible since Dag Wieers packaged it (http://dag.wieers.com/home-made/apt/) for that. I have also found in my search some bugs in bugzilla and emails in the archives that seem to imply others are trying to work with valgrind on distros that use the 2.6 kernel. However, I'm getting several problems: 1. Using the version packaged by Dag Wieers (valgrind-2.1.1) and running 'valgrind --tool=memcheck ls' all I see is 'Segmentation fault'. 2. So, I try downloading CVS HEAD. I build it and get a segfault when trying to run valgrind on ls just as with Dag's package. 3. So, I download the 2.0.0 tarball and build it. Trying to run valgrind on ls gives me the bug described at http://bugs.kde.org/show_bug.cgi?id=82026. 4. So, I try out the VALGRIND_2_0_BRANCH in CVS. When trying to configure, I get the response, 'configure: error: Valgrind works on kernels 2.2 and 2.4'. Until the last step above, I hadn't found anything that specifically says that valgrind doesn't work on a 2.6 kernel. Now I'm wondering if that's my problem, though. Can anyone shed some light on this? I seem to be coming up blank in my searches through bugzilla and my searches of the email list archives as to what I can try. If it should be possible, what information could I provide to help pinpoint the problem? I can get valgrind to work just fine on the older systems (running the 2.4 kernel) I've tried, both using packages from Dag or compiling from tarballs. But those machines are really slow and don't have as much memory, among other problems... Thanks in advance for any pointers, Elijah P.S. Output of 'uname -a': 'Linux amr.math.utah.edu 2.6.5-1.358smp #1 SMP Sat May 8 09:25:36 EDT 2004 i686 athlon i386 GNU/Linux'. Output of 'valgrind -v' is identical to that of 'valgrind --help'. |
|
From: Dennis L. <pla...@gm...> - 2004-06-09 16:12:39
|
Hi, especially for debugging a Program under few memory conditions, I have tried to run a program with ulimit -v 180000 set. Even with ls it does not work : # valgrind --tool=memcheck ls Segmentation Fault without the ulimit set, everything works fine. I have a P4 with 512MB RAM running Linux 2.6.6 with glibc 2.3.3 with NPTL enabled. greets Dennis Carpe quod tibi datum est |
|
From: Simon E. <si...@es...> - 2004-06-09 13:45:27
|
Hello list, I'm trying to valgrind my application, which is a 3d graphics program running on Linux 2.4. I'm using SDL and OpenGL for the 3d graphics. The program executes cleanly whitout Valgrind, but when I start it with Valgrind I get a segmentation fault. I'm using Valgrind version 2.1.1, and SDL 1.2.7, compiled for Gentoo Linux. The bug is also present in Valgrind version 2.0.0. I've tracked down the problem to OpenGl, in SDL I create a surface like this: videoFlags = SDL_OPENGL | SDL_GL_DOUBLEBUFFER | SDL_HWPALETTE | SDL_RESIZABLE; screen = SDL_SetVideoMode(800, 600, 32, videoFlags); If I remove SDL_OPENGL from the flags, the program works in Valgrind. Does anyone else experience this problem/bug? I'm thinking it might be linked to the gfx drivers (ATI). -- Simon Ejsing, Systemudvikler esoft ApS, http://www.esoft.dk Skibhusvej 52C, DK-5000 Odense C. Tlf: 70 222 466, Fax: 63 122 466 |
|
From: Nicholas N. <nj...@ca...> - 2004-06-09 10:10:59
|
On Tue, 8 Jun 2004, Tamtoro, Ferry (MED) wrote: > I installed valgrind 2.1.1 and tried to run a program that used to work > with valgrind 2.0.0, and I'm getting this error: > > @@ don't know what type '_' is > > I tried a simple "Hello World" program and it works fine. So, I believe > the installation is fine. > > Any idea that this problem is? It's a known bug (bugs.kde.org/show_bug.cgi?id=81262). I think the problem is with valgrind's debug info parser not handling one case. No fix yet, patches are welcome! N |
|
From: Paul M. <pa...@sa...> - 2004-06-09 03:21:54
|
David, > I've downloaded your PowerPC port of valgrind 2.1.0, and am running into > an "Illegal opcode" error when it hits an addis instruction in libgobject. > Valgrind does have a section for generating "addis" UCode instructions, > so I'm a bit lost. See dump below. The instruction is 7CBA04AA, which is a lswi instruction. I do need to get in and implement the string load/store instructions. I have avoided them so far because I haven't hit the problem myself, and because doing lswx/stswx is going to be a bit interesting - uCode doesn't have a way to express loading a variable number of registers based on the contents of another register (XER). > I've also tried pulling the latest CVS and applying your CVS patch. > After I got valgrind built, I got: > > eger@rosencrantz$ valgrind ls > Executable is mapped outside of range 0x1009e000-0x7ffff000 > failed to load /usr/local/lib/valgrind/stage2: Cannot allocate memory Hmmm, I'll have to look at that. What address is valgrind linked at? You could find out by doing `objdump -p valgrind'. It may be that I arranged for it to be linked in the 0xb0000000 region, in which case you would need to change that to the 0x70000000 region. The best address to use there depends on the TASK_SIZE definition in the kernel, and it looks like you have TASK_SIZE=0x80000000 (2GB). I usually have TASK_SIZE set to 3GB on my ppc32 machines, and of course 32-bit processes have TASK_SIZE = 4GB on a ppc64 kernel. Regards, Paul. |
|
From: David E. <eg...@ha...> - 2004-06-09 02:15:58
|
Dear Paul,
I've downloaded your PowerPC port of valgrind 2.1.0, and am running into
an "Illegal opcode" error when it hits an addis instruction in libgobject.
Valgrind does have a section for generating "addis" UCode instructions,
so I'm a bit lost. See dump below.
I've also tried pulling the latest CVS and applying your CVS patch.
After I got valgrind built, I got:
eger@rosencrantz$ valgrind ls
Executable is mapped outside of range 0x1009e000-0x7ffff000
failed to load /usr/local/lib/valgrind/stage2: Cannot allocate memory
Any ideas? If you give me a pointer to what needs fixing, I could look
at it. I'm just a little unsure where to start.
-dte
==15814== Memcheck, a memory error detector for linux.
==15814== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward.
==15814== Using valgrind-2.1.0-ppc, a program supervision framework for linux.
==15814== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward.
==15814== PowerPC port copyright (C) 2004, and GNU GPL'd, by Paul Mackerras.
==15814== Estimated timebase clock rate is 33 MHz
==15814== For more details, rerun with: -v
==15814==
unrecognized PowerPC instruction: 7CBA04AA
at 0xF3BA1B4: (within /usr/lib/libgobject-2.0.so.0.400.0)
==15814==
==15814== Process terminating with default action of signal 4 (SIGILL): dumping core
==15814== Illegal opcode at address 0xFDE8BC8
==15814== at 0xF3BA1B4: (within /usr/lib/libgobject-2.0.so.0.400.0)
==15814== by 0xF3C0E30: g_type_init_with_debug_flags (in /usr/lib/libgobject-2.0.so.0.400.0)
==15814== by 0xF3C0EF4: g_type_init (in /usr/lib/libgobject-2.0.so.0.400.0)
==15814== by 0xF5C0234: (within /usr/lib/libgdk-x11-2.0.so.0.400.0)
==15814==
==15814== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==15814== malloc/free: in use at exit: 8157 bytes in 54 blocks.
==15814== malloc/free: 58 allocs, 4 frees, 8236 bytes allocated.
==15814== For a detailed leak analysis, rerun with: --leak-check=yes
==15814== For counts of detected errors, rerun with: -v
Illegal instruction
|
|
From: kirk j. <tu...@in...> - 2004-06-08 16:06:15
|
KJ = kirk johnson
NN = nicholas nethercote
KJ > i'm trying to use massif to analyze the behavior of some rather
> large applications. for many "interesting" problem sizes,
> massif/valgrind (this is in the context of valgrind 2.1.1) blows
> out with:
>
> valgrind: vg_mylibc.c:1681 (vgPlain_get_memory_from_mmap):
> Assertion `p >= (void *)vgPlain_valgrind_mmap_end && p < (void
> *)vgPlain_valgrind_end' failed.
>
> vg_mylibc.c:1681 corresponds to a bounds-checking assertion in
> "VG_(get_memory_from_mmap)"; i've instrumented that code and
> verified that the problem appears to be an _overflow_ of those
> bounds.
>
> because i don't see the same problems running the same
> applications and problem sizes under calltree/valgrind, i'm
> assuming this is a massif-specific issue.
NN > I think it's a Valgrind core issue, that perhaps only Massif
> exposes.
entirely possible.
NN > It may be a manifestation of bug #82301
> (bugs.kde.org/show_bug.cgi?id=82301).
yeah, i'm seeing a different failure mode, but i think the basic
problem is the same -- i'm running out of mmap space.
NN > As a temporary workaround, you could try installing Valgrind
> 2.0.0, which lays out memory differently, and then plumbing in
> Massif (it wasn't added until 2.1.0), which will require some
> judicious copying and editing of configure.in and Makefile.am.
another option would be to try some version of the patch that's listed
at the end of bug #82301.
NN > Hmm, I hadn't considered that some XPts could become non-live.
> My gut feeling is that the number wouldn't be that significant,
> but I would be happy to be proved wrong.
mostly a guess on my part, no data to support it -- i was simply
trying to come up with an explanation for why we were going through
128 MB worth of XPt objects ...
NN > The number of XPts is bound by the size of the program, rather
> than the running time. It's also possible that an XPt could
> become dead and then alive again later, in which case it would
> be reallocated.
exactly the sort of thing i was wondering about.
NN > I think option 2 would be the better one.
good for a short term fix, but if a significant number of XPt objects
are going non-live and/or then being reallocated, then it may not be
the right long-term fix ...
tx for the pointers, i'll see if i can get something working today and
let you know what happens.
kirk
|
|
From: Tamtoro, F. (MED) <Fer...@me...> - 2004-06-08 13:49:29
|
I installed valgrind 2.1.1 and tried to run a program that used to work with valgrind 2.0.0, and I'm getting this error: @@ don't know what type '_' is @@ parsing __lt__C14_Bit_referenceRC14_Bit_reference;2B.;flip::(378,12)=##(0,21);:; 2A.;; gave NULL type (_lt__C14_Bit_referenceRC14_Bit_reference;2B.;flip::(378,12)=##(0,21);:; 2A.;; remains) @@ expected ':' at struct method MANGLE-ARGS (remains="lt__C14_Bit_referenceRC14_Bit_reference;2B.;flip::(378,12)=##( 0,21);:;2A.;;") @@ parsing (378,1)=s8_M_p:(378,2)=*(0,4),0,32;_M_mask:(0,4),32,32;_Bit_reference::( 378,3)=##(378,4)=*(378,1);:RC14_Bit_reference;2A.(378,5)=##(378,4);:PUiU i;2A.(378,6)=##(378,4);:;2A.;__opb::(378,7)=##(0,12);:;2B.;operator=::(3 78,8)=##(378,9)=&(378,1);:__as__14_Bit_referenceb;2A.(378,10)=##(378,9); :__as__14_Bit_referenceRC14_Bit_reference;2A.;operator==::(378,11)=##(0, 12);:__eq__C14_Bit_referenceRC14_Bit_reference;2B.;operator<::(378,11):_ _lt__C14_Bit_referenceRC14_Bit_reference;2B.;flip::(378,12)=##(0,21);:;2 A.;; gave NULL type (s8_M_p:(378,2)=*(0,4),0,32;_M_mask:(0,4),32,32;_Bit_reference::(378,3)= ##(378,4)=*(378,1);:RC14_Bit_reference;2A.(378,5)=##(378,4);:PUiUi;2A.(3 78,6)=##(378,4);:;2A.;__opb::(378,7)=##(0,12);:;2B.;operator=::(378,8)=# #(378,9)=&(378,1);:__as__14_Bit_referenceb;2A.(378,10)=##(378,9);:__as__ 14_Bit_referenceRC14_Bit_reference;2A.;operator==::(378,11)=##(0,12);:__ eq__C14_Bit_referenceRC14_Bit_reference;2B.;operator<::(378,11):__lt__C1 4_Bit_referenceRC14_Bit_reference;2B.;flip::(378,12)=##(0,21);:;2A.;; remains) --28146-- INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting --28146-- si_code=1 Fault EIP: 0xB8038BBB (); Faulting address: 0x0 valgrind: the `impossible' happened: Killed by fatal signal I tried a simple "Hello World" program and it works fine. So, I believe the installation is fine. Any idea that this problem is? Thanks. |
|
From: Nicholas N. <nj...@ca...> - 2004-06-08 07:40:33
|
On Mon, 7 Jun 2004 tunaNO@SPAMindra.com wrote: > i'm trying to use massif to analyze the behavior of some rather large > applications. for many "interesting" problem sizes, massif/valgrind > (this is in the context of valgrind 2.1.1) blows out with: > > valgrind: vg_mylibc.c:1681 (vgPlain_get_memory_from_mmap): Assertion > `p >= (void *)vgPlain_valgrind_mmap_end && p < (void *)vgPlain_valgrind_end' > failed. > > vg_mylibc.c:1681 corresponds to a bounds-checking assertion in > "VG_(get_memory_from_mmap)"; i've instrumented that code and verified > that the problem appears to be an _overflow_ of those bounds. > > because i don't see the same problems running the same applications > and problem sizes under calltree/valgrind, i'm assuming this is a > massif-specific issue. I think it's a Valgrind core issue, that perhaps only Massif exposes. It may be a manifestation of bug #82301 (bugs.kde.org/show_bug.cgi?id=82301). Josef, is this the same error you are getting with Calltree on big programs? As a temporary workaround, you could try installing Valgrind 2.0.0, which lays out memory differently, and then plumbing in Massif (it wasn't added until 2.1.0), which will require some judicious copying and editing of configure.in and Makefile.am. > without digging into ms_main.c too much further (yet!), it appears to > me that there might be a handful of different ways of attacking this > problem: > > 1) assuming "halve_censi" (or some other mechanism?) does indeed > remove some XPt objects from further consideration without > providing a means for ever reusing them, provide such a > means: > > a) simplest solution here is probably a freelist that > no-longer-used XPt objects are pushed onto, and new XPt objects > are popped from when possible. > > b) alternate approach would be to eliminate the calls to > "perm_malloc" in favor of calls to a conventional "malloc", > taking care to insert corresponding calls to "free" for XPt > objects that will no longer be used. > > 2) provide a means of expanding the size of the memory segment that > is available for "VG_(get_memory_from_mmap)" to work with. > > of these, 1a would seem to be the most straightforward and promising > approach, but that's only if the assumption about XPt object use holds > true, which i'm completely unclear on. Hmm, I hadn't considered that some XPts could become non-live. My gut feeling is that the number wouldn't be that significant, but I would be happy to be proved wrong. The number of XPts is bound by the size of the program, rather than the running time. It's also possible that an XPt could become dead and then alive again later, in which case it would be reallocated. I think option 2 would be the better one. N |
|
From: smiley g. <smi...@ya...> - 2004-06-08 07:40:11
|
To the group... Note: forwarded message attached. __________________________________ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ |
|
From: tunaNO@SPAMindra.com - 2004-06-07 21:48:39
|
i'm trying to use massif to analyze the behavior of some rather large
applications. for many "interesting" problem sizes, massif/valgrind
(this is in the context of valgrind 2.1.1) blows out with:
valgrind: vg_mylibc.c:1681 (vgPlain_get_memory_from_mmap): Assertion
`p >= (void *)vgPlain_valgrind_mmap_end && p < (void *)vgPlain_valgrind_end'
failed.
vg_mylibc.c:1681 corresponds to a bounds-checking assertion in
"VG_(get_memory_from_mmap)"; i've instrumented that code and verified
that the problem appears to be an _overflow_ of those bounds.
because i don't see the same problems running the same applications
and problem sizes under calltree/valgrind, i'm assuming this is a
massif-specific issue. digging around, i see a call to
"VG_(get_memory_from_mmap)" at ms_main.c:372 coming out of
"perm_malloc", which is prefaced with the following comment:
// Cheap allocation for blocks that never need to be freed. Saves
// about 10% for Konqueror startup with --depth=40.
"perm_malloc" looks to be called from "new_XPt", which appears to be
the code that is used to allocate new execution/allocation points in
the instrumentation scheme used by massif. so one assumes that the
assertion at vg_mylibc.c:1681 is ultimately failing because we've run
out of space to allocate more XPt objects, and perhaps that there is
something interesting about these applications (long runtimes? large
number of allocation points?) that is causing enough XPt objects to be
allocated for me to run afoul of such problems.
it is unclear to me at this point whether or not the periodic calls to
"halve_censi" may in fact be removing some XPt objects from further
consideration without providing a means for ever reusing them, thus
exacerbating the problems suggested above.
without digging into ms_main.c too much further (yet!), it appears to
me that there might be a handful of different ways of attacking this
problem:
1) assuming "halve_censi" (or some other mechanism?) does indeed
remove some XPt objects from further consideration without
providing a means for ever reusing them, provide such a
means:
a) simplest solution here is probably a freelist that
no-longer-used XPt objects are pushed onto, and new XPt objects
are popped from when possible.
b) alternate approach would be to eliminate the calls to
"perm_malloc" in favor of calls to a conventional "malloc",
taking care to insert corresponding calls to "free" for XPt
objects that will no longer be used.
2) provide a means of expanding the size of the memory segment that
is available for "VG_(get_memory_from_mmap)" to work with.
of these, 1a would seem to be the most straightforward and promising
approach, but that's only if the assumption about XPt object use holds
true, which i'm completely unclear on.
thoughts/comments/suggestions?
tx,
kirk
ps. i'm not subscribed to val...@li..., so
please include my e-mail address (modulo obvious anti-spam -- remove
the NO and SPAM) in your response. just in case, i'll also try to keep
an eye on the valgrind-users archives ...
|
|
From: Robert W. <rj...@du...> - 2004-06-07 18:36:01
|
> > I've had some success running on AMD64 with the patch at this address: > > > > http://www.durables.org/software/valgrind/ > > > > This only works for 32-bit executables, and I built Valgrind on a P4 > > machine - I haven't tried the linux32 ./configure trick Andi mentioned. > > Ah that fixes the 4GB problem, right? Um, yep. I don't remember the details right now, but Jeremy wasn't terribly happy with the fix as it potentially meant Valgrind could allocate some memory in the last page of the address space. He suggested another fix, but that caused a crash later in the code. I think you might find the thread in valgrind-developers somewhere. That's why I haven't checked this back in yet, BTW. Regards, Robert. |
|
From: Andi K. <ak...@mu...> - 2004-06-07 18:31:57
|
On Mon, Jun 07, 2004 at 11:03:16AM -0700, Bryan O'Sullivan wrote: > On Mon, 2004-06-07 at 04:50, Andi Kleen wrote: > > > I worked around that by using linux32 --3gb (which will the process > > only give 3GB address space) > > Trouble is, linux32 looks like it's only distributed by SuSE. I can't > find anything similar in Red Hat land. Debian should at least have it too. If you don't have it you can grab it from ftp://ftp.x86-64.org/pub/linux/tools/linux32/ Anyways - it would be better of course to fix valgrind to not assume 3GB address space. There's an open bug for this. -Andi |
|
From: Bryan O'S. <bo...@se...> - 2004-06-07 18:03:25
|
On Mon, 2004-06-07 at 04:50, Andi Kleen wrote: > I worked around that by using linux32 --3gb (which will the process > only give 3GB address space) Trouble is, linux32 looks like it's only distributed by SuSE. I can't find anything similar in Red Hat land. <b |
|
From: Andi K. <ak...@mu...> - 2004-06-07 11:50:27
|
Robert Walsh <rj...@du...> writes: > > I've had some success running on AMD64 with the patch at this address: > > http://www.durables.org/software/valgrind/ > > This only works for 32-bit executables, and I built Valgrind on a P4 > machine - I haven't tried the linux32 ./configure trick Andi mentioned. Ah that fixes the 4GB problem, right? I worked around that by using linux32 --3gb (which will the process only give 3GB address space) -Andi |
|
From: Robert W. <rj...@du...> - 2004-06-07 06:22:55
|
On Thu, 2004-06-03 at 10:13, Andi Kleen wrote: > "Simon J. Benson" <sim...@cm...> writes: > > > > setting the host argument doesn't help. Is Valgrind compatible with > > non Intel architecture? >=20 > Use linux32 ./configure ... >=20 > However the result may not run completely reliable, there seem > to be still some issues left in the 32bit emulation of the kernel > interacting with valgrind >=20 > Also of course you can only run 32bit executables this way. I've had some success running on AMD64 with the patch at this address: http://www.durables.org/software/valgrind/ This only works for 32-bit executables, and I built Valgrind on a P4 machine - I haven't tried the linux32 ./configure trick Andi mentioned. Regards, Robert. --=20 Robert Walsh Amalgamated Durables, Inc. - "We don't make the things you buy." Email: rj...@du... |
|
From: Nicholas N. <nj...@ca...> - 2004-06-06 21:38:39
|
On Sun, 6 Jun 2004, Tamtoro, Ferry (MED) wrote: > I am new to valgrind and am hoping that someone can help me resolve a > problem I'm experiencing when I'm running my program using valgrind. > > When I'm running my program using valgrind, it crashes in the middle with > this error: > disInstr: unhandled instruction bytes: 0xF 0x17 0x10 0xF > > I believe this happens right after a call to a function in one of the Intel > libraries. So, I'm wondering if it's possible to setup valgrind to ignore > certain function calls, so that it does not try to instrument code around > that function? > It's different that suppressing errors, because I'm hoping to call that > function like when the program is not run using valgrind. > > Any help would be greatly appreciated. You don't way what version you're running, probably an old one. Try a new one (eg. 2.1.1) and it should be fixed. N |
|
From: Tamtoro, F. (MED) <Fer...@me...> - 2004-06-06 20:38:02
|
Hi, I am new to valgrind and am hoping that someone can help me resolve a problem I'm experiencing when I'm running my program using valgrind. When I'm running my program using valgrind, it crashes in the middle with this error: disInstr: unhandled instruction bytes: 0xF 0x17 0x10 0xF I believe this happens right after a call to a function in one of the Intel libraries. So, I'm wondering if it's possible to setup valgrind to ignore certain function calls, so that it does not try to instrument code around that function? It's different that suppressing errors, because I'm hoping to call that function like when the program is not run using valgrind. Any help would be greatly appreciated. Thanks, Ferry |
|
From: Tamtoro, F. (MED) <Fer...@me...> - 2004-06-06 19:27:35
|
-----Original Message----- From: val...@li... [mailto:val...@li...]On Behalf Of val...@li... Sent: Saturday, June 05, 2004 11:41 AM To: Tamtoro, Ferry (MED) Subject: Valgrind-users -- confirmation of subscription -- request 147922 Valgrind-users -- confirmation of subscription -- request 147922 We have received a request from 67.52.56.20 for subscription of your email address, <Fer...@me...>, to the val...@li... mailing list. To confirm the request, please send a message to val...@li..., and either: - maintain the subject line as is (the reply's additional "Re:" is ok), - or include the following line - and only the following line - in the message body: confirm 147922 (Simply sending a 'reply' to this message should work from most email interfaces, since that usually leaves the subject line in the right form.) If you do not wish to subscribe to this list, please simply disregard this message. Send questions to val...@li.... |
|
From: Tom H. <th...@cy...> - 2004-06-06 07:23:12
|
In message <010f01c44b8b$84a771c0$0201a8c0@aelfin.local>
George Huber <kh...@op...> wrote:
> I downloaded the source from CVS today (6 Jun), and
> build without doing any patches. Although I am unsure
> of how to turn of vdso support. Googling for vdso
> seems to imply that it is a `rather undocumented feature'
> of Linux. Any help on how to disable vdso? (I am
> using grub as the bootloader).
Either add vdso=0 to the boot options in grub or run this command:
sysctl -w kernel.vdso=0
> I kinda figured that debugging valgrind with GDB would
> be difficult, I at first tried using the --wait-for-gdb=yes
> flag and then attaching, but when valgrind segfaulted
> and I tried to attach with GDB there was no valgrind
> process to attach to. I also tried the command:
>
> valgrind --tool=memcheck --help
>
> which also seg-faulted on me. Base on this, is why I
> attempted to debug valgrind directly with GDB. The
> seg-fault occures within the first thirty instructions
> being executed.
If you use wait-for-gdb and it dies before it waits then you
probably do need to run gdb directly. In this case however it
may have been dying between the transfer from phase1 to phase2
and the point where phase2 pauses to allow GDB to be attached
in which case you are pretty much stuffed at the moment as
a directly attached GDB will appear to be at the point where
the transfer to phase2 happens which isn't where the problem
really is.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: George H. <kh...@op...> - 2004-06-06 06:00:09
|
Tom - Thanks for the info. I downloaded the source from CVS today (6 Jun), and build without doing any patches. Although I am unsure of how to turn of vdso support. Googling for vdso seems to imply that it is a `rather undocumented feature' of Linux. Any help on how to disable vdso? (I am using grub as the bootloader). I kinda figured that debugging valgrind with GDB would be difficult, I at first tried using the --wait-for-gdb=yes flag and then attaching, but when valgrind segfaulted and I tried to attach with GDB there was no valgrind process to attach to. I also tried the command: valgrind --tool=memcheck --help which also seg-faulted on me. Base on this, is why I attempted to debug valgrind directly with GDB. The seg-fault occures within the first thirty instructions being executed. George |