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
(5) |
2
(11) |
3
(5) |
4
(1) |
5
|
|
6
(6) |
7
(2) |
8
(4) |
9
(7) |
10
(17) |
11
(3) |
12
(3) |
|
13
(5) |
14
(5) |
15
(6) |
16
(6) |
17
(5) |
18
(1) |
19
(5) |
|
20
(6) |
21
(10) |
22
(5) |
23
(5) |
24
(2) |
25
(3) |
26
(1) |
|
27
(1) |
28
|
|
|
|
|
|
|
From: Paul P. <ppl...@gm...> - 2005-02-07 19:01:42
|
> valgrind: Couldn't allocate address space for shadow memory. > The funny thing is that it worked fine on Friday. I rebooted the Are you running Fedora Core2. You probably have "random" prelinking enabled (by default it happens once every 2 weeks) Undo the prelinking (as root) "prelink -ua", and try again. If that helps, edit /etc/sysconfig/prelink, set "PRELINKING=no" Cheers, |
|
From: Hans t. H. <hos...@gm...> - 2005-02-07 17:07:32
|
Hello All, On the command valgrind --tool=memcheck ls -l I get the following error back: valgrind: Couldn't allocate address space for shadow memory. The funny thing is that it worked fine on Friday. I rebooted the system but that didnt' help either. $ valgrind --version valgrind-2.2.0 [root@hterhors-fc2 ~/valgrind/valgrind-2.2.0] $ uname -a Linux hterhors-fc2 2.4.18-3dev #2 Tue Sep 28 03:36:21 EDT 2004 i686 i686 i386 GNU/Linux |
|
From: Tom H. <to...@co...> - 2005-02-06 21:20:08
|
In message <420...@ts...>
Yuri <yu...@ts...> wrote:
> Is it any hope to get amd64 support into Valgrind ?
Yes.
> Any work is being done ? How difficult is this ?
It is being worked on.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Nicholas N. <nj...@cs...> - 2005-02-06 21:12:30
|
On Sun, 6 Feb 2005, Edward Moyse wrote: > I was surprised by that as well, but It definitely says 12x in the manual > (just checked): > "The amount of instrumentation code added varies widely between tools. At one > end of the scale, Memcheck adds code to check every memory access and every > value computed, increasing the size of the code at least 12 times, and making > it run 25-50 times slower than natively. That's code size, which only represents a fraction of a program's total memory usage. There's also data, which is usually bigger. A very rough figure to expect might be something like 3x overall. > He said that AddrCheck didn't work either, even on a machine with 3Gb of ram. > Is he correct that there is a hard-limit of 4Gb for 32 machines? Is it > believable that valgrind 2.2.0 could require 64bit machines in order to be > used on this project? (I hope not!) The amount of RAM basically doesn't matter, it's the size of the address space, which is limited to 4GB on 32-bit machines, and the kernel typically reserves the top 1GB of that. N |
|
From: Yuri <yu...@ts...> - 2005-02-06 21:08:01
|
Is it any hope to get amd64 support into Valgrind ? Any work is being done ? How difficult is this ? Thanx, Yuri |
|
From: Edward M. <edw...@ce...> - 2005-02-06 20:52:04
|
On 6 Feb 2005, at 21:34, Nicholas Nethercote wrote: > On Sun, 6 Feb 2005, Edward Moyse wrote: > >> We've been having problems getting valgrind 2.2.0 working with our >> project. Older versions (e.g. <2.0.0) seemed to work okay. One of our >> IT folk says that since (according to the valgrind manual) MemCheck >> takes ~12 times more memory than usually needed, and our code takes >> 1Gb normally, valgrind will never work. Apparently the maximum >> addressable space on a 32-bit processor is 4Gb, so "unless you do >> something really smart with your swap space, you can never run >> valgrind" > > 2.2.0 does handle memory differently to 2.0.0, which can cause > problems. Without any more info about how things go wrong, we can't > give any help, though.\ Okay thanks - I'll try to get more details on monday. It's sunday evening here, so there isn't much I can do right now. > > The 12x figure is flat-out wrong; the expansion factor depends on a > bunch of things. I was surprised by that as well, but It definitely says 12x in the manual (just checked): "The amount of instrumentation code added varies widely between tools. At one end of the scale, Memcheck adds code to check every memory access and every value computed, increasing the size of the code at least 12 times, and making it run 25-50 times slower than natively. At the other end of the spectrum, the ultra-trivial "none" tool (a.k.a. Nulgrind) adds no instrumentation at all and causes in total "only" about a 4 times slowdown." > If you use 1GB, things will be pretty tight for Memcheck, which may be > the problem. You could try Addrcheck, which uses less memory. > He said that AddrCheck didn't work either, even on a machine with 3Gb of ram. Is he correct that there is a hard-limit of 4Gb for 32 machines? Is it believable that valgrind 2.2.0 could require 64bit machines in order to be used on this project? (I hope not!) Thanks! Ed |
|
From: Nicholas N. <nj...@cs...> - 2005-02-06 20:34:25
|
On Sun, 6 Feb 2005, Edward Moyse wrote: > We've been having problems getting valgrind 2.2.0 working with our project. > Older versions (e.g. <2.0.0) seemed to work okay. One of our IT folk says > that since (according to the valgrind manual) MemCheck takes ~12 times more > memory than usually needed, and our code takes 1Gb normally, valgrind will > never work. Apparently the maximum addressable space on a 32-bit processor > is 4Gb, so "unless you do something really smart with your swap space, you > can never run valgrind" 2.2.0 does handle memory differently to 2.0.0, which can cause problems. Without any more info about how things go wrong, we can't give any help, though. The 12x figure is flat-out wrong; the expansion factor depends on a bunch of things. If you use 1GB, things will be pretty tight for Memcheck, which may be the problem. You could try Addrcheck, which uses less memory. N |
|
From: Edward M. <edw...@ce...> - 2005-02-06 09:52:15
|
Hi all, We've been having problems getting valgrind 2.2.0 working with our project. Older versions (e.g. <2.0.0) seemed to work okay. One of our IT folk says that since (according to the valgrind manual) MemCheck takes ~12 times more memory than usually needed, and our code takes 1Gb normally, valgrind will never work. Apparently the maximum addressable space on a 32-bit processor is 4Gb, so "unless you do something really smart with your swap space, you can never run valgrind" Is this correct? Has something drastic changed since the 1.x.x days? Do all the valgrind "skins" require as much memory as MemCheck? Thanks in advance for any help. Ed |
|
From: Homer, E. B <eri...@hp...> - 2005-02-04 15:40:43
|
I'm trying to run a verilog simulation using Cadence NCverilog tools. Our verilog is stimulated and checked using C++ and PLI code. I wanted to use Valgrind to find memory issues in our C++, but when I run with Valgrind I get unexpected signal errors on some verilog system tasks. System tasks like $time, $display, and $finish work fine, but $strobe and $monitor cause the failures. I'm running on Linux 8.0 and 3.2.3 of gnu. Any thoughts? -ebh |
|
From: Tom H. <to...@co...> - 2005-02-03 19:38:49
|
In message <1107458660.6659.109.camel@d-usca22-161-76>
Darryl Mocek <Darryl.Mocek@Sun.COM> wrote:
> I am having problems running our code in valgrind. I get a SIG11.
> It looks like the problem is in libpthread.so in the cond_wait
> function. I've reported the bug (#96559). Is there a way to build
> valgrind using Linux's libpthread library instead of its own?
If you use CVS that is exactly what you will get - we have dropped
the special libpthread.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Darryl M.
|
Hello, I am having problems running our code in valgrind. I get a SIG11. It looks like the problem is in libpthread.so in the cond_wait function. I've reported the bug (#96559). Is there a way to build valgrind using Linux's libpthread library instead of its own? -d |
|
From: Eduardo M. <ea...@us...> - 2005-02-03 16:57:25
|
Running valgrind --tool=lackey <pgr> hangs:
>cat /proc/version
>Linux version 2.6.5-7.97-pseries64 (geeko@buildhost) (gcc version 3.3.3
(SuSE Linux)) #1 SMP Fri Jul 2 14:21:59 UTC 2004
valgrind: valgrind-2.3.0-CVS-ppc-041217.tar.bz2
The following command hangs:
I ran strace on the following valgrind command:
>strace valgrind --tool=lackey ls
:
:
:
:
:
:
:
mmap(0xfd8f000, 75916, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) =
0xfd8f000
fstat(3, {st_mode=S_IFREG|0755, st_size=18508, ...}) = 0
readlink("/proc/self/fd/3", "/lib/libdl.so.2", 4096) = 15
stat("/lib/libdl.so.2", {st_mode=S_IFREG|0755, st_size=18508, ...}) = 0
open("/lib/libdl.so.2", O_RDONLY) = 4
mmap(0x7034d000, 18508, PROT_READ, MAP_PRIVATE|MAP_FIXED, 4, 0) =
0x7034d000
fstat(4, {st_mode=S_IFREG|0755, st_size=18508, ...}) = 0
readlink("/proc/self/fd/4", "/lib/libdl.so.2", 4096) = 15
close(4) = 0
munmap(0x7034d000, 18508) = 0
write(824, "\0\0\0\1p\6\240@\0\0\0Z", 12) = 12
gettid() = 2067
gettid() = 2067
rt_sigprocmask(SIG_SETMASK, NULL, ~[ILL BUS FPE KILL SEGV STOP], 8) = 0
gettid() = 2067
read(825, "\0\0\0\1\0\0\0\1\0\0\0\315\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
136) = 136
read(825, 0xffffde80, 136) = -1 EAGAIN (Resource temporarily
unavailable)
mprotect(0xfd92000, 63628, PROT_NONE) = 0
mmap(0xfd9f000, 12288, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED, 3, 0) = 0xfd9f000
fstat(3, {st_mode=S_IFREG|0755, st_size=18508, ...}) = 0
readlink("/proc/self/fd/3", "/lib/libdl.so.2", 4096) = 15
close(3) = 0
mmap(0x2546c000, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x2546c000
munmap(0x25499000, 111780) = 0
write(824, "\0\0\0\1p\2ADp\n\0\0", 12) = 12
gettid() = 2067
gettid() = 2067
rt_sigprocmask(SIG_SETMASK, NULL, ~[ILL BUS FPE KILL SEGV STOP], 8) = 0
gettid() = 2067
read(825, "\0\0\0\1\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
136) = 136
read(825, 0xffffde80, 136) = -1 EAGAIN (Resource temporarily
unavailable)
write(824, "\0\0\0\1p\2ADp\n\0\0", 12) = 12
gettid() = 2067
gettid() = 2067
rt_sigprocmask(SIG_SETMASK, NULL, ~[ILL BUS FPE KILL SEGV STOP], 8) = 0
gettid() = 2067
read(825, 0xffffde80, 136) = -1 EAGAIN (Resource temporarily
unavailable)
poll(
Regards,
Eduardo A. Munoz
Linux Technology Center
MCP Build and Infrastructure Team
ea...@us...
512-838-8219
|
|
From: Josef W. <Jos...@gm...> - 2005-02-03 09:17:46
|
On Thursday 03 February 2005 08:22, Yuri wrote: > I use cachegrind-0.9.10 -- older version -- and it's working nicely > except for two problems: Hi Yuri, you are confusing cachegrind and callgrind. Callgrind is an extension of cachegrind, but external to VG releases. It is distributed separately on kcachegrind.sf.net. > 1. truncates long C++-mangled names Which length do you need? I thought the current maximal length of 4096 (?) should be enough. Perhaps Callgrind/Cachegrind should output mangled names and KCachegrind itself should unmangle them... > 2. leaves some functions with "cycle 4" non-descriptive names. These functions are produced by the cycle detection inside of KCachegrind, and have nothing to do with the measuring tool. A cycle is a set of functions which have called each other in a recursive manner (at least by looking at the call graph). Have a look at the "Callee Tab" of a cycle to see the member functions. There is no bug. GProf would do the same. You should try to reduce the cycles by generating "functions" which do not call each other in a recursive way. That is sometimes possible if there is no real recursion in your program, but different call chains make the call graph appear to have a cycle. * Generate call chain contexts instead of pure function contexts (e.g. --separate-callers=3). Be aware that call chains will be a concatenation of the function names in the chain. * Specify functions which should never appear in the generated calls (multiple --fn-skip=func). It will look like "func" was inlined to each call site. This can break cycles. For real recursion, try to distinguish the first few recursion levels (e.g. --separate-recs=5). The function names get the recursion level appended. > Hoping that these are fixed I took version from CVS of valgrind with > cachegrind inside today. Surely above issues can not be "fixed" by using VG CVS. > First: options --simulate-cache=yes --simulate-hwpref=yes > --simulate-wb=yes --collect-jumps=yes --dump-instr=yes > are all gone -- not supported. See above. Cachegrind != Callgrind. > kcachegrind (also fresh from CVS) doesn't show any C++ function names. If you are loading files generated from cachegrind? That would be a bug... > My questions: > > What's wrong with the current version of valgrind, are these options now > default ? > Or I am doing something wrong ? > Also what's these "cycle 4" functions and why there source is not shown > by kcachegrind ? Josef > > Thanx, > Yuri > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting > Tool for open source databases. Create drag-&-drop reports. Save time > by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. > Download a FREE copy at http://www.intelliview.com/go/osdn_nl > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Yuri
|
I use cachegrind-0.9.10 -- older version -- and it's working nicely except for two problems: 1. truncates long C++-mangled names 2. leaves some functions with "cycle 4" non-descriptive names. Hoping that these are fixed I took version from CVS of valgrind with cachegrind inside today. First: options --simulate-cache=yes --simulate-hwpref=yes --simulate-wb=yes --collect-jumps=yes --dump-instr=yes are all gone -- not supported. kcachegrind (also fresh from CVS) doesn't show any C++ function names. My questions: What's wrong with the current version of valgrind, are these options now default ? Or I am doing something wrong ? Also what's these "cycle 4" functions and why there source is not shown by kcachegrind ? Thanx, Yuri |
|
From: Nicholas N. <nj...@cs...> - 2005-02-02 22:56:17
|
Hi, I completed my PhD dissertation late last year. It's entitled "Dynamic Binary Analysis and Instrumentation", and it's basically about Valgrind, tools built with Valgrind, and the underlying techniques. Notably, chapter 2 provides one of the most detailed and up-to-date descriptions of Valgrind's inner workings available. If you interested, it's available at: http://www.cs.utexas.edu/~njn/pubs/phd2004.ps.gz I include a copy of the abstract below. N Dynamic binary analysis (DBA) tools such as profilers and checkers help programmers create better software. Dynamic binary instrumentation (DBI) frameworks make it easy to build new DBA tools. This dissertation advances the theory and practice of dynamic binary analysis and instrumentation, with an emphasis on the importance of the use and support of metadata. The dissertation has three main parts. - The first part describes a DBI framework called Valgrind which provides novel features to support heavyweight DBA tools that maintain rich metadata, especially location metadata--the shadowing of every register and memory location with a metavalue. Location metadata is used in shadow computation, a kind of DBA where every normal operation is shadowed by an abstract operation. - The second part describes three powerful DBA tools. The first tool performs detailed cache profiling. The second tool does an old kind of dynamic analysis -- bounds-checking -- in a new way. The third tool produces dynamic data flow graphs, a novel visualisation that cuts to the essence of a program's execution. All three tools were built with Valgrind, and rely on Valgrind's support for heavyweight DBA and rich metadata, and the latter two perform shadow computation. - The third part describes a novel system of semi-formal descriptions of DBA tools. It gives many example descriptions, and also considers in detail exactly what dynamic analysis is. The dissertation makes six main contributions. - First, the descriptions show that metadata is the key component of dynamic analysis; in particular, whereas static analysis predicts approximations of a program's future, dynamic analysis remembers approximations of a program's past, and these approximations are exactly what metadata is. - Second, the example tools show that rich metadata and shadow computation make for powerful and novel DBA tools that do more than the traditional tracing and profiling. - Third, Valgrind and the example tools show that a DBI framework can make it easy to build heavyweight DBA tools, by providing good support for rich metadata and shadow computation. - Fourth, the descriptions are a precise and concise way of characterising tools, provide a directed way of thinking about tools that can lead to better implementations, and indicate the theoretical upper limit of the power of DBA tools in general. - Fifth, the three example tools are interesting in their own right, and the latter two are novel. - Finally, the entire dissertation provides many details, and represents a great deal of condensed experience, about implementing DBI frameworks and DBA tools. |
|
From: Eduardo M. <ea...@us...> - 2005-02-02 19:29:59
|
This is in coregrind/Makefile.am at the end:
I put back the statement how it was in valgrind-2.2.0.tar.bz2 and my
problem went away.
The statement commented out does not work.
Paul, is the a type or what exactly are you trying to do here??
# Extract ld's default linker script and hack it to our needs
stage2.lds: Makefile
$(CC) -Wl,--verbose -nostdlib 2>&1 | sed \
-e '1,/^=====\+$$/d' \
-e '/^=====\+$$/d' \
-e 's/0x10000000/kickstart_base/g' > $@ || rm -f $@
# -e '/executable_start/s/0x[0-9a-f]+/kickstart_base/g' > $@
\
# || rm -f $@
Regards,
Eduardo A. Munoz
|
|
From: Dirk M. <dm...@gm...> - 2005-02-02 16:40:03
|
On Wednesday 02 February 2005 17:11, Eduardo Munoz wrote: > Also, I am using valgrind-ppc-2.3.0.CVS-ppc-041217.tar.bz2 > I compiled it myself. ah, the PPC port.. that one isn't very stable yet. Please contact the author of the ppc port directly and try to figure out with him what goes wrong. Dirk |
|
From: Eduardo M. <ea...@us...> - 2005-02-02 16:11:55
|
I am running Linux version 2.6.5-7.97-pseries64 (geeko@buildhost) (gcc version 3.3.3 (SuSE Linux)) #1 SMP Fri Jul 2 14:21:59 UTC 2004 Also, I am using valgrind-ppc-2.3.0.CVS-ppc-041217.tar.bz2 I compiled it myself. Regards, Eduardo A. Munoz ea...@us... 512-838-8219 |
|
From: Tom H. <to...@co...> - 2005-02-02 16:01:09
|
In message <OFA...@us...>
Eduardo Munoz <ea...@us...> wrote:
> I am getting the following error trying to run valgrind:
>
> dev1:~ # valgrind --tool=memcheck /bin/ls -l
> Executable range 0x10000000-0x10239ee8 is outside the
> acceptable range 0x100a1000-0x7ffff000
> valgrind: failed to load /usr/lib/valgrind/stage2: Cannot allocate
> memory
You need to find out why stage2 is linked to load at 0x10000000 which
looks very wrong to me - it is far too low.
> Any Ideas??
> I am running Linux version 2.6.5-7.97-pseries64 (geeko@buildhost) (gcc
> version 3.3.3 (SuSE Linux)) #1 SMP Fri Jul 2 14:21:59 UTC 2004
>
> Also, I am using valgrind-ppc-2.3.0.CVS-ppc-041217.tar.bz2
Aha. The PPC port is very alpha - you probably want to talk to the
person that did the port as he will know more about it.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Dirk M. <dm...@gm...> - 2005-02-02 16:00:57
|
On Wednesday 02 February 2005 16:50, Eduardo Munoz wrote: > dev2:~ # ulimit -a ok, looks unsuspicous. did you use the version packaged by SuSE ? or compile on your own? which version of valgrind are you trying to run? Dirk |
|
From: Tom H. <to...@co...> - 2005-02-02 15:59:41
|
In message <200...@gm...>
Dirk Mueller <dm...@gm...> wrote:
> On Tuesday 01 February 2005 21:40, Eduardo Munoz wrote:
>
>> I am getting the following error trying to run valgrind:
>
> ulimit -a says?
It doesn't matter, his problem isn't limit related.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Eduardo M. <ea...@us...> - 2005-02-02 15:51:07
|
dev2:~ # ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited file size (blocks, -f) unlimited max locked memory (kbytes, -l) unlimited max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size (512 bytes, -p) 8 stack size (kbytes, -s) unlimited cpu time (seconds, -t) unlimited max user processes (-u) 4096 virtual memory (kbytes, -v) unlimited Regards, Eduardo A. Munoz ea...@us... |
|
From: Dirk M. <dm...@gm...> - 2005-02-02 15:40:00
|
On Tuesday 01 February 2005 21:40, Eduardo Munoz wrote: > I am getting the following error trying to run valgrind: ulimit -a says? |
|
From: Igmar P. <mai...@jd...> - 2005-02-02 09:59:23
|
> =3D=3D14779=3D=3D Reading syms from /usr/lib/libSDL-1.2.so.0.7.0 (0x4F447= 000) > =3D=3D14779=3D=3D=A0=A0=A0=A0object=A0doesn't=A0have=A0a=A0symbol=A0table > =3D=3D14779=3D=3D=A0=A0=A0=A0object=A0doesn't=A0have=A0any=A0debug=A0info > ./ffx: error while loading shared libraries: libSDL-1.2.so.0: cannot enab= le > executable stack as shared object requires: Invalid argument >=20 > i couldn't find any reference to this error on the mailing list, faq, or > google. what is it, why am i getting it and what can i do to get rid of i= t? >=20 > cheers for any help you can offer, Are you by any change running a kernel with PAX enabled ? If the answer is= =20 'yes', then start reading=20 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=3D132149 Since this is SDL, I can highly imagine that it uses asm somewhere, which= =20 causes the problems. I personally hardly believe that it's a valgrind=20 issue, since mappings are done by the kernel. =09Igmar |
|
From: EgoldShop <Ad...@eg...> - 2005-02-02 03:51:52
|
Dear Sir/Madam. We have the pleasure to offer you new e-shop http://egoldshop.net Now you can buy and pay the various goods via E-gold payment system. In our shop, you can get home appliances, electronics, furniture, cars, and many other goods with low prices. You never see before lower prices, and we have chosen the way of payment most convenient for you. You pay any item in our shop through E-gold system. Our E-shop gives huge assortment of the goods! Simply order and pay the goods in our shop. The item will be delivered by the courier after payment at any time convenient for you! Hasten to choose that is necessary to you as the low prices will be only the current month! What do we mean under the low prices? For example: now you can buy automobile BMW 735i only for $50,000 US. WELCOME TO EGOLDSHOP.NET Sincerely Yours, EGOLDSHOP Customer Support |