|
From: Andy H. <And...@ra...> - 2006-05-12 04:17:27
|
Hello, I'm having a problem with callgrind on AMD64. My app cores with: ** glibc detected *** double free or corruption (out) 0X0000000588e010 *** I'm 99% sure that I'm not doing a double free where it cores. This only happens on AMD64. On a 4-way 32 bit XEON its fine. Valgrind does not turn up any errors either. I'm using callgrind-0.10.1 and valgrind-3.1.0 Any known issues with AMD64? Thanks, Andy |
|
From: Andy H. <And...@ra...> - 2006-05-12 17:59:38
|
Josef Weidendorfer wrote:
> On Friday 12 May 2006 06:16, Andy Howell wrote:
>> Hello,
>>
>> I'm having a problem with callgrind on AMD64. My app cores with:
>>
>> ** glibc detected *** double free or corruption (out) 0X0000000588e010 ***
>>
>> I'm 99% sure that I'm not doing a double free where it cores.
>
> memcheck is running this code without errors on AMD64?
> Can you check out the SVN version of VG (which includes callgrind)?
>
> Hmmm... I would love to run memcheck on callgrind. Perhaps something
> is not 64bit clean.
>
Josef,
I tried "valgrind callgrind myapp" but it didn't come up with anything.
I checked out the latest from SVN, but was not able build. It fails with:
gcc -Wno-long-long -Wdeclaration-after-statement -o valgrind-listener
-m64 -fomit-frame-pointer -O -g -Wmissing-prototypes -Winline -Wall
-Wshadow -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations
valgrind_listener-valgrind-listener.o
mpicc -g -O -fno-omit-frame-pointer -Wall -fpic -shared \
-I../include \
-m64 \
-o libmpiwrap.so libmpiwrap.c
/usr/bin/ld: /usr/lib64/libmpi.a(laminit.o): relocation R_X86_64_32S
against `lam_mpi_comm_world' can not be used when making a shared
object; recompile with -fPIC
/usr/lib64/libmpi.a: could not read symbols: Bad value
I tried changes the -fpic to -fPIC in auxprogs/Makefile.in and
Makefile.am, but no luck.
|
|
From: Tom H. <to...@co...> - 2006-05-16 12:49:37
|
In message <446...@ra...>
Andy Howell <And...@ra...> wrote:
> I checked out the latest from SVN, but was not able build. It fails with:
>
> gcc -Wno-long-long -Wdeclaration-after-statement -o
> valgrind-listener -m64 -fomit-frame-pointer -O -g -Wmissing-prototypes
> -Winline -Wall -Wshadow -Wpointer-arith -Wstrict-prototypes
> -Wmissing-declarations valgrind_listener-valgrind-listener.o
> mpicc -g -O -fno-omit-frame-pointer -Wall -fpic -shared \
> -I../include \
> -m64 \
> -o libmpiwrap.so libmpiwrap.c
> /usr/bin/ld: /usr/lib64/libmpi.a(laminit.o): relocation R_X86_64_32S
> against `lam_mpi_comm_world' can not be used when making a shared
> object; recompile with -fPIC
> /usr/lib64/libmpi.a: could not read symbols: Bad value
>
> I tried changes the -fpic to -fPIC in auxprogs/Makefile.in and
> Makefile.am, but no luck.
It's libmpi.a that needs to be recompiled with -fPIC not callgrind.
The problem is that it is trying to link a static library into a
shared object and you can't do that on amd64 (unless you happen to
have compiled the code in the static library as PIC code for some
weird reason).
On x86 you shouldn't really do it but you can get away with it because
the dynamic linker will do the necessary relocations when the
resulting shared object is loaded. The amd64 dynamic linker doesn't
have that kludge so the linker stops you creating an object that
would require it.
So what you really need is a libmpi.so with PIC code in it ;-)
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Julian S. <js...@ac...> - 2006-05-12 19:44:08
|
> I tried changes the -fpic to -fPIC in auxprogs/Makefile.in and > Makefile.am, but no luck. Known problem. Re-run configure with --with-mpicc=some_bogus_mpicc_name so as to inhibit the compilation of libmpiwrap.so. J |
|
From: Andy H. <And...@ra...> - 2006-05-12 21:05:43
|
Julian Seward wrote: >> I tried changes the -fpic to -fPIC in auxprogs/Makefile.in and >> Makefile.am, but no luck. > > Known problem. Re-run configure with --with-mpicc=some_bogus_mpicc_name > so as to inhibit the compilation of libmpiwrap.so. > Got the SVN ( today ) version running. I'm still seeing the double-free problem. Checking the vgcore, it is in my app where I'm doing a free. Its odd that it runs by itself ok, and under valgrind memcheck. The code in question is for a reference counted chunk of memory. Its created in one thread and freed in another. Its protected by a mutex, which is why I pretty sure I'm not freeing it twice. While I have the mutex, I free and then NULL out the pointer. Even it did get called twice, the pointer would be NULL, so I would not get a double-free. Maybe its my problem. Not sure. Anything else I can try? |
|
From: Julian S. <js...@ac...> - 2006-05-12 22:46:26
|
You're absolutely 110% sure you don't have any race conditions or threading bugs associated with this memory? > Maybe its my problem. Not sure. Anything else I can try? Run it on V with the tools (--tool=...) none, lackey, cachegrind, callgrind and memcheck, and see which of those get the double-free problem and which don't. When you say it runs ok with memcheck, you mean memcheck reports no errors, or merely that it doesn't crash? J |