I am using this tutorial to analyze the dump file generated on kernel crash.
The dump file is successfully generated and I am able to access it using crash utility.
/* Code for the kernel module */
#include<linux/module.h>
#include<linux/kernel.h>
#include<linux/types.h>
static s32 __init testmoduleinit(void)
{
s8 *ptr = NULL;
pr_info("%s:module loaded.\n", __func__);
*ptr = 100; // generate oops
return 0;
}
static void __exit testmoduledeinit(void)
{
pr_info("%s:module un-loaded.\n", __func__);
}
module_init(testmoduleinit);
module_exit(testmoduledeinit);
MODULE_LICENSE("GPL");
The crash logs(backtrace output) are as follows.
crash> bt
PID: 3401 TASK: ffff9d6928b3af00 CPU: 2 COMMAND: "insmod"
#0 [ffffb2bd846478c8] machine_kexec at ffffffff9246fe83
#1 [ffffb2bd84647928] __crash_kexec at ffffffff9255a152
#2 [ffffb2bd846479f8] crash_kexec at ffffffff9255aff1
#3 [ffffb2bd84647a18] oops_end at ffffffff9243633d
#4 [ffffb2bd84647a40] no_context at ffffffff924803c9
#5 [ffffb2bd84647ab0] __bad_area_nosemaphore at ffffffff924807c0
#6 [ffffb2bd84647af8] bad_area_nosemaphore at ffffffff92480976
#7 [ffffb2bd84647b08] __do_page_fault at ffffffff9248133d
#8 [ffffb2bd84647b70] do_page_fault at ffffffff9248162c
#9 [ffffb2bd84647ba0] page_fault at ffffffff93001284
[exception RIP: _MODULE_INIT_START_gencrash+44]
RIP: ffffffffc062b02c RSP: ffffb2bd84647c58 RFLAGS: 00010282
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffff9d6935c9c8c8 RDI: ffff9d6935c9c8c8
RBP: ffffb2bd84647c60 R8: 0000000000000722 R9: 0000000000000004
R10: ffff9d693219f730 R11: 0000000000000001 R12: ffffffffc062b000
R13: ffff9d693219f730 R14: ffffb2bd84647e68 R15: ffffffffc0628000
ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018
#10 [ffffb2bd84647c68] do_one_initcall at ffffffff9240389a
#11 [ffffb2bd84647ce0] do_init_module at ffffffff92edd493
#12 [ffffb2bd84647d08] load_module at ffffffff92556e1b
#13 [ffffb2bd84647e48] __do_sys_finit_module at ffffffff9255773c
#14 [ffffb2bd84647f20] __x64_sys_finit_module at ffffffff9255777a
#15 [ffffb2bd84647f30] do_syscall_64 at ffffffff92405207
#16 [ffffb2bd84647f50] entry_SYSCALL_64_after_hwframe at ffffffff9300008c
RIP: 00007f7f2613c539 RSP: 00007fff5ba4f6a8 RFLAGS: 00000246
RAX: ffffffffffffffda RBX: 000056442b32d7c0 RCX: 00007f7f2613c539
RDX: 0000000000000000 RSI: 0000564429214d2e RDI: 0000000000000003
RBP: 0000564429214d2e R8: 0000000000000000 R9: 00007f7f2640f000
R10: 0000000000000003 R11: 0000000000000246 R12: 0000000000000000
R13: 000056442b32d760 R14: 0000000000000000 R15: 0000000000000000
ORIG_RAX: 0000000000000139 CS: 0033 SS: 002b
The "bt" logs show that page fault is generated at address ffffffffc062b02c.
But when I do
crash> mod -s test_module ./test_module.o
crash> sym ffffffffc062b02c
I don't see the line number in source code which is generating crash.
Is there any way to get the line number from the kernel module which is causing the oops condition.
I always got a crash report from libart-compiler.so in android 8.1.0 and what it's all about?
this bug can happen at any time,anyone knows how to fix it ?
--------- beginning of crash
08-03 09:50:00.972 2566 2572 F libc : Fatal signal 11 (SIGSEGV), code 1, fault addr 0x9b045e80 in tid 2572 (Jit thread pool), pid 2566 (r.iot.show.core)
08-03 09:50:01.175 3110 3110 F DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
08-03 09:50:01.176 3110 3110 F DEBUG : Build fingerprint: 'XHF/XHF_H003/XHF_H003:8.1.0/OPM1.171019.026/20210802-152226:userdebug/test-keys'
08-03 09:50:01.176 3110 3110 F DEBUG : Revision: '0'
08-03 09:50:01.176 3110 3110 F DEBUG : ABI: 'arm'
08-03 09:50:01.176 3110 3110 F DEBUG : pid: 2566, tid: 2572, name: Jit thread pool >>> com.iflytek.cyber.iot.show.core <<<
08-03 09:50:01.176 3110 3110 F DEBUG : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x9b045e80
08-03 09:50:01.176 3110 3110 F DEBUG : r0 9b045e80 r1 00000045 r2 fc114286 r3 ffffffff
08-03 09:50:01.176 3110 3110 F DEBUG : r4 00000045 r5 9b253c28 r6 9b045e80 r7 9b25b240
08-03 09:50:01.176 3110 3110 F DEBUG : r8 9b25e380 r9 9b25e380 sl 00000161 fp 00000000
08-03 09:50:01.176 3110 3110 F DEBUG : ip 0000000f sp 9d9122d0 lr 9dd106db pc 9dce9cea cpsr a00d0030
08-03 09:50:01.314 3110 3110 F DEBUG :
08-03 09:50:01.314 3110 3110 F DEBUG : backtrace:
08-03 09:50:01.315 3110 3110 F DEBUG : #00 pc 000f4cea /system/lib/libart-compiler.so (art::HEnvironment::RemoveAsUserOfInput(unsigned int) const+41)
08-03 09:50:01.315 3110 3110 F DEBUG : #01 pc 0011b6d7 /system/lib/libart-compiler.so (art::LiveInterval::FindFirstRegisterHint(unsigned int*, art::SsaLivenessAnalysis const&) const+222)
08-03 09:50:01.315 3110 3110 F DEBUG : #02 pc 001142f3 /system/lib/libart-compiler.so (art::RegisterAllocatorLinearScan::TryAllocateFreeReg(art::LiveInterval*)+334)
08-03 09:50:01.315 3110 3110 F DEBUG : #03 pc 00113bd5 /system/lib/libart-compiler.so (art::RegisterAllocatorLinearScan::LinearScan()+704)
08-03 09:50:01.315 3110 3110 F DEBUG : #04 pc 00112c63 /system/lib/libart-compiler.so (art::RegisterAllocatorLinearScan::AllocateRegistersInternal()+334)
08-03 09:50:01.315 3110 3110 F DEBUG : #05 pc 00112a9d /system/lib/libart-compiler.so (art::RegisterAllocatorLinearScan::AllocateRegisters()+20)
08-03 09:50:01.315 3110 3110 F DEBUG : #06 pc 00102489 /system/lib/libart-compiler.so (art::AllocateRegisters(art::HGraph*, art::CodeGenerator*, art::PassObserver*, art::RegisterAllocator::Strategy)+284)
08-03 09:50:01.315 3110 3110 F DEBUG : #07 pc 00101dc3 /system/lib/libart-compiler.so (art::OptimizingCompiler::TryCompile(art::ArenaAllocator*, art::CodeVectorAllocator*, art::DexFile::CodeItem const*, unsigned int, art::InvokeType, unsigned short, unsigned int, art::Handle<art::mirror::ClassLoader>, art::DexFile const&, art::Handle<art::mirror::DexCache>, art::ArtMethod*, bool, art::VariableSizedHandleScope*) const+2326)
08-03 09:50:01.316 3110 3110 F DEBUG : #08 pc 001032fd /system/lib/libart-compiler.so (art::OptimizingCompiler::JitCompile(art::Thread*, art::jit::JitCodeCache*, art::ArtMethod*, bool, art::jit::JitLogger*)+612)
08-03 09:50:01.316 3110 3110 F DEBUG : #09 pc 000a09b9 /system/lib/libart-compiler.so (art::jit::JitCompiler::CompileMethod(art::Thread*, art::ArtMethod*, bool)+92)
08-03 09:50:01.316 3110 3110 F DEBUG : #10 pc 00266a55 /system/lib/libart.so (art::jit::Jit::CompileMethod(art::ArtMethod*, art::Thread*, bool)+288)
08-03 09:50:01.316 3110 3110 F DEBUG : #11 pc 0026884b /system/lib/libart.so (art::jit::JitCompileTask::Run(art::Thread*)+406)
08-03 09:50:01.316 3110 3110 F DEBUG : #12 pc 003948b9 /system/lib/libart.so (art::ThreadPoolWorker::Run()+44)
08-03 09:50:01.316 3110 3110 F DEBUG : #13 pc 003944eb /system/lib/libart.so (art::ThreadPoolWorker::Callback(void*)+90)
08-03 09:50:01.316 3110 3110 F DEBUG : #14 pc 00047b93 /system/lib/libc.so (__pthread_start(void*)+22)
08-03 09:50:01.316 3110 3110 F DEBUG : #15 pc 0001b057 /system/lib/libc.so (__start_thread+32)
I want to build the React-Native code with the option to debug native code (Java & C++), what I did till now:
Clone react-native source code
Added NDK_DEBUG=1 to buildReactNdkLib gradle task - code
I had to add some files to the make file of the folly project - code
I added the command not to stip the .so files in one of the makefiles - code - actually I was sure that NDK_DEBUG=1 is doing this by default, but it wasn't
The result is that the build is passing and the so files are really not-stripped, but the app crashes in Runtime
2019-04-06 11:24:31.058 24906-24906/? A/DEBUG: pid: 24850, tid: 24890, name: mqt_js >>> com.facebook.react.uiapp <<<
2019-04-06 11:24:31.058 24906-24906/? A/DEBUG: signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
2019-04-06 11:24:31.059 24906-24906/? A/DEBUG: Abort message: 'java_vm_ext.cc:504] JNI DETECTED ERROR IN APPLICATION: JNI GetObjectRefType called with pending exception com.facebook.react.uimanager.IllegalViewOperationException: No ViewManager defined for class Text'
2019-04-06 11:24:31.059 24906-24906/? A/DEBUG: eax 00000000 ebx 00006112 ecx 0000613a edx 00000006
2019-04-06 11:24:31.059 24906-24906/? A/DEBUG: esi 0000613a edi 878553d8
2019-04-06 11:24:31.059 24906-24906/? A/DEBUG: xcs 00000073 xds 0000007b xes 0000007b xfs 0000003b xss 0000007b
2019-04-06 11:24:31.059 24906-24906/? A/DEBUG: eip ad1d7ac4 ebp 878553f8 esp 8785538c flags 00000296
2019-04-06 11:24:31.070 24906-24906/? A/DEBUG: backtrace:
2019-04-06 11:24:31.070 24906-24906/? A/DEBUG: #00 pc 00000ac4 [vdso:ad1d7000] (__kernel_vsyscall+16)
2019-04-06 11:24:31.070 24906-24906/? A/DEBUG: #01 pc 00075b3c /system/lib/libc.so (tgkill+28)
2019-04-06 11:24:31.070 24906-24906/? A/DEBUG: #02 pc 0001f04e /system/lib/libc.so (abort+110)
2019-04-06 11:24:31.070 24906-24906/? A/DEBUG: #03 pc 0053bcbd /system/lib/libart.so (_ZN3art7Runtime5AbortEPKc+669)
2019-04-06 11:24:31.070 24906-24906/? A/DEBUG: #04 pc 0053c599 /system/lib/libart.so (_ZN3art7Runtime7AborterEPKc+41)
2019-04-06 11:24:31.070 24906-24906/? A/DEBUG: #05 pc 0011c3d3 /system/lib/libart.so (_ZNSt3__110__function6__funcIPFvPKcENS_9allocatorIS5_EES4_EclEOS3_+35)
2019-04-06 11:24:31.070 24906-24906/? A/DEBUG: #06 pc 0065168a /system/lib/libart.so (_ZN7android4base10LogMessageD1Ev+1034)
2019-04-06 11:24:31.070 24906-24906/? A/DEBUG: #07 pc 00386952 /system/lib/libart.so (_ZN3art9JavaVMExt8JniAbortEPKcS2_+2146)
2019-04-06 11:24:31.071 24906-24906/? A/DEBUG: #08 pc 00386bd1 /system/lib/libart.so (_ZN3art9JavaVMExt9JniAbortVEPKcS2_Pc+113)
2019-04-06 11:24:31.071 24906-24906/? A/DEBUG: #09 pc 0014ec45 /system/lib/libart.so (_ZN3art11ScopedCheck6AbortFEPKcz+69)
2019-04-06 11:24:31.072 24906-24906/? A/DEBUG: #10 pc 0014e710 /system/lib/libart.so (_ZN3art11ScopedCheck11CheckThreadEP7_JNIEnv+544)
2019-04-06 11:24:31.072 24906-24906/? A/DEBUG: #11 pc 0014d311 /system/lib/libart.so (_ZN3art11ScopedCheck22CheckPossibleHeapValueERNS_18ScopedObjectAccessEcNS_12JniValueTypeE+161)
2019-04-06 11:24:31.072 24906-24906/? A/DEBUG: #12 pc 0014c8b3 /system/lib/libart.so (_ZN3art11ScopedCheck5CheckERNS_18ScopedObjectAccessEbPKcPNS_12JniValueTypeE+1155)
2019-04-06 11:24:31.072 24906-24906/? A/DEBUG: #13 pc 0014bf36 /system/lib/libart.so (_ZN3art8CheckJNI16GetObjectRefTypeEP7_JNIEnvP8_jobject+998)
2019-04-06 11:24:31.072 24906-24906/? A/DEBUG: #14 pc 000e2fce /data/app/com.facebook.react.uiapp-uUhqD6BXzpF-7FnHQHBjIA==/lib/x86/libreactnativejni.so (_ZN7_JNIEnv16GetObjectRefTypeEP8_jobject+62)
Just found the answer, I don't need set NDK_DEBUG=1, all the not-stripped files placed under build/tmp/buildReactNdkLib/local//
You just need to configure the symbol directory in Android-Studio:
I'm going crazy and after I have googled without answer I'm going to try to write here.
I have Ubuntu 16.04, GCC 5.4.0, Poco 1.7.8-all and OpenSSL 1.1.0e.
and these few lines of code:
int main()
{
const std::string AES_NAME = "aes-128-cbc";
Cipher::Ptr uptrCipher = CipherFactory::defaultFactory().createCipher(CipherKey(AES_NAME, "abcdef", "123456"));
std::string plainText = "This is my secret information";
std::string encrypted = uptrCipher->encryptString(plainText, Cipher::ENC_BASE64);
return 0;
}
If I run Valgrind I got this error (my apologize for the lengh):
valgrind --leak-check=full ./CipherTest
==32223== Memcheck, a memory error detector
==32223== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==32223== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==32223== Command: ./CipherTest
==32223==
==32223== Invalid free() / delete / delete[] / realloc()
==32223== at 0x4C2F24B: operator delete(void*) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==32223== by 0x5A3F369: __cxa_finalize (cxa_finalize.c:56)
==32223== by 0x687CAB2: ??? (in /usr/local/lib/libPocoFoundationd.so.48)
==32223== by 0x4010C16: _dl_fini (dl-fini.c:235)
==32223== by 0x5A3EFF7: __run_exit_handlers (exit.c:82)
==32223== by 0x5A3F044: exit (exit.c:104)
==32223== by 0x5A25836: (below main) (libc-start.c:325)
==32223== Address 0x737a9d0 is 0 bytes inside a block of size 20 free'd
==32223== at 0x4C2F24B: operator delete(void*) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==32223== by 0x5A3F369: __cxa_finalize (cxa_finalize.c:56)
==32223== by 0x4ED7542: ??? (in /usr/local/lib/libPocoFoundation.so.48)
==32223== by 0x4010C16: _dl_fini (dl-fini.c:235)
==32223== by 0x5A3EFF7: __run_exit_handlers (exit.c:82)
==32223== by 0x5A3F044: exit (exit.c:104)
==32223== by 0x5A25836: (below main) (libc-start.c:325)
==32223== Block was alloc'd at
==32223== at 0x4C2E0EF: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==32223== by 0x4F69C0C: ??? (in /usr/local/lib/libPocoFoundation.so.48)
==32223== by 0x4ED7212: ??? (in /usr/local/lib/libPocoFoundation.so.48)
==32223== by 0x40104E9: call_init.part.0 (dl-init.c:72)
==32223== by 0x40105FA: call_init (dl-init.c:30)
==32223== by 0x40105FA: _dl_init (dl-init.c:120)
==32223== by 0x4000CF9: ??? (in /lib/x86_64-linux-gnu/ld-2.23.so)
==32223==
==32223==
==32223== HEAP SUMMARY:
==32223== in use at exit: 73,124 bytes in 13 blocks
==32223== total heap usage: 3,914 allocs, 3,912 frees, 256,412 bytes allocated
==32223==
==32223== 18 bytes in 1 blocks are definitely lost in loss record 1 of 13
==32223== at 0x4C2E0EF: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==32223== by 0x558EAEC: void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char const*>(char const*, char const*, std::forward_iterator_tag) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==32223== by 0x558EC4B: std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==32223== by 0x688F40D: __static_initialization_and_destruction_0(int, int) (DateTimeFormat.cpp:31)
==32223== by 0x688FB4D: _GLOBAL__sub_I_DateTimeFormat.cpp (DateTimeFormat.cpp:63)
==32223== by 0x40104E9: call_init.part.0 (dl-init.c:72)
==32223== by 0x40105FA: call_init (dl-init.c:30)
==32223== by 0x40105FA: _dl_init (dl-init.c:120)
==32223== by 0x4000CF9: ??? (in /lib/x86_64-linux-gnu/ld-2.23.so)
==32223==
==32223== 20 bytes in 1 blocks are definitely lost in loss record 2 of 13
==32223== at 0x4C2E0EF: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==32223== by 0x558EAEC: void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char const*>(char const*, char const*, std::forward_iterator_tag) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==32223== by 0x558EC4B: std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==32223== by 0x688F165: __static_initialization_and_destruction_0(int, int) (DateTimeFormat.cpp:23)
==32223== by 0x688FB4D: _GLOBAL__sub_I_DateTimeFormat.cpp (DateTimeFormat.cpp:63)
==32223== by 0x40104E9: call_init.part.0 (dl-init.c:72)
==32223== by 0x40105FA: call_init (dl-init.c:30)
==32223== by 0x40105FA: _dl_init (dl-init.c:120)
==32223== by 0x4000CF9: ??? (in /lib/x86_64-linux-gnu/ld-2.23.so)
==32223==
==32223== 20 bytes in 1 blocks are definitely lost in loss record 3 of 13
==32223== at 0x4C2E0EF: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==32223== by 0x558EAEC: void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char const*>(char const*, char const*, std::forward_iterator_tag) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==32223== by 0x558EC4B: std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==32223== by 0x688F1BA: __static_initialization_and_destruction_0(int, int) (DateTimeFormat.cpp:24)
==32223== by 0x688FB4D: _GLOBAL__sub_I_DateTimeFormat.cpp (DateTimeFormat.cpp:63)
==32223== by 0x40104E9: call_init.part.0 (dl-init.c:72)
==32223== by 0x40105FA: call_init (dl-init.c:30)
==32223== by 0x40105FA: _dl_init (dl-init.c:120)
==32223== by 0x4000CF9: ??? (in /lib/x86_64-linux-gnu/ld-2.23.so)
==32223==
==32223== 20 bytes in 1 blocks are definitely lost in loss record 4 of 13
==32223== at 0x4C2E0EF: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==32223== by 0x558EAEC: void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char const*>(char const*, char const*, std::forward_iterator_tag) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==32223== by 0x558EC4B: std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==32223== by 0x6942982: __static_initialization_and_destruction_0(int, int) (URI.cpp:32)
==32223== by 0x6942A63: _GLOBAL__sub_I_URI.cpp (URI.cpp:915)
==32223== by 0x40104E9: call_init.part.0 (dl-init.c:72)
==32223== by 0x40105FA: call_init (dl-init.c:30)
==32223== by 0x40105FA: _dl_init (dl-init.c:120)
==32223== by 0x4000CF9: ??? (in /lib/x86_64-linux-gnu/ld-2.23.so)
==32223==
==32223== 21 bytes in 1 blocks are definitely lost in loss record 5 of 13
==32223== at 0x4C2E0EF: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==32223== by 0x558EAEC: void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char const*>(char const*, char const*, std::forward_iterator_tag) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==32223== by 0x558EC4B: std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==32223== by 0x688F3B8: __static_initialization_and_destruction_0(int, int) (DateTimeFormat.cpp:30)
==32223== by 0x688FB4D: _GLOBAL__sub_I_DateTimeFormat.cpp (DateTimeFormat.cpp:63)
==32223== by 0x40104E9: call_init.part.0 (dl-init.c:72)
==32223== by 0x40105FA: call_init (dl-init.c:30)
==32223== by 0x40105FA: _dl_init (dl-init.c:120)
==32223== by 0x4000CF9: ??? (in /lib/x86_64-linux-gnu/ld-2.23.so)
==32223==
==32223== 25 bytes in 1 blocks are definitely lost in loss record 6 of 13
==32223== at 0x4C2E0EF: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==32223== by 0x558EAEC: void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char const*>(char const*, char const*, std::forward_iterator_tag) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==32223== by 0x558EC4B: std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==32223== by 0x688F20F: __static_initialization_and_destruction_0(int, int) (DateTimeFormat.cpp:25)
==32223== by 0x688FB4D: _GLOBAL__sub_I_DateTimeFormat.cpp (DateTimeFormat.cpp:63)
==32223== by 0x40104E9: call_init.part.0 (dl-init.c:72)
==32223== by 0x40105FA: call_init (dl-init.c:30)
==32223== by 0x40105FA: _dl_init (dl-init.c:120)
==32223== by 0x4000CF9: ??? (in /lib/x86_64-linux-gnu/ld-2.23.so)
==32223==
==32223== 25 bytes in 1 blocks are definitely lost in loss record 7 of 13
==32223== at 0x4C2E0EF: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==32223== by 0x558EAEC: void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char const*>(char const*, char const*, std::forward_iterator_tag) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==32223== by 0x558EC4B: std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==32223== by 0x688F264: __static_initialization_and_destruction_0(int, int) (DateTimeFormat.cpp:26)
==32223== by 0x688FB4D: _GLOBAL__sub_I_DateTimeFormat.cpp (DateTimeFormat.cpp:63)
==32223== by 0x40104E9: call_init.part.0 (dl-init.c:72)
==32223== by 0x40105FA: call_init (dl-init.c:30)
==32223== by 0x40105FA: _dl_init (dl-init.c:120)
==32223== by 0x4000CF9: ??? (in /lib/x86_64-linux-gnu/ld-2.23.so)
==32223==
==32223== 25 bytes in 1 blocks are definitely lost in loss record 8 of 13
==32223== at 0x4C2E0EF: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==32223== by 0x558EAEC: void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char const*>(char const*, char const*, std::forward_iterator_tag) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==32223== by 0x558EC4B: std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==32223== by 0x688F2B9: __static_initialization_and_destruction_0(int, int) (DateTimeFormat.cpp:27)
==32223== by 0x688FB4D: _GLOBAL__sub_I_DateTimeFormat.cpp (DateTimeFormat.cpp:63)
==32223== by 0x40104E9: call_init.part.0 (dl-init.c:72)
==32223== by 0x40105FA: call_init (dl-init.c:30)
==32223== by 0x40105FA: _dl_init (dl-init.c:120)
==32223== by 0x4000CF9: ??? (in /lib/x86_64-linux-gnu/ld-2.23.so)
==32223==
==32223== 25 bytes in 1 blocks are definitely lost in loss record 9 of 13
==32223== at 0x4C2E0EF: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==32223== by 0x558EAEC: void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char const*>(char const*, char const*, std::forward_iterator_tag) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==32223== by 0x558EC4B: std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==32223== by 0x688F30E: __static_initialization_and_destruction_0(int, int) (DateTimeFormat.cpp:28)
==32223== by 0x688FB4D: _GLOBAL__sub_I_DateTimeFormat.cpp (DateTimeFormat.cpp:63)
==32223== by 0x40104E9: call_init.part.0 (dl-init.c:72)
==32223== by 0x40105FA: call_init (dl-init.c:30)
==32223== by 0x40105FA: _dl_init (dl-init.c:120)
==32223== by 0x4000CF9: ??? (in /lib/x86_64-linux-gnu/ld-2.23.so)
==32223==
==32223== 25 bytes in 1 blocks are definitely lost in loss record 10 of 13
==32223== at 0x4C2E0EF: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==32223== by 0x558EAEC: void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char const*>(char const*, char const*, std::forward_iterator_tag) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==32223== by 0x558EC4B: std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==32223== by 0x688F363: __static_initialization_and_destruction_0(int, int) (DateTimeFormat.cpp:29)
==32223== by 0x688FB4D: _GLOBAL__sub_I_DateTimeFormat.cpp (DateTimeFormat.cpp:63)
==32223== by 0x40104E9: call_init.part.0 (dl-init.c:72)
==32223== by 0x40105FA: call_init (dl-init.c:30)
==32223== by 0x40105FA: _dl_init (dl-init.c:120)
==32223== by 0x4000CF9: ??? (in /lib/x86_64-linux-gnu/ld-2.23.so)
==32223==
==32223== 28 bytes in 1 blocks are definitely lost in loss record 11 of 13
==32223== at 0x4C2E0EF: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==32223== by 0x558EAEC: void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char const*>(char const*, char const*, std::forward_iterator_tag) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==32223== by 0x558EC4B: std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==32223== by 0x6918141: __static_initialization_and_destruction_0(int, int) (RotateStrategy.cpp:47)
==32223== by 0x69181B7: _GLOBAL__sub_I_RotateStrategy.cpp (RotateStrategy.cpp:115)
==32223== by 0x40104E9: call_init.part.0 (dl-init.c:72)
==32223== by 0x40105FA: call_init (dl-init.c:30)
==32223== by 0x40105FA: _dl_init (dl-init.c:120)
==32223== by 0x4000CF9: ??? (in /lib/x86_64-linux-gnu/ld-2.23.so)
==32223==
==32223== 168 bytes in 1 blocks are definitely lost in loss record 12 of 13
==32223== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==32223== by 0x7038D9D: CRYPTO_zalloc (in /usr/local/lib/libcrypto.so.1.1)
==32223== by 0x5253907: Poco::Crypto::(anonymous namespace)::CryptoTransformImpl::CryptoTransformImpl(evp_cipher_st const*, std::vector<unsigned char, std::allocator<unsigned char> > const&, std::vector<unsigned char, std::allocator<unsigned char> > const&, Poco::Crypto::(anonymous namespace)::CryptoTransformImpl::Direction) (CipherImpl.cpp:100)
==32223== by 0x5253E6F: Poco::Crypto::CipherImpl::createEncryptor() (CipherImpl.cpp:218)
==32223== by 0x5252ACA: Poco::Crypto::Cipher::encrypt(std::istream&, std::ostream&, Poco::Crypto::Cipher::Encoding) (Cipher.cpp:67)
==32223== by 0x52528BB: Poco::Crypto::Cipher::encryptString(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, Poco::Crypto::Cipher::Encoding) (Cipher.cpp:49)
==32223== by 0x4010FA: main (main.cpp:37)
==32223==
==32223== LEAK SUMMARY:
==32223== definitely lost: 420 bytes in 12 blocks
==32223== indirectly lost: 0 bytes in 0 blocks
==32223== possibly lost: 0 bytes in 0 blocks
==32223== still reachable: 72,704 bytes in 1 blocks
==32223== suppressed: 0 bytes in 0 blocks
==32223== Reachable blocks (those to which a pointer was found) are not shown.
==32223== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==32223==
==32223== For counts of detected and suppressed errors, rerun with: -v
==32223== ERROR SUMMARY: 23 errors from 13 contexts (suppressed: 0 from 0)
Following the last statements from the bottom, I went in the Cipher.cpp and CipherImp.cpp at the line #100 I found out:
#if OPENSSL_VERSION_NUMBER >= 0x10100000L
_pContext = EVP_CIPHER_CTX_new();
It seems is not deleted...I have no idea. But I'm sure that I'm making some mistakes.
Did anybody meet this error?
Where I wrong in the code?
Thank you
Cristano
I found out the answer.
It seems that with OpenSSL 1.1.0 the method to free resources is EVP_CIPHER_CTX_free(ctx).
I have included the CipherImpl in my project and changed the line below in the distructor:
CryptoTransformImpl::~CryptoTransformImpl()
{
#if OPENSSL_VERSION_NUMBER >= 0x10100000L
//IT WAS: EVP_CIPHER_CTX_cleanup(_pContext);
EVP_CIPHER_CTX_free(_pContext);
#else
EVP_CIPHER_CTX_cleanup(&_context);
#endif
}
I ran again Valgrind:
valgrind --leak-check=full ./CipherTest
==32869== Memcheck, a memory error detector
==32869== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==32869== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==32869== Command: ./CipherTest
==32869==
Sono nel costruttore con Openssl v.269484127
==32869==
==32869== HEAP SUMMARY:
==32869== in use at exit: 72,704 bytes in 1 blocks
==32869== total heap usage: 3,893 allocs, 3,892 frees, 253,681 bytes allocated
==32869==
==32869== LEAK SUMMARY:
==32869== definitely lost: 0 bytes in 0 blocks
==32869== indirectly lost: 0 bytes in 0 blocks
==32869== possibly lost: 0 bytes in 0 blocks
==32869== still reachable: 72,704 bytes in 1 blocks
==32869== suppressed: 0 bytes in 0 blocks
==32869== Reachable blocks (those to which a pointer was found) are not shown.
==32869== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==32869==
==32869== For counts of detected and suppressed errors, rerun with: -v
==32869== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
I am trying to troubleshoot a problem in my kernel:
khungtask panic was thrown due to a stuck process. The process which triggered the panic has four threads. Two threads stuck trying to a acquire the mmap_sem semaphore. And the other two were waiting on a user-space mutex.
Here is the stack trace for the first one:
crash> set 14789
PID: 14789
COMMAND: "dumper:du"
TASK: ffff8801a434c140 [THREAD_INFO: ffff8801ecd7c000]
CPU: 0
STATE: TASK_UNINTERRUPTIBLE
crash> bt
PID: 14789 TASK: ffff8801a434c140 CPU: 0 COMMAND: "dumper:du"
#0 [ffff8801ecd7dda8] __schedule at ffffffff8143fa09
#1 [ffff8801ecd7de50] schedule at ffffffff8143fb95
#2 [ffff8801ecd7de60] rwsem_down_failed_common at ffffffff81440fdf
#3 [ffff8801ecd7dec0] rwsem_down_write_failed at ffffffff81441024
#4 [ffff8801ecd7ded0] call_rwsem_down_write_failed at ffffffff812167c3
#5 [ffff8801ecd7df20] sys_mprotect at ffffffff810f968e
#6 [ffff8801ecd7df80] system_call_fastpath at ffffffff81447f42
RIP: 00000031dfce5377 RSP: 00007fff3c2b6408 RFLAGS: 00013202
RAX: 000000000000000a RBX: ffffffff81447f42 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000001000 RDI: 00007f95310a1000
RBP: 00000031e061c360 R8: 0000000000000019 R9: 0000000000000008
R10: 00000031dfa20000 R11: 0000000000003246 R12: 0000000000000003
R13: 0000000000000000 R14: 00007f95318a19c0 R15: 0000000000800000
ORIG_RAX: 000000000000000a CS: 0033 SS: 002b
And here is the stack trace from the second one:
crash> set 14791
PID: 14791
COMMAND: "dumper:du"
TASK: ffff8801eda161c0 [THREAD_INFO: ffff8801f0fa2000]
CPU: 1
STATE: TASK_RUNNING
crash> bt
PID: 14791 TASK: ffff8801eda161c0 CPU: 1 COMMAND: "dumper:du"
#0 [ffff8801f0fa3d88] __schedule at ffffffff8143fa09
#1 [ffff8801f0fa3e30] schedule at ffffffff8143fb95
#2 [ffff8801f0fa3e40] rwsem_down_failed_common at ffffffff81440fdf
#3 [ffff8801f0fa3ea0] rwsem_down_write_failed at ffffffff81441024
#4 [ffff8801f0fa3eb0] call_rwsem_down_write_failed at ffffffff812167c3
#5 [ffff8801f0fa3f00] sys_mmap_pgoff at ffffffff810f8de4
#6 [ffff8801f0fa3f70] sys_mmap at ffffffff8101280e
#7 [ffff8801f0fa3f80] system_call_fastpath at ffffffff81447f42
RIP: 00000031dfce531a RSP: 00007f95330a30c8 RFLAGS: 00013246
RAX: 0000000000000009 RBX: ffffffff81447f42 RCX: 0000000000000000
RDX: 0000000000000003 RSI: 0000000000001000 RDI: 0000000000000000
RBP: 0000000000001000 R8: 00000000ffffffff R9: 0000000000000000
R10: 0000000000000022 R11: 0000000000003246 R12: ffffffff8101280e
R13: ffff8801f0fa3f78 R14: 0000000000000003 R15: 0000000000040000
ORIG_RAX: 0000000000000009 CS: 0033 SS: 002b
I see that the first one was TASK_UNINTERRUPTIBLE, and the second one was TASK_RUNNING. Why would that be?
Obviously, the first one which was TASK_UNINTERRUPTIBLE is the one that triggered the panic. But, why would both fail to acquire the semaphore?
I do not understand this.