Valgrind is detecting some memory leaks in Gsoap. This is a very basic example code:
//file hr.cpp
#include "soapH.h"
#include "ns1.nsmap"
int main()
{
struct soap *soap_ = soap_new();
soap_destroy(soap_);
soap_end(soap_);
//soap_done(soap_);
soap_free(soap_);
return 0;
}
To compile this code, I use this :
g++ -D DEBUG -g -std=c++0x -o hr hr.cpp soapC.cpp stdsoap2.cpp
And these are the memory leaks reported by Valgrind:
==5290== HEAP SUMMARY:
==5290== in use at exit: 72,800 bytes in 4 blocks
==5290== total heap usage: 18 allocs, 14 frees, 244,486 bytes allocated
==5290==
==5290== 32 bytes in 1 blocks are definitely lost in loss record 1 of 4
==5290== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==5290== by 0x41D6FF: soap_track_malloc (stdsoap2.cpp:8952)
==5290== by 0x421347: soap_set_logfile (stdsoap2.cpp:10022)
==5290== by 0x421402: soap_set_test_logfile (stdsoap2.cpp:10062)
==5290== by 0x422391: soap_init_REQUIRE_lib_v20851 (stdsoap2.cpp:10405)
==5290== by 0x43DD31: soap::soap() (stdsoap2.cpp:20074)
==5290== by 0x41AF2E: soap_new_REQUIRE_lib_v20851 (stdsoap2.cpp:8109)
==5290== by 0x40238C: main (hr.cpp:6)
==5290==
==5290== 32 bytes in 1 blocks are definitely lost in loss record 2 of 4
==5290== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==5290== by 0x41D6FF: soap_track_malloc (stdsoap2.cpp:8952)
==5290== by 0x421347: soap_set_logfile (stdsoap2.cpp:10022)
==5290== by 0x4213DA: soap_set_sent_logfile (stdsoap2.cpp:10050)
==5290== by 0x4223A2: soap_init_REQUIRE_lib_v20851 (stdsoap2.cpp:10406)
==5290== by 0x43DD31: soap::soap() (stdsoap2.cpp:20074)
==5290== by 0x41AF2E: soap_new_REQUIRE_lib_v20851 (stdsoap2.cpp:8109)
==5290== by 0x40238C: main (hr.cpp:6)
==5290==
==5290== 32 bytes in 1 blocks are definitely lost in loss record 3 of 4
==5290== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==5290== by 0x41D6FF: soap_track_malloc (stdsoap2.cpp:8952)
==5290== by 0x421347: soap_set_logfile (stdsoap2.cpp:10022)
==5290== by 0x4213B2: soap_set_recv_logfile (stdsoap2.cpp:10038)
==5290== by 0x4223B3: soap_init_REQUIRE_lib_v20851 (stdsoap2.cpp:10407)
==5290== by 0x43DD31: soap::soap() (stdsoap2.cpp:20074)
==5290== by 0x41AF2E: soap_new_REQUIRE_lib_v20851 (stdsoap2.cpp:8109)
==5290== by 0x40238C: main (hr.cpp:6)
==5290==
==5290== LEAK SUMMARY:
==5290== definitely lost: 96 bytes in 3 blocks
==5290== indirectly lost: 0 bytes in 0 blocks
==5290== possibly lost: 0 bytes in 0 blocks
==5290== still reachable: 72,704 bytes in 1 blocks
==5290== suppressed: 0 bytes in 0 blocks
==5290== Reachable blocks (those to which a pointer was found) are not shown.
==5290== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==5290==
==5290== For counts of detected and suppressed errors, rerun with: -v
==5290== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 0 from 0)
What am I doing wrong?
Am I missing any instruction? I have read through gsoap documentation and internet but I did not found anything.
Thanks a lot!
Do not compile your code with -DDEBUG to test with valgrind, because it activates gSOAP's internal memory leak checker. This may interfere with valgrind.
EDIT:
I verified this with the latest release 2.8.61 which shows no leak in DEBUG mode or otherwise. I suggest to upgrade to gSOAP 2.8.61.
Related
In my program I'm using GNU Readline and the functions from that library causes some leaks. While using Valgrind I don't want to see those leaks. Can I somehow block some functions?
I was getting lots of this kind of leak warnings from using valgrind --leak-check=full --show-leak-kinds=all ./program
==2376== 28,784 bytes in 7 blocks are still reachable in loss record 57 of 57
==2376== at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==2376== by 0x489500C: xmalloc (in /usr/lib/x86_64-linux-gnu/libreadline.so.8.0)
==2376== by 0x4873A91: rl_make_bare_keymap (in /usr/lib/x86_64-linux-gnu/libreadline.so.8.0)
==2376== by 0x487AD79: rl_generic_bind (in /usr/lib/x86_64-linux-gnu/libreadline.so.8.0)
==2376== by 0x487CA92: rl_parse_and_bind (in /usr/lib/x86_64-linux-gnu/libreadline.so.8.0)
==2376== by 0x487CC6C: ??? (in /usr/lib/x86_64-linux-gnu/libreadline.so.8.0)
==2376== by 0x486F228: rl_initialize (in /usr/lib/x86_64-linux-gnu/libreadline.so.8.0)
==2376== by 0x486F4AF: readline (in /usr/lib/x86_64-linux-gnu/libreadline.so.8.0)
==2376== by 0x10B6B5: main (main.c:77)
I made a file named supp.supp and wrote in it:
{
ignore_libreadline_leaks
Memcheck:Leak
...
obj:*/libreadline.so.*
}
After this, I added --suppressions=supp.supp flag. All leak errors from libreadline is now suppressed.
I am currently confusing how to optimize using HugePages with JVM applications with Netty, -XX:+UseLargePages option enabled, and using G1Gc.
Also, I didn't forget to set the same max and min size of the heap and metaspace.
My application looks fine, but I was wondering what happens if there's no remaining free huge pages on system since JVM uses additional native memory area to allocate direct memory buffer, etc.
(Assume that application started up normally, and consumes additional HugePages on off-heap memory area.)
I've read following page, but there's no description of the behavior when JVM failed to allocate huge pages.
https://www.oracle.com/java/technologies/javase/largememory-pages.html
I use CentOS 7 and OpenJDK 1.8.0_151-b12 for the testbed before deployment.
If allocating large pages fails, OpenJDK 8 or later falls back to allocating regular pages.
src/hotspot/share/memory/virtualspace.cpp:
if (base != NULL) {
[...]
} else {
// failed; try to reserve regular memory below
if (UseLargePages && (!FLAG_IS_DEFAULT(UseLargePages) ||
!FLAG_IS_DEFAULT(LargePageSizeInBytes))) {
log_debug(gc, heap, coops)("Reserve regular memory without large pages");
}
}
All GC implementations use the ReservedSpace helper for allocating memory, so this is not GC-specific.
You can easily test that behavior on Linux by restricting available large pages:
$ echo 16 > /proc/sys/vm/nr_hugepages
$ cat /proc/meminfo | grep HugePages
AnonHugePages: 40960 kB
HugePages_Total: 16
HugePages_Free: 16
HugePages_Rsvd: 0
HugePages_Surp: 0
$ java -XX:+UseLargePages Test
OpenJDK 64-Bit Server VM warning: Failed to reserve large pages memory req_addr: 0x0000000000000000 bytes: 251658240 (errno = 12).
OpenJDK 64-Bit Server VM warning: Failed to reserve large pages memory req_addr: 0x0000000707c00000 bytes: 4164943872 (errno = 12).
OpenJDK 64-Bit Server VM warning: Failed to reserve large pages memory req_addr: 0x0000000000000000 bytes: 67108864 (errno = 12).
OpenJDK 64-Bit Server VM warning: Failed to reserve large pages memory req_addr: 0x0000000000000000 bytes: 67108864 (errno = 12).
$ echo $?
0
strace confirms the failed allocation attempt and the successful retry with the same size but without MAP_HUGETLB:
11631 mmap(NULL, 251658240, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS|MAP_HUGETLB, -1, 0) = -1 ENOMEM (Cannot allocate memory)
11631 mmap(NULL, 251658240, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x7f35d489c000
Am trying to run Cassandra v3.11.3 on RHEL 7 system.
But facing memory errors while trying to start Cassandra.
Facing following error:
OpenJDK 64-Bit Server VM warning: INFO: os::commit_memory(0x0000000080000000, 1073741824, 0) failed; error='Cannot allocate memory' (errno=12)
#
# There is insufficient memory for the Java Runtime Environment to continue.
# Native memory allocation (mmap) failed to map 1073741824 bytes for committing reserved memory.
# An error report file with more information is saved as:
# /../../../hs_err_pid16347.log
hs_err_pid16347.log
#
# There is insufficient memory for the Java Runtime Environment to continue.
# Native memory allocation (mmap) failed to map 1073741824 bytes for committing reserved memory.
# Possible reasons:
# The system is out of physical RAM or swap space
# The process is running with CompressedOops enabled, and the Java Heap may be blocking the growth of the native heap
# Possible solutions:
# Reduce memory load on the system
# Increase physical memory or swap space
# Check if swap backing store is full
# Decrease Java heap size (-Xmx/-Xms)
# Decrease number of Java threads
# Decrease Java thread stack sizes (-Xss)
# Set larger code cache with -XX:ReservedCodeCacheSize=
# This output file may be truncated or incomplete.
#
# Out of Memory Error (os_linux.cpp:2760), pid=16347, tid=0x00007f7a61dec700
#
# JRE version: (8.0_212-b04) (build )
# Java VM: OpenJDK 64-Bit Server VM (25.212-b04 mixed mode linux-amd64 compressed oops)
# Core dump written. Default location: /../logs/core or core.16347
#
--------------- T H R E A D ---------------
Current thread (0x00007f7a5800dae0): JavaThread "Unknown thread" [_thread_in_vm, id=16349, stack(0x00007f7a61dad000,0x00007f7a61ded000)]
Stack: [0x00007f7a61dad000,0x00007f7a61ded000], sp=0x00007f7a61deb520, free space=249k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0xa7ffb2] VMError::report_and_die()+0x2e2
V [libjvm.so+0x4cae47] report_vm_out_of_memory(char const*, int, unsigned long, VMErrorType, char const*)+0x67
V [libjvm.so+0x8c0ed0] os::pd_commit_memory(char*, unsigned long, unsigned long, bool)+0x100
V [libjvm.so+0x8b85ff] os::commit_memory(char*, unsigned long, unsigned long, bool)+0x1f
V [libjvm.so+0xa7c2ac] VirtualSpace::initialize(ReservedSpace, unsigned long)+0x20c
V [libjvm.so+0x5cf3e6] Generation::Generation(ReservedSpace, unsigned long, int)+0x96
V [libjvm.so+0x4d4b80] DefNewGeneration::DefNewGeneration(ReservedSpace, unsigned long, int, char const*)+0x30
V [libjvm.so+0x8e24ef] ParNewGeneration::ParNewGeneration(ReservedSpace, unsigned long, int)+0x2f
V [libjvm.so+0x5d0d26] GenerationSpec::init(ReservedSpace, int, GenRemSet*)+0x3d6
V [libjvm.so+0x5bbbaf] GenCollectedHeap::initialize()+0x20f
V [libjvm.so+0xa4326a] Universe::initialize_heap()+0x16a
V [libjvm.so+0xa43553] universe_init()+0x33
V [libjvm.so+0x613000] init_globals()+0x50
V [libjvm.so+0xa24cc5] Threads::create_vm(JavaVMInitArgs*, bool*)+0x4e5
V [libjvm.so+0x68c691] JNI_CreateJavaVM+0x51
C [libjli.so+0x7f44] JavaMain+0x84
C [libpthread.so.0+0x7ea5] start_thread+0xc5
Did check "free -m" and there is enough memory available but still this error related to memory, what could be this related to? The -Xmn1G defined here.
Thinking enough memory available did try checking "ulimit -a" and updated as per this link recommendation https://serverfault.com/questions/662992/java-on-linux-insufficient-memory-even-though-there-is-plenty-of-available-memor
Rebooted the system and tried again to start Cassandra but still facing the same issue. Are there any additional settings at system level which needs to be updated here?
Also can anyone please share Cassdandra 3.11 and Operating System compatibility matrix?
I have a problem figuring out why ASAN gives this output, why I can't see where and in what line the bug is in my code, is this bug even in my code as it says or is it in some libraries that is used by the program?
This is how I build my project :
CC=clang CXX=clang++ meson -Db_sanitize=address -Db_lundef=false
build-clang
and then I configure the env values and run the executable like this :
ASAN_OPTIONS=symbolize=1
ASAN_SYMBOLIZER_PATH=/usr/bin/llvm-symbolizer ./executable
And yes that is a valid path for llvm-sybolizer
So is there a way for me to know what does executable+0x431340 mean and where it points to in my code?
=================================================================
==13110==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 16384 byte(s) in 1 object(s) allocated from:
#0 0x4e1340 in __interceptor_malloc (/home/maysara/Desktop/testscreen/build-clang/src/excutable+0x4e1340)
#1 0x7ff16a2ccab8 in g_malloc (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x51ab8)
Direct leak of 4352 byte(s) in 17 object(s) allocated from:
#0 0x4e1340 in __interceptor_malloc (/home/maysara/Desktop/testscreen/build-clang/src/excutable+0x4e1340)
#1 0x7ff165e518ed (/usr/lib/x86_64-linux-gnu/libfontconfig.so.1+0x1d8ed)
Direct leak of 3840 byte(s) in 6 object(s) allocated from:
#0 0x4e17c0 in realloc (/home/maysara/Desktop/testscreen/build-clang/src/excutable+0x4e17c0)
#1 0x7ff165e51998 (/usr/lib/x86_64-linux-gnu/libfontconfig.so.1+0x1d998)
Direct leak of 24 byte(s) in 1 object(s) allocated from:
#0 0x4e1340 in __interceptor_malloc (/home/maysara/Desktop/testscreen/build-clang/src/excutable+0x4e1340)
#1 0x7ff16a2ccab8 in g_malloc (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x51ab8)
#2 0x7ff168b5910c in g_closure_invoke (/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0+0x1010c)
Indirect leak of 10016 byte(s) in 313 object(s) allocated from:
#0 0x4e1340 in __interceptor_malloc (/home/maysara/Desktop/testscreen/build-clang/src/excutable+0x4e1340)
#1 0x7ff165e3ffef (/usr/lib/x86_64-linux-gnu/libfontconfig.so.1+0xbfef)
Indirect leak of 4887 byte(s) in 405 object(s) allocated from:
#0 0x43db60 in strdup (/home/maysara/Desktop/testscreen/build-clang/src/excutable+0x43db60)
#1 0x7ff165e512f4 in FcValueSave (/usr/lib/x86_64-linux-gnu/libfontconfig.so.1+0x1d2f4)
Indirect leak of 4320 byte(s) in 135 object(s) allocated from:
#0 0x4e1568 in calloc (/home/maysara/Desktop/testscreen/build-clang/src/excutable+0x4e1568)
#1 0x7ff165e51fd8 (/usr/lib/x86_64-linux-gnu/libfontconfig.so.1+0x1dfd8)
Indirect leak of 2400 byte(s) in 75 object(s) allocated from:
#0 0x4e1568 in calloc (/home/maysara/Desktop/testscreen/build-clang/src/excutable+0x4e1568)
#1 0x7ff165e515c4 (/usr/lib/x86_64-linux-gnu/libfontconfig.so.1+0x1d5c4)
Indirect leak of 576 byte(s) in 18 object(s) allocated from:
#0 0x4e1568 in calloc (/home/maysara/Desktop/testscreen/build-clang/src/excutable+0x4e1568)
#1 0x7ff165e51440 (/usr/lib/x86_64-linux-gnu/libfontconfig.so.1+0x1d440)
Indirect leak of 144 byte(s) in 3 object(s) allocated from:
#0 0x4e1340 in __interceptor_malloc (/home/maysara/Desktop/testscreen/build-clang/src/excutable+0x4e1340)
#1 0x7ff165e4bacd in FcLangSetCreate (/usr/lib/x86_64-linux-gnu/libfontconfig.so.1+0x17acd)
SUMMARY: AddressSanitizer: 46943 byte(s) leaked in 974 allocation(s).
In order to resolve the code addresses to source code locations, you need to compile the code with debug symbols enabled, e.g. with -g on the compiler command line or the commonly with build systems the environment variables CFLAGS and CXXFLAGS set accordingly:
CFLAGS="-g"
CXXFLAGS="-g"
That needs to be done for the code actually referenced, meaning here for example not only the code of executable, but also the linked libraries like glib, fontconfig, etc. if you want all addresses resolved.
Since these libraries are probably installed through a system package manager, you would need to look in your distribution's documentation how to install debug symbols. For Ubuntu, for example, there are usually variants of packages with an -dbg suffix.
In any case your stack traces do not look very helpful anyway, so it is not clear that finding the source code locations will be any help to you. You might want to recompile your executable with -fno-omit-frame-pointer and/or set the environment variable ASAN_OPTIONS=fast_unwind_on_malloc=0 when running the executable to try and improve them. See also the ASAN faq.
I just installed Oracle Coherence 3.6 on RHEL 5.5. When I execute cache-server.sh I get a lot of GC warnings about allocating large blocks and then it fails with a segmentation fault. Suggestions? Here is the stack:
GC Warning: Repeated allocation of very large block (appr. size 1024000):
May lead to memory leak and poor performance.
GC Warning: Repeated allocation of very large block (appr. size 1024000):
May lead to memory leak and poor performance.
./bin/cache-server.sh: line 24: 6142 Segmentation fault $JAVAEXEC -server -showversion $JAVA_OPTS -cp "$COHERENCE_HOME/lib/coherence.jar" com.tangosol.net.DefaultCacheServer $1
[root#localhost coherence_3.6]# swapon -s
Filename Type Size Used Priority
/dev/mapper/VolGroup00-LogVol01 partition 2097144 0 -1
[root#localhost coherence_3.6]# free
total used free shared buffers cached
Mem: 3631880 662792 2969088 0 142636 353244
-/+ buffers/cache: 166912 3464968
Swap: 2097144 0 2097144
[root#localhost coherence_3.6]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
147G 6.7G 133G 5% /
/dev/sda1 99M 12M 82M 13% /boot
tmpfs 1.8G 0 1.8G 0% /dev/shm
/dev/hdb 2.8G 2.8G 0 100% /media/RHEL_5.5 Source
/dev/hda 57M 57M 0 100% /media/VBOXADDITIONS_4.2.16_86992
[root#localhost coherence_3.6]#
I haven't seen this issue before, but to start, I'd suggest the following:
Check for Linux updates. The JVMs for example now try to use large pages, and there have been some bugs in RH related to large pages that are fixed in the latest versions.
Download the latest Java 7 JDK. While no JDK is entirely bug-free, we have done extensive testing with JDK 7 patch levels 15, 21 and 40.
Download the latest version of Coherence. Coherence 12.1.2 is now out, but if you don't want to go for the very latest, then Coherence 3.7.1 is the suggested version. (The release after 3.7.1 is called 12.1.2. That is to align with Oracle versioning.)
I would check your space allocation on disk and memory/swap. You are probably running out of space somewhere.
df -h
free
You could also check your Java version - make sure that you are well patched.
Are you using Java 6 or Java 7?
There are Oracle forums for Coherence - you should try and ask the question there - thats where the real experts hang out.