I have a sample code with memory leaks. Though clang displays the leak correctly, I am unable to achieve the same with gcc. gcc version I am using is 4.8.5-39
Code:
#include <stdlib.h>
void *p;
int main() {
p = malloc(7);
p = 0; // The memory is leaked here.
return 0;
}
CLANG:
clang -fsanitize=address -g memory-leak.c ; ASAN_OPTIONS=detect_leaks=1 ./a.out
=================================================================
==15543==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 7 byte(s) in 1 object(s) allocated from:
#0 0x465289 in __interceptor_malloc (/u/optest/a.out+0x465289)
#1 0x47b549 in main /u/optest/memory-leak.c:4
#2 0x7f773fe14544 in __libc_start_main /usr/src/debug/glibc-2.17-c758a686/csu/../csu/libc-start.c:266
SUMMARY: AddressSanitizer: 7 byte(s) leaked in 1 allocation(s).
GCC:
gcc -fsanitize=address -g memory-leak.c ; ASAN_OPTIONS=detect_leaks=1 ./a.out
I need to use gcc. Can someone help me understand why gcc isn't behaving like clang and what should I do to make it work.
Can someone help me understand why gcc isn't behaving like clang
Gcc-4.8 was released on March 22, 2013.
The patch to support -fsanitize=leak was sent on Nov. 15, 2013, and is likely not backported into the 4.8 release.
GCC-8.3 has no trouble detecting this leak:
$ gcc -g -fsanitize=address memory-leak.c && ./a.out
=================================================================
==166614==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 7 byte(s) in 1 object(s) allocated from:
#0 0x7fcaf3dc5330 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xe9330)
#1 0x55d297afc162 in main /tmp/memory-leak.c:4
#2 0x7fcaf394052a in __libc_start_main ../csu/libc-start.c:308
SUMMARY: AddressSanitizer: 7 byte(s) leaked in 1 allocation(s).
This item in Asan's FAQ is relevant:
Q: Why didn't ASan report an obviously invalid
memory access in my code?
A1: If your errors is too obvious, compiler might have
already optimized it out by the time Asan runs.
Related
For some reason, NVCC is crashing when trying to compile a GPU program with very long double-precision arithmetic expressions, of the form
// given double precision arrays A[ ], F[ ],
__global__ myKernel(double *A, double *F, long n){
//.......thread ids
A[t+1] = A[t]*F[t+1] + ...... (order of million of terms).... + A[t-1]*F[t]
}
The same code does get compiled successfully with GCC (around 30 minutes compiling) and even executes correctly.
The crash occurs after +20hrs of compilation time, with the following error:
nvcc error : 'cicc' died due to signal 11 (Invalid memory reference)
nvcc error : 'cicc' core dumped
make: *** [Makefile:28: obj/EquationAlfa.cu.o] Error 139
As a side note, if we change the GPU program to 32-bit float, then it does compile correctly, although still taking hours to compile.
The compilation line is this:
nvcc -std=c++14 -c -o obj/EquationAlfa.cu.o src/EquationAlfa.cu
NVCC version:
nvcc: NVIDIA (R) Cuda compiler driver
Copyright (c) 2005-2020 NVIDIA Corporation
Built on Mon_Nov_30_19:08:53_PST_2020
Cuda compilation tools, release 11.2, V11.2.67
Build cuda_11.2.r11.2/compiler.29373293_0
During compilation, the RAM usage does not exceed 8~10GB, and the computer has 128GB of RAM.
Any help or directions would be greatly appreciated.
I am trying to test the usage of -fsanitize=thread for gcc, and its complaining of unexpected memory mapping, maybe there might have been some change in the kernel, and thats the reason for it. Is there any thing I could do to make it work ?
This is what I am doing ...
mfrw#kp ...fpp/asgn/as2 %
mfrw#kp ...fpp/asgn/as2 % cat tiny.cpp
#include <pthread.h>
int global;
void *thread(void *x) {
global = 42;
return x;
}
int main() {
pthread_t t;
pthread_create(&t, NULL, thread, NULL);
global = 43;
pthread_join(t, NULL);
return global;
}
mfrw#kp ...fpp/asgn/as2 % g++ tiny.cpp -fsanitize=thread -pie -fPIC -g -O1 -o tinyrace -pthread
mfrw#kp ...fpp/asgn/as2 % uname -a
Linux kp 4.4.33-1-MANJARO #1 SMP PREEMPT Fri Nov 18 18:06:44 UTC 2016 x86_64 GNU/Linux
mfrw#kp ...fpp/asgn/as2 % gcc --version
gcc (GCC) 6.2.1 20160830
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
mfrw#kp ...fpp/asgn/as2 % ./tinyrace
FATAL: ThreadSanitizer: unexpected memory mapping 0x55e38776b000-0x55e38776c000
mfrw#kp ...fpp/asgn/as2 %
It is to do with your compilation option: -pie -fPIC.
If I compiled your code (in Ubuntu 16.04, latest update) with:
g++ -fsanitize=thread -pie -fPIC tinyrace.c -g -O1 -o tinyrace -pthread
I will get the same error.
But if changed to:
g++ -fsanitize=thread tinyrace.c -g -O1 -o tinyrace -pthread
Then the race condition alert is printed:
./tinyrace
==================
WARNING: ThreadSanitizer: data race (pid=12032)
Write of size 4 at 0x00000060108c by thread T1:
#0 thread(void*) /home/tteikhua/tinyrace.c:5 (tinyrace+0x000000400a5d)
#1 <null> <null> (libtsan.so.0+0x0000000230d9)
Previous write of size 4 at 0x00000060108c by main thread:
#0 main /home/tteikhua/tinyrace.c:11 (tinyrace+0x000000400ab1)
Location is global 'global' of size 4 at 0x00000060108c (tinyrace+0x00000060108c)
Thread T1 (tid=12034, running) created by main thread at:
#0 pthread_create <null> (libtsan.so.0+0x000000027577)
#1 main /home/tteikhua/tinyrace.c:10 (tinyrace+0x000000400aa7)
SUMMARY: ThreadSanitizer: data race /home/tteikhua/tinyrace.c:5 thread(void*)
Yes, it's due to changes in the kernel and it's not GCC-specific, clang exposes the same behaviour.
There is a corresponding bug in GCC tracker, which references fix in the upstream. Comments mention kernels 4.1+, but I hit this problem on 3.16.
As mentioned in the answer by Peter Teoh, it might work if you omit pie/pic options, but the proper fix is in newer thread sanitizer used by newer compilers (after September 2016, but it's not clear whether GCC 6.x branch got the fix).
I have encounter EXEC_BAD_ACCESS error in my local environment (Mac OS X 10.9.2, boost 1.55.0, mlpack 1.0.8, llvm 5.1 clang-503.0.38), and I have narrowed down the error in a very simple snippet:
#include "mlpack/methods/range_search/range_search.hpp"
int main(int argc, const char *argv[])
{
return 0;
}
The g++ version is
iMac:build dongli$ g++ --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 5.1 (clang-503.0.38) (based on LLVM 3.4svn)
Target: x86_64-apple-darwin13.1.0
Thread model: posix
and compile the snippet by
g++ -std=c++11 main.cpp -o main -lmlpack -I/usr/include/libxml2
(you may change to your case)
Run main in terminal will give you
iMac:build dongli$ ./main
Bus error: 10
and run it in lldb will give you more information
iMac:build dongli$ lldb ./main
Current executable set to './main' (x86_64).
(lldb) r
Process 79449 launched: './main' (x86_64)
Process 79449 stopped
* thread #1: tid = 0xb4a75, 0x00000001000500eb libmlpack.1.0.dylib`long double boost::math::lanczos::lanczos17m64::lanczos_sum<long double>(long double const&) + 59, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=2, address=0x100001d80)
frame #0: 0x00000001000500eb libmlpack.1.0.dylib`long double boost::math::lanczos::lanczos17m64::lanczos_sum<long double>(long double const&) + 59
libmlpack.1.0.dylib`long double boost::math::lanczos::lanczos17m64::lanczos_sum<long double>(long double const&) + 59:
-> 0x1000500eb: fstpt (%rax)
0x1000500ed: fldt 0x26c8d(%rip) ; .memset_pattern99 + 1296
0x1000500f3: fstpt 0x10(%rax)
0x1000500f6: fldt 0x26c94(%rip) ; .memset_pattern99 + 1312
As you can see, it point me to boost::math::lanczos::lanczos17m64::lanczos_sum, but I have no idea what is the problem.
But when -std=c++11 is absent, no error occurs. I also tried to reinstall boost with --c++11 by homebrew.
Thanks in advance!
EDIT:
I have only installed one boost:
iMac:~ dongli$ ls /usr/local/Cellar/boost/
1.55.0
with command:
brew install boost --c++11
You could
check that the actual shared library file is marked executable and is accessible to the user that runs the application?
It that isn't it, this probably means that at runtime you find a conflicting version of the library. Fix/override the runtime library path, or compile against the same version of the library if so
After I removed all the C++11 features from my codes (e.g., initializer_list and default template argument), and removed the -std=c++11 option, the error is gone. I think I have installed boost, mlpack with -std=c++11 by using homebrew, but the error persisted, so my experience is not use the new features if they are not necessary.
I'm a bit of an AIX newbie. I'm trying to compile a program using gcc's stack protector feature. I installed gcc on server using pware's GCC package and I can compile a sample program like:
#include <stdio.h>
int main(int argc,char **argv)
{
printf("hello world\n");
return 0;
}
When I turn on stack-protector though, I get:
g++ -fstack-protector-all main.cpp
collect2: library libssp_nonshared not found
I've been hunting on google for a solution to this and it seems like my libc needs to have some stuff built into that mine doesn't. Is there a package out there that includes a libc with the stack protection builtin?
g++ -v returns
Using built-in specs.
Target: powerpc-ibm-aix5.3.0.0
Configured with: ../stage/gcc-4.2.4/configure --disable-shared --enable-threads=posix --prefix=/opt/pware --with-long-double-128 --with-mpfr=/opt/pware --with-gmp=/opt/pware
Thread model: aix
gcc version 4.2.4
I can not find libssp_nonshared.a on the system -- is there an additional package I need to install or should it have come with the gcc package?
This has nothing to do with libc: your GCC installation is missing libssp_nonshared.a library.
What does your "gcc --version" say? It may have been configured with --disable-libssp option (in which case you can't use the stack protection instrumentation).
Update:
I just looked in gcc-4.3.0/configure:
powerpc-*-aix*)
noconfigdirs="$noconfigdirs gprof target-libgloss target-libssp ${libgcj}"
;;
I am about 99% sure this means that libssp (and therefore -fstack-protector) is not available for your platform. Sorry :-(
I have the following program:
~/test> cat test.cc
int main()
{
int i = 3;
int j = __sync_add_and_fetch(&i, 1);
return 0;
}
I'm compiling this program using GCC 4.2.2 on Linux running on a multi-cpu 64-bit Intel machine:
~/test> uname --all
Linux doom 2.6.9-67.ELsmp #1 SMP Wed Nov 7 13:56:44 EST 2007 x86_64 x86_64 x86_64 GNU/Linux
When I compile the program in 64-bit mode, it compiles and links fine:
~/test> /share/tools/gcc-4.2.2/bin/g++ test.cc
~/test>
When I compile it in 32-bit mode, I get the following error:
~/test> /share/tools/gcc-4.2.2/bin/g++ -m32 test.cc
/tmp/ccEVHGkB.o(.text+0x27): In function `main':
: undefined reference to `__sync_add_and_fetch_4'
collect2: ld returned 1 exit status
~/test>
Although I will never actually run on a 32-bit processor, I do need a 32-bit executable so I can link with some 32-bit libraries.
My 2 questions are:
Why do I get a link error when I compile in 32-bit mode?
Is there some way to get the program to compile and link, while still being able to link with a 32-bit library?
The answer from Dan Udey was close, close enough in fact to allow me to find the real solution.
According to the man page "-mcpu" is a deprecated synonym for "-mtune" and just means "optimize for a particular CPU (but still run on older CPUs, albeit less optimal)". I tried this, and it did not solve the issue.
However, "-march=" means "generate code for a particular CPU (and don't run on older CPUs)". When I tried this it solved the problem: specifying a CPU of i486 or better got rid of the link error.
~/test> /share/tools/gcc-4.2.2/bin/g++ -m32 test.cc
/tmp/ccYnYLj6.o(.text+0x27): In function `main':
: undefined reference to `__sync_add_and_fetch_4'
collect2: ld returned 1 exit status
~/test> /share/tools/gcc-4.2.2/bin/g++ -m32 -march=i386 test.cc
/tmp/ccOr3ww8.o(.text+0x22): In function `main':
: undefined reference to `__sync_add_and_fetch_4'
collect2: ld returned 1 exit status
~/test> /share/tools/gcc-4.2.2/bin/g++ -m32 -march=i486 test.cc
~/test> /share/tools/gcc-4.2.2/bin/g++ -m32 -march=pentium test.cc
From the GCC page on Atomic Builtins:
Not all operations are supported by
all target processors. If a particular
operation cannot be implemented on the
target processor, a warning will be
generated and a call an external
function will be generated. The
external function will carry the same
name as the builtin, with an
additional suffix `_n' where n is the
size of the data type.
Judging from your compiler output, which refers to __sync_add_and_fetch_4, this is what's happening. For some reason, GCC is not generating the external function properly.
This is likely why you're only getting an error in 32-bit mode - when compiling for 64-bit mode, it compiles for your processor more closely. When compiling for 32-bit, it may well be using a generic arch (i386, for example) which does not natively support those features. Try specifying a specific architecture for your chip family (Xeon, Core 2, etc.) via -mcpu and see if that works.
If not, you'll have to figure out why GCC isn't including the appropriate function that it should be generating.