Patrick Alken writes:
> It is a 64 bit machine, and I reinstalled valgrind using
> --enable-only64bit, and it did use the -m64 when compiling.
I meant compiling the *app* 64bit. e.g. if you're running:
valgrind --whatever ./a.out
then you should get a.out via:
gcc -blah -m64 -moreblah som
On Fri, May 15, 2009 at 4:44 AM, Ashley Pittman wrote:
>
> Unless it's been fixed in the last month the VPATH stuff is broken on
> the HEAD, I posted a patch to make the basic build work last month but
> there are remaining problems, the tests don't work for example.
Which is something of a shows
It is a 64 bit machine, and I reinstalled valgrind using
--enable-only64bit, and it did use the -m64 when compiling.
Unfortunately I get the same malloc failure as before.
Patrick
On Thu, May 14, 2009 at 03:03:37PM -0600, tom fogal wrote:
> patrick.al...@noaa.gov writes:
> > I am using valgrin
Sean,
I have encountered the same problem. The problem lies in how command-line
arguments are parsed.
Have a look at the following webpage
https://csd.vpac.org/twiki/bin/view/Tech/ParallelDebugging#Using_valgrind_with_MPICH_to_che
which gives instructions on getting valgrind to work with mpich
is it a 32 bit or 64 bit OS?
On Thu, May 14, 2009 at 1:55 PM, wrote:
> Hi,
>
> I am using valgrind 3.4.1 to try to find a memory leak. My
> program has an initial routine which allocates a lot of memory -
> around 1 GB. When I run the program by itself it runs fine, however
> when I run it unde
patrick.al...@noaa.gov writes:
> I am using valgrind 3.4.1 to try to find a memory leak. My
> program has an initial routine which allocates a lot of memory -
> around 1 GB. When I run the program by itself it runs fine, however
> when I run it under valgrind, one of the many malloc calls in
> th
Hi,
I am using valgrind 3.4.1 to try to find a memory leak. My
program has an initial routine which allocates a lot of memory -
around 1 GB. When I run the program by itself it runs fine, however
when I run it under valgrind, one of the many malloc calls in
the initial routine fails.
Does anyon
On Thu, 2009-05-14 at 20:30 +0200, Julian Seward wrote:
> > Compiling For Multiple Architectures
> >
> >
> >You can compile the package for more than one kind of computer at
> the
> > same time, by placing the object files for each architecture in
> their
>
On Thursday 14 May 2009, Russell E. Owen wrote:
> I'm trying to install Valgrid 3.4.1 on a shared disk in such a way that
> all of our users can use it, though we have a mix of various flavors of
> linux box (x86 64-bit, 32-bit and AMD64).
>
> I assume this is the relevant section of the documentat
"Russell E. Owen" writes:
> I'm trying to install Valgrid 3.4.1 on a shared disk in such a way that
> all of our users can use it, though we have a mix of various flavors of
> linux box (x86 64-bit, 32-bit and AMD64).
[snip]
> `cd' to the
> directory where you want the object files and executabl
I'm trying to install Valgrid 3.4.1 on a shared disk in such a way that
all of our users can use it, though we have a mix of various flavors of
linux box (x86 64-bit, 32-bit and AMD64).
I assume this is the relevant section of the documentation, but I cannot
make heads or tails out of it:
---
Julian Seward wrote:
>> Thanks. I don't think it actually makes any difference though. I can
>> reproduce what you're seeing on F10 x86 with the original program.
>
> Could you pls send the objdump -d of the insn it's complaining about
> + the few preceding ones, so as to show how the flags get s
Tom,
> Thanks. I don't think it actually makes any difference though. I can
> reproduce what you're seeing on F10 x86 with the original program.
Could you pls send the objdump -d of the insn it's complaining about
+ the few preceding ones, so as to show how the flags get set?
J
---
David L wrote:
> On Thu, May 14, 2009 at 6:36 AM, Tom Hughes wrote:
>> David L wrote:
>>
>>> ==3121== Conditional jump or move depends on uninitialised value(s)
>>> ==3121==at 0x804852F: main (main.cpp:11)
>>> ==3121== Uninitialised value was created by a heap allocation
>>> ==3121==at 0x
On Thu, May 14, 2009 at 6:36 AM, Tom Hughes wrote:
> David L wrote:
>
>> ==3121== Conditional jump or move depends on uninitialised value(s)
>> ==3121== at 0x804852F: main (main.cpp:11)
>> ==3121== Uninitialised value was created by a heap allocation
>> ==3121== at 0x400674E: operator new(u
David L wrote:
> ==3121== Conditional jump or move depends on uninitialised value(s)
> ==3121==at 0x804852F: main (main.cpp:11)
> ==3121== Uninitialised value was created by a heap allocation
> ==3121==at 0x400674E: operator new(unsigned int) (vg_replace_malloc.c:224)
> ==3121==by 0x8
On Thu, May 14, 2009 at 12:33 AM, Julian Seward wrote:
>
>> Hmm, that's ungood. Can you send details of the precise gcc version,
>> the compilation flags, and the what kind of processor you're running on?
I'm running on a fedora 10 x86 box:
valgrind --version
valgrind-3.4.1
g++ --version
g++
On Thursday 14 May 2009, Julian Seward wrote:
> Hmm, that's ungood. Can you send details of the precise gcc version,
> the compilation flags, and the what kind of processor you're running on?
Oh, and of course, the Valgrind version too.
J
---
On Thursday 14 May 2009, David L wrote:
> With this code:
>
>
> #include
>
> class MyClass {
> public:
> short int foo_ : 6;
> };
>
> int main(int argc, char *argv[]) {
> MyClass *gce = new MyClass();
> double d=0.0;
> if (d == 0.0) {
> printf("d equals zero.\n");
> }
> return 0;
>
19 matches
Mail list logo
