I have the following situation (Ubuntu 15.10 and Debian Testing)
I have Lib A which is compiled without cxx11 and a lib B that uses -std=c++11. B includes and links against A, A uses boost.
If i link B to A, the application a A created crashes during dynload.
If i compile A without cxx11 or B with cxx11 everything works fine.
My question: as far i understood the ABI namespace add on should guarantee shuch kind of problem. Am i wrong here?
I created a example project to clarify the problem:
https://github.com/goldhoorn/sandbox/tree/gcc5.2-issue
test1 failed, the other tests passing.
GDB tells me:
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7bceb2e in _GLOBAL__sub_I_Lib.cpp () from ./libmyLib.so
(gdb) bt
#0 0x00007ffff7bceb2e in _GLOBAL__sub_I_Lib.cpp () from ./libmyLib.so
#1 0x00007ffff7deaa0a in call_init (l=<optimized out>, argc=argc#entry=1,
argv=argv#entry=0x7fffffffe688, env=env#entry=0x7fffffffe698)
at dl-init.c:78
#2 0x00007ffff7deaaf3 in call_init (env=0x7fffffffe698, argv=0x7fffffffe688,
argc=1, l=<optimized out>) at dl-init.c:36
#3 _dl_init (main_map=0x7ffff7ffe1a8, argc=1, argv=0x7fffffffe688,
env=0x7fffffffe698) at dl-init.c:126
#4 0x00007ffff7ddd1ca in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
#5 0x0000000000000001 in ?? ()
#6 0x00007fffffffe89f in ?? ()
#7 0x0000000000000000 in ?? ()
Result from Valgrind:
goldhoorn#debian:/tmp/example$ LD_LIBRARY_PATH=. valgrind --show-below-main=yes ./main
==17140== Memcheck, a memory error detector
==17140== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==17140== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==17140== Command: ./main
==17140==
==17140==
==17140== Process terminating with default action of signal 11 (SIGSEGV)
==17140== Bad permissions for mapped region at address 0x401FE8
==17140== at 0x4E3EB2E: _GLOBAL__sub_I_Lib.cpp (in /tmp/example/libmyLib.so)
==17140== by 0x400EA09: call_init.part.0 (dl-init.c:78)
==17140== by 0x400EAF2: call_init (dl-init.c:36)
==17140== by 0x400EAF2: _dl_init (dl-init.c:126)
==17140== by 0x40011C9: ??? (in /lib/x86_64-linux-gnu/ld-2.19.so)
==17140==
==17140== HEAP SUMMARY:
==17140== in use at exit: 72,704 bytes in 1 blocks
==17140== total heap usage: 1 allocs, 0 frees, 72,704 bytes allocated
==17140==
==17140== LEAK SUMMARY:
==17140== definitely lost: 0 bytes in 0 blocks
==17140== indirectly lost: 0 bytes in 0 blocks
==17140== possibly lost: 0 bytes in 0 blocks
==17140== still reachable: 72,704 bytes in 1 blocks
==17140== suppressed: 0 bytes in 0 blocks
==17140== Rerun with --leak-check=full to see details of leaked memory
==17140==
==17140== For counts of detected and suppressed errors, rerun with: -v
==17140== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Segmentation fault
Please check your library A against the list of Cxx11 ABI backward incompatibilities: https://gcc.gnu.org/wiki/Cxx11AbiCompatibility
The C++98 language is ABI-compatible with the C++11 language, but several places in the library break compatibility. This makes it dangerous to link C++98 objects with C++11 objects.
Related
I've created a c++ app in an arm embedded board .The board uses armbian linux debian flavour. This app in several places execute https request with the help of poco NetSSl library.
When I run the valgrind with the following arguments:
valgrind --leak-check=full --leak-resolution=high --show-reachable=yes --num-callers=20 --track-origins=yes --show-below-main=yes --log-file=valrgind.log ./c++_app
I get the following error message :
==2414== Memcheck, a memory error detector
==2414== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==2414== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
==2414== Command: ./c++_app
==2414== Parent PID: 1556
==2414==
disInstr(thumb): unhandled instruction: 0xEC51 0x0F1E
==2414== valgrind: Unrecognised instruction at address 0x52a17e7.
==2414== at 0x52A17E6: ??? (in /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.1)
==2414== Your program just tried to execute an instruction that Valgrind
==2414== did not recognise. There are two possible reasons for this.
==2414== 1. Your program has a bug and erroneously jumped to a non-code
==2414== location. If you are running Memcheck and you just saw a
==2414== warning about a bad jump, it's probably your program's fault.
==2414== 2. The instruction is legitimate but Valgrind doesn't handle it,
==2414== i.e. it's Valgrind's fault. If you think this is the case or
==2414== you are not sure, please let us know and we'll try to fix it.
==2414== Either way, Valgrind will now raise a SIGILL signal which will
==2414== probably kill your program.
==2414== Thread 5:
==2414== Syscall param write(buf) points to uninitialised byte(s)
==2414== at 0x5153D12: write (syscall-template.S:84)
==2414== by 0x52B8A29: ??? (in /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.1)
==2414== Address 0x59d78f6 is 382 bytes inside a block of size 16,472 alloc'd
==2414== at 0x483E8DC: malloc (vg_replace_malloc.c:299)
==2414== by 0x5217FCB: ??? (in /usr/lib/arm-linux-gnueabihf/libssl.so.1.1)
==2414== Uninitialised value was created by a heap allocation
==2414== at 0x483E8DC: malloc (vg_replace_malloc.c:299)
==2414== by 0x52CE4FB: BUF_MEM_grow_clean (in /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.1)
==2414==
==2414==
==2414== HEAP SUMMARY:
==2414== in use at exit: 400 bytes in 2 blocks
==2414== total heap usage: 57,828 allocs, 57,826 frees, 4,335,151 bytes allocated
==2414==
==2414== Thread 1:
==2414== 400 bytes in 2 blocks are definitely lost in loss record 1 of 1
==2414== at 0x483E8DC: malloc (vg_replace_malloc.c:299)
==2414== by 0x5332337: CRYPTO_zalloc (in /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.1)
==2414==
==2414== LEAK SUMMARY:
==2414== definitely lost: 400 bytes in 2 blocks
==2414== indirectly lost: 0 bytes in 0 blocks
==2414== possibly lost: 0 bytes in 0 blocks
==2414== still reachable: 0 bytes in 0 blocks
==2414== suppressed: 0 bytes in 0 blocks
==2414==
==2414== For counts of detected and suppressed errors, rerun with: -v
==2414== ERROR SUMMARY: 3 errors from 2 contexts (suppressed: 0 from 0)
Since I've dealt with similar problems when using gdb I gave export OPENSSL_armcap=0 and then I got the following:
==2435== Memcheck, a memory error detector
==2435== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==2435== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
==2435== Command: ./c++_app
==2435== Parent PID: 1556
==2435==
==2435==
==2435== HEAP SUMMARY:
==2435== in use at exit: 400 bytes in 2 blocks
==2435== total heap usage: 158,181 allocs, 158,179 frees, 11,872,290 bytes allocated
==2435==
==2435== 400 bytes in 2 blocks are definitely lost in loss record 1 of 1
==2435== at 0x483E8DC: malloc (vg_replace_malloc.c:299)
==2435== by 0x5332337: CRYPTO_zalloc (in /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.1)
==2435==
==2435== LEAK SUMMARY:
==2435== definitely lost: 400 bytes in 2 blocks
==2435== indirectly lost: 0 bytes in 0 blocks
==2435== possibly lost: 0 bytes in 0 blocks
==2435== still reachable: 0 bytes in 0 blocks
==2435== suppressed: 0 bytes in 0 blocks
==2435==
==2435== For counts of detected and suppressed errors, rerun with: -v
==2435== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
However no additional info was retrieved even though I've compiled the code with -ggdb3.
The info that I get from openssl version -a is:
OpenSSL 1.1.0j 20 Nov 2018
built on: reproducible build, date unspecified
platform: debian-armhf
options: bn(64,32) rc4(char) des(long) blowfish(ptr)
compiler: gcc -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/lib/ssl\"" -DENGINESDIR="\"/usr/lib/arm-linux-gnueabihf/engines-1.1\""
OPENSSLDIR: "/usr/lib/ssl"
ENGINESDIR: "/usr/lib/arm-linux-gnueabihf/engines-1.1"
I've found several issues regarding memory leaks of the openssl but not one with so limited info.
Does anyone know if this memory leak is caused by libcrypto or false alarm of valgrind and is there any way to get additional info?
I have already seen this a few times. So far it was always a fault in my code. Because you shared no code, I can only give the latest issue in my case which caused this.
I was allocating a MAC code with the new OpenSSL 3 API with:
EVP_MAC *_mac = EVP_MAC_fetch(NULL, "cmac", NULL);
I forgot to deallocate this with:
EVP_MAC_free(_mac);
Here is my valgrind output
$ valgrind --leak-check=full --show-leak-kinds=all --track-origins=yes new
==14028== Memcheck, a memory error detector
==14028== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==14028== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==14028== Command: new
==14028==
allocated
deleted
==14028==
==14028== HEAP SUMMARY:
==14028== in use at exit: 72,704 bytes in 1 blocks
==14028== total heap usage: 2 allocs, 1 frees, 72,754 bytes allocated
==14028==
==14028== 72,704 bytes in 1 blocks are still reachable in loss record 1 of 1
==14028== at 0x4C29C23: malloc (vg_replace_malloc.c:299)
==14028== by 0x4EBF18F: pool (eh_alloc.cc:117)
==14028== by 0x4EBF18F: __static_initialization_and_destruction_0 (eh_alloc.cc:244)
==14028== by 0x4EBF18F: _GLOBAL__sub_I_eh_alloc.cc (eh_alloc.cc:307)
==14028== by 0x400FB02: _dl_init (in /usr/lib64/ld-2.17.so)
==14028== by 0x4001069: ??? (in /usr/lib64/ld-2.17.so)
==14028==
==14028== LEAK SUMMARY:
==14028== definitely lost: 0 bytes in 0 blocks
==14028== indirectly lost: 0 bytes in 0 blocks
==14028== possibly lost: 0 bytes in 0 blocks
==14028== still reachable: 72,704 bytes in 1 blocks
==14028== suppressed: 0 bytes in 0 blocks
==14028==
==14028== For counts of detected and suppressed errors, rerun with: -v
==14028== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
As you can see the extra alloc seems to be from some source I can't identify, valgrind lists it as ???. Is this just some weird allocation behind the scenes? Should I worry about it?
This allocation/'still reachable' memory report is normal, and has been reported on valgrind bugzilla (and fixed) : see a.o. bugs https://bugs.kde.org/show_bug.cgi?id=345307 and https://bugs.kde.org/show_bug.cgi?id=348978.
You might need to upgrade to a newer valgrind and/or newer ld/glibc/... to have all that fixed.
If you cannot upgrade yet, in the meantime, you can use a suppression file.
Run valgrind + your program with the valgrind option --gen-suppressions=yes (or =all) to provide the needed suppression entry.
I try to send via curl request from c++ on my macOS (for example on linux works everything fine). But when I run the program via valgrind and then try to send request over curl then the program fails with a segmentation fault. Even on code from here https://curl.haxx.se/libcurl/c/https.html and I also try the curl command from terminal with valgrind and even then it failed but it must be https. I tried the curl with openssl and darwinssl but without success.
My os is macOS high sierra.
The output from valgrind:
valgrind ./demo
==78893== Memcheck, a memory error detector
==78893== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==78893== Using Valgrind-3.14.0.GIT and LibVEX; rerun with -h for copyright info
==78893== Command: ./demo
==78893==
--78893-- run: /usr/bin/dsymutil "./demo" warning: no debug symbols in executable (-arch x86_64)
--78893-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option
--78893-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 2 times)
--78893-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 4 times)
--78893-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 8 times)
==78893== Thread 2:
==78893== Invalid read of size 4
==78893== at 0x100AB45BA: _pthread_body (in /usr/lib/system/libsystem_pthread.dylib)
==78893== by 0x100AB450C: _pthread_start (in /usr/lib/system/libsystem_pthread.dylib)
==78893== by 0x100AB3BF8: thread_start (in /usr/lib/system/libsystem_pthread.dylib)
==78893== Address 0x18 is not stack'd, malloc'd or (recently) free'd
==78893==
==78893==
==78893== Process terminating with default action of signal 11 (SIGSEGV)
==78893== Access not within mapped region at address 0x18
==78893== at 0x100AB45BA: _pthread_body (in /usr/lib/system/libsystem_pthread.dylib)
==78893== by 0x100AB450C: _pthread_start (in /usr/lib/system/libsystem_pthread.dylib)
==78893== by 0x100AB3BF8: thread_start (in /usr/lib/system/libsystem_pthread.dylib)
==78893== If you believe this happened as a result of a stack
==78893== overflow in your program's main thread (unlikely but
==78893== possible), you can try to increase the size of the
==78893== main thread stack using the --main-stacksize= flag.
==78893== The main thread stack size used in this run was 8388608.
==78893==
==78893== HEAP SUMMARY:
==78893== in use at exit: 840,095 bytes in 3,760 blocks
==78893== total heap usage: 4,784 allocs, 1,024 frees, 1,520,703 bytes allocated
==78893==
==78893== LEAK SUMMARY:
==78893== definitely lost: 5,792 bytes in 78 blocks
==78893== indirectly lost: 416 bytes in 12 blocks
==78893== possibly lost: 4,648 bytes in 111 blocks
==78893== still reachable: 208,644 bytes in 3,290 blocks
==78893== suppressed: 620,595 bytes in 269 blocks
==78893== Rerun with --leak-check=full to see details of leaked memory
==78893==
==78893== For counts of detected and suppressed errors, rerun with: -v
==78893== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 25 from 4) Segmentation fault: 11
Also you can try write to command line: "valgrind curl https://example.com"
It causing same exception.
I have around 350 lines code where I am parsing xml file and creating another 2 sheets out of it using C++.
After adding the last 2 or 3 functions I started having memory error,
Signal: SIGSEGV (Segmentation fault)
Removing them didn't solve the error so definitely I edited something else. I searched online and found about valgrind which showed me errors that I can't translate.
As per the valgrind manual, I have to check from below to up so as per the last one,
==7276== 4,064 bytes in 1 blocks are definitely lost in loss record 52 of 54
==7276== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==7276== by 0x456BDD: ??? (in /usr/bin/g++-5)
==7276== by 0x4EC260D: _obstack_begin (obstack.c:176)
==7276== by 0x456FCE: ??? (in /usr/bin/g++-5)
==7276== by 0x43BA49: ??? (in /usr/bin/g++-5)
==7276== by 0x43BAC0: ??? (in /usr/bin/g++-5)
==7276== by 0x4E5A82F: (below main) (libc-start.c:291)
For line 291 is the append line in the below code,
if (vlan_ether)
sprintf(cConfStr, "**.Switch%ld.eth[%d].queue.VlanClassifier = true\n", srcindex + 1, portno);
else if (!vlan_ether)
sprintf(cConfStr, "**.Switch%ld.eth[%d].queue.etherType = false\n", srcindex + 1, portno);
else
cout << "Switch" << srcindex + 1 << "port# " << portno << " Classifier is not specified." << endl;
confStr.append(string(cConfStr));
Removing the above lines didn't do any change, while line 176 is a comment so am hesitating that valgrind is not showing the lines of error.
So I am not sure what to show you in my question from the code. Still I am definite that it should be related to string and char usage In which I used them several times.
char cNedStr[600];
char cConfStr[600];
sprintf(cConfStr, "%d ", intervalvector[q]);
confStr.append(string(cConfStr));
The Valgrind result as per below,
amr#amr-PC:~$ valgrind --leak-check=yes g++ main.cpp pugixml.cpp headers.h -Wall -std=c++11
EDIT:
amr#amr-PC:~/ClionProjects/converter$ valgrind ./a.out
==7624== Memcheck, a memory error detector
==7624== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==7624== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==7624== Command: ./a.out
==7624== Invalid free() / delete / delete[] / realloc()
==7624== at 0x4C2F24B: operator delete(void*) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==7624== by 0x5714FF7: __run_exit_handlers (exit.c:82)
==7624== by 0x5715044: exit (exit.c:104)
==7624== by 0x56FB836: (below main) (libc-start.c:325)
==7624== Address 0x35663a37323a6536 is not stack'd, malloc'd or (recently) free'd
==7624==
==7624==
==7624== HEAP SUMMARY:
==7624== in use at exit: 72,704 bytes in 1 blocks
==7624== total heap usage: 525 allocs, 525 frees, 214,887 bytes allocated
==7624==
==7624== LEAK SUMMARY:
==7624== definitely lost: 0 bytes in 0 blocks
==7624== indirectly lost: 0 bytes in 0 blocks
==7624== possibly lost: 0 bytes in 0 blocks
==7624== still reachable: 72,704 bytes in 1 blocks
==7624== suppressed: 0 bytes in 0 blocks
==7624== Rerun with --leak-check=full to see details of leaked memory
==7624==
==7624== For counts of detected and suppressed errors, rerun with: -v
==7624== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
First compile, without the header file, (default output is a.out):
g++ main.cpp pugixml.cpp -Wall -std=c++11
Then check using valgrind:
valgrind --leak-check=yes ./a.out
Other comments:
You could consider adding the following flags to g++:
-Wextra (more warnings)
-pedantic (turns off extensions and generates more warnings)
-g (debug symbols)
-O3 (maximum optimization, not recommended for debugging!)
valgrind prints the following diagnostic from an empty program:
$cat main.cpp
int main(){}
$g++ -std=c++1z -o main main.cpp
$valgrind --leak-check=full --show-leak-kinds=all ./main
==26823== Memcheck, a memory error detector
==26823== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==26823== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==26823== Command: ./main
==26823==
==26823==
==26823== HEAP SUMMARY:
==26823== in use at exit: 72,704 bytes in 1 blocks
==26823== total heap usage: 1 allocs, 0 frees, 72,704 bytes allocated
==26823==
==26823== 72,704 bytes in 1 blocks are still reachable in loss record 1 of 1
==26823== at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==26823== by 0x4E9D62F: ??? (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.22)
==26823== by 0x4010109: call_init.part.0 (dl-init.c:78)
==26823== by 0x40101F2: call_init (dl-init.c:36)
==26823== by 0x40101F2: _dl_init (dl-init.c:126)
==26823== by 0x4001309: ??? (in /lib/x86_64-linux-gnu/ld-2.19.so)
==26823==
==26823== LEAK SUMMARY:
==26823== definitely lost: 0 bytes in 0 blocks
==26823== indirectly lost: 0 bytes in 0 blocks
==26823== possibly lost: 0 bytes in 0 blocks
==26823== still reachable: 72,704 bytes in 1 blocks
==26823== suppressed: 0 bytes in 0 blocks
==26823==
==26823== For counts of detected and suppressed errors, rerun with: -v
==26823== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Notice how it states:
"total heap usage: 1 allocs, 0 frees".
It is consistently off by 1 for programs where I also allocate and manage memory properly. This seems to be an issue with the lib standard itself? How can I fix this? I can't seem to find a compiler flag to prevent this.
I have the same issue using the clang++ frontend.