I am trying to set up Valgrind to detect possible leaks from the native part of an app.
I have managed to build and get it running on my device, but I seem to be getting an error, causing many leaks to be detected whatever I use it on.
Here is the output of me using valgrind on 'ls' (that should come up with 0 leaks):
130|root#hwALE-H:/data/local/Inst/bin # ./valgrind ls
==16610== Memcheck, a memory error detector
==16610== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==16610== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==16610== Command: ls
==16610==
WARNING: linker: /data/local/Inst/lib/valgrind/vgpreload_core-arm64-linux.so: unsupported flags DT_FLAGS_1=0x421
WARNING: linker: /data/local/Inst/lib/valgrind/vgpreload_memcheck-arm64-linux.so: unsupported flags DT_FLAGS_1=0x421
==16610== Invalid free() / delete / delete[] / realloc()
==16610== at 0x487D7D4: free (vg_replace_malloc.c:530)
==16610== by 0x40084FB: __dl__ZL12load_libraryilR10LinkedListI8LoadTask18TypeBasedAllocatorI15LinkedListEntryIS0_EEEPKciPK17android_dlextinfo (in /system/bin/linker64)
==16610== by 0x40097AF: __dl__ZL14find_librariesP6soinfoPKPKcmPS0_PNSt3__16vectorIS0_NS6_9allocatorIS0_EEEEmiPK17android_dlextinfo (in /system/bin/linker64)
==16610== by 0x400A883: __dl___linker_init (in /system/bin/linker64)
==16610== by 0x40029EB: _start (in /system/bin/linker64)
==16610== by 0x40029EB: _start (in /system/bin/linker64)
==16610== by 0x40029EB: _start (in /system/bin/linker64)
==16610== by 0x40029EB: _start (in /system/bin/linker64)
==16610== by 0x40029EB: _start (in /system/bin/linker64)
==16610== by 0x40029EB: _start (in /system/bin/linker64)
==16610== by 0x40029EB: _start (in /system/bin/linker64)
==16610== by 0x40029EB: _start (in /system/bin/linker64)
==16610== Address 0x4039150 is in a rw- anonymous segment
==16610==
==16610== Invalid free() / delete / delete[] / realloc()
==16610== at 0x487D7D4: free (vg_replace_malloc.c:530)
==16610== by 0x4009A43: __dl__ZL14find_librariesP6soinfoPKPKcmPS0_PNSt3__16vectorIS0_NS6_9allocatorIS0_EEEEmiPK17android_dlextinfo (in /system/bin/linker64)
==16610== by 0x400A883: __dl___linker_init (in /system/bin/linker64)
==16610== by 0x40029EB: _start (in /system/bin/linker64)
==16610== by 0x40029EB: _start (in /system/bin/linker64)
==16610== by 0x40029EB: _start (in /system/bin/linker64)
==16610== by 0x40029EB: _start (in /system/bin/linker64)
==16610== by 0x40029EB: _start (in /system/bin/linker64)
==16610== by 0x40029EB: _start (in /system/bin/linker64)
==16610== by 0x40029EB: _start (in /system/bin/linker64)
==16610== by 0x40029EB: _start (in /system/bin/linker64)
==16610== by 0x40029EB: _start (in /system/bin/linker64)
==16610== Address 0x403e010 is in a rw- anonymous segment
==16610==
callgrind_annotate
callgrind_control
cg_annotate
cg_diff
cg_merge
ms_print
valgrind
valgrind-di-server
valgrind-listener
vgdb
==16610==
==16610== HEAP SUMMARY:
==16610== in use at exit: 680 bytes in 12 blocks
==16610== total heap usage: 58 allocs, 48 frees, 72,870 bytes allocated
==16610==
==16610== LEAK SUMMARY:
==16610== definitely lost: 352 bytes in 7 blocks
==16610== indirectly lost: 0 bytes in 0 blocks
==16610== possibly lost: 16 bytes in 1 blocks
==16610== still reachable: 312 bytes in 4 blocks
==16610== suppressed: 0 bytes in 0 blocks
==16610== Rerun with --leak-check=full to see details of leaked memory
==16610==
==16610== For counts of detected and suppressed errors, rerun with: -v
==16610== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)
Any suggestions to help solve this issue will greatly appreciated!
EDIT: Here is the full logcat output from starting a "HelloJNI" type app, with a 6byte leak from native code. https://pastebin.com/j7TWC5Bu
The trace is hardly usable.
Related
I'm experimenting with assembly language and wrote a program which prints 2 hardcoded bytes into stdout. Here it is:
section .text
global _start
_start:
mov eax, 0x0A31
mov [val], eax
mov eax, 4
mov ebx, 1
mov ecx, val
mov edx, 2
int 0x80
mov eax, 1
int 0x80
segment .bss
val resb 1; <------ Here
Note that I reserved only 1 byte inside the bss segment, but actually put 2 bytes (charcode for 1 and newline symbol) into the memory location. And the program worked fine. It printed 1 character and then newline.
But I expected segmentation fault. Why isn't it occured. We reserved only 1 byte, but put 2.
x86, like most other modern architectures, uses paging / virtual memory for memory protection. On x86 (again like many other architectures), the granularity is 4kiB.
A 4-byte store to val won't fault unless the linker happens to place it in the last 3 bytes of a page, and the next page is unmapped.
What actually happens is that you just overwrite whatever is after val. In this case, it's just unused space to the end of the page. If you had other static storage locations in the BSS, you'd step on their values. (Call them "variables" if you want, but the high-level concept of a "variable" doesn't just mean a memory location, a variable can be live in a register and never needs to have an address.)
Besides the wikipedia article linked above, see also:
How does x86 paging work? (internals of the page-table format, and how the OS manages it and the CPU reads it).
What is the state of the art in Memory Protection?
Is it safe to read past the end of a buffer within the same page on x86 and x64?
About the memory layout of programs in Linux
but actually put 2 bytes (charcode for 1 and newline symbol) into the memory location.
mov [val], eax is a 4-byte store. The operand-size is determined by the register. If you wanted to do a 2-byte store, use mov [val], ax.
Fun fact: MASM would warn or error about an operand-size mismatch, because it magically associates sizes with symbol names based on the declaration that reserves space after them. NASM stays out of your way, so if you wrote mov [val], 0x0A31, it would be an error. Neither operand implies a size, so you need mov dword [val], 0x0A31 (or word or byte).
Placing val at the end of a page to get a segfault
The BSS for some reason doesn't start at the beginning of a page in a 32-bit binary, but it is near the start of a page. You're not linking with anything else that would use up most of a page in the BSS. nm bss-no-segfault shows that it's at 0x080490a8, and a 4k page is 0x1000 bytes, so the last byte in the BSS mapping will be 0x08049fff.
It seems that the BSS start address changes when I add an instruction to the .text section, so presumably the linker's choices here are related to packing things into an ELF executable. It doesn't make much sense, because the BSS isn't stored in the file, it's just a base address + length. I'm not going down that rabbit hole; I'm sure there's a reason that making .text slightly larger results in a BSS that starts at the beginning of a page, but IDK what it is.
Anyway, if we construct the BSS so that val is right before the end of a page, we can get a fault:
... same .text
section .bss
dummy: resb 4096 - 0xa8 - 2
val: resb 1
;; could have done this instead of making up constants
;; ALIGN 4096
;; dummy2: resb 4094
;; val2: resb
Then build and run:
$ asm-link -m32 bss-no-segfault.asm
+ yasm -felf32 -Worphan-labels -gdwarf2 bss-no-segfault.asm
+ ld -melf_i386 -o bss-no-segfault bss-no-segfault.o
peter#volta:~/src/SO$ nm bss-no-segfault
080490a7 B __bss_start
080490a8 b dummy
080490a7 B _edata
0804a000 B _end <--------- End of the BSS
08048080 T _start
08049ffe b val <--------- Address of val
gdb ./bss-no-segfault
(gdb) b _start
(gdb) r
(gdb) set disassembly-flavor intel
(gdb) layout reg
(gdb) p &val
$2 = (<data variable, no debug info> *) 0x8049ffe
(gdb) si # and press return to repeat a couple times
mov [var], eax segfaults because it crosses into the unmapped page. mov [var], ax would works (because I put var 2 bytes before the end of the page).
At this point, /proc/<PID>/smaps shows:
... the r-x private mapping for .text
08049000-0804a000 rwxp 00000000 00:15 2885598 /home/peter/src/SO/bss-no-segfault
Size: 4 kB
Rss: 4 kB
Pss: 4 kB
Shared_Clean: 0 kB
Shared_Dirty: 0 kB
Private_Clean: 0 kB
Private_Dirty: 4 kB
Referenced: 4 kB
Anonymous: 4 kB
...
[vvar] and [vdso] pages exported by the kernel for fast gettimeofday / getpid
Key things: rwxp means read/write/execute, and private. Even stopped before the first instruction, somehow it's already "dirty" (i.e. written to). So is the text segment, but that's expected from gdb changing the instruction to int3.
The 08049000-0804a000 (and 4 kB size of the mapping) shows us that the BSS only has 1 page mapped. There's no data segment, just text and BSS.
I'm experimenting with assembly language and wrote a program which prints 2 hardcoded bytes into stdout. Here it is:
section .text
global _start
_start:
mov eax, 0x0A31
mov [val], eax
mov eax, 4
mov ebx, 1
mov ecx, val
mov edx, 2
int 0x80
mov eax, 1
int 0x80
segment .bss
val resb 1; <------ Here
Note that I reserved only 1 byte inside the bss segment, but actually put 2 bytes (charcode for 1 and newline symbol) into the memory location. And the program worked fine. It printed 1 character and then newline.
But I expected segmentation fault. Why isn't it occured. We reserved only 1 byte, but put 2.
x86, like most other modern architectures, uses paging / virtual memory for memory protection. On x86 (again like many other architectures), the granularity is 4kiB.
A 4-byte store to val won't fault unless the linker happens to place it in the last 3 bytes of a page, and the next page is unmapped.
What actually happens is that you just overwrite whatever is after val. In this case, it's just unused space to the end of the page. If you had other static storage locations in the BSS, you'd step on their values. (Call them "variables" if you want, but the high-level concept of a "variable" doesn't just mean a memory location, a variable can be live in a register and never needs to have an address.)
Besides the wikipedia article linked above, see also:
How does x86 paging work? (internals of the page-table format, and how the OS manages it and the CPU reads it).
What is the state of the art in Memory Protection?
Is it safe to read past the end of a buffer within the same page on x86 and x64?
About the memory layout of programs in Linux
but actually put 2 bytes (charcode for 1 and newline symbol) into the memory location.
mov [val], eax is a 4-byte store. The operand-size is determined by the register. If you wanted to do a 2-byte store, use mov [val], ax.
Fun fact: MASM would warn or error about an operand-size mismatch, because it magically associates sizes with symbol names based on the declaration that reserves space after them. NASM stays out of your way, so if you wrote mov [val], 0x0A31, it would be an error. Neither operand implies a size, so you need mov dword [val], 0x0A31 (or word or byte).
Placing val at the end of a page to get a segfault
The BSS for some reason doesn't start at the beginning of a page in a 32-bit binary, but it is near the start of a page. You're not linking with anything else that would use up most of a page in the BSS. nm bss-no-segfault shows that it's at 0x080490a8, and a 4k page is 0x1000 bytes, so the last byte in the BSS mapping will be 0x08049fff.
It seems that the BSS start address changes when I add an instruction to the .text section, so presumably the linker's choices here are related to packing things into an ELF executable. It doesn't make much sense, because the BSS isn't stored in the file, it's just a base address + length. I'm not going down that rabbit hole; I'm sure there's a reason that making .text slightly larger results in a BSS that starts at the beginning of a page, but IDK what it is.
Anyway, if we construct the BSS so that val is right before the end of a page, we can get a fault:
... same .text
section .bss
dummy: resb 4096 - 0xa8 - 2
val: resb 1
;; could have done this instead of making up constants
;; ALIGN 4096
;; dummy2: resb 4094
;; val2: resb
Then build and run:
$ asm-link -m32 bss-no-segfault.asm
+ yasm -felf32 -Worphan-labels -gdwarf2 bss-no-segfault.asm
+ ld -melf_i386 -o bss-no-segfault bss-no-segfault.o
peter#volta:~/src/SO$ nm bss-no-segfault
080490a7 B __bss_start
080490a8 b dummy
080490a7 B _edata
0804a000 B _end <--------- End of the BSS
08048080 T _start
08049ffe b val <--------- Address of val
gdb ./bss-no-segfault
(gdb) b _start
(gdb) r
(gdb) set disassembly-flavor intel
(gdb) layout reg
(gdb) p &val
$2 = (<data variable, no debug info> *) 0x8049ffe
(gdb) si # and press return to repeat a couple times
mov [var], eax segfaults because it crosses into the unmapped page. mov [var], ax would works (because I put var 2 bytes before the end of the page).
At this point, /proc/<PID>/smaps shows:
... the r-x private mapping for .text
08049000-0804a000 rwxp 00000000 00:15 2885598 /home/peter/src/SO/bss-no-segfault
Size: 4 kB
Rss: 4 kB
Pss: 4 kB
Shared_Clean: 0 kB
Shared_Dirty: 0 kB
Private_Clean: 0 kB
Private_Dirty: 4 kB
Referenced: 4 kB
Anonymous: 4 kB
...
[vvar] and [vdso] pages exported by the kernel for fast gettimeofday / getpid
Key things: rwxp means read/write/execute, and private. Even stopped before the first instruction, somehow it's already "dirty" (i.e. written to). So is the text segment, but that's expected from gdb changing the instruction to int3.
The 08049000-0804a000 (and 4 kB size of the mapping) shows us that the BSS only has 1 page mapped. There's no data segment, just text and BSS.
Upon running valgrind node, Node seems to abort with a somewhat cryptic syscall-related error.
I'm on macOS Sierra, Node v8.2.1.
$ valgrind `which node` test-pass.js
==17115== Memcheck, a memory error detector
==17115== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==17115== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==17115== Command: /Users/junon/n/bin/node test-pass.js
==17115==
==17115== Syscall param msg->desc.port.name points to uninitialised byte(s)
==17115== at 0x10352B34A: mach_msg_trap (in /usr/lib/system/libsystem_kernel.dylib)
==17115== by 0x10352A796: mach_msg (in /usr/lib/system/libsystem_kernel.dylib)
==17115== by 0x103524485: task_set_special_port (in /usr/lib/system/libsystem_kernel.dylib)
==17115== by 0x1036C010E: _os_trace_create_debug_control_port (in /usr/lib/system/libsystem_trace.dylib)
==17115== by 0x1036C0458: _libtrace_init (in /usr/lib/system/libsystem_trace.dylib)
==17115== by 0x1029B29DF: libSystem_initializer (in /usr/lib/libSystem.B.dylib)
==17115== by 0x1021ECA1A: ImageLoaderMachO::doModInitFunctions(ImageLoader::LinkContext const&) (in /usr/lib/dyld)
==17115== by 0x1021ECC1D: ImageLoaderMachO::doInitialization(ImageLoader::LinkContext const&) (in /usr/lib/dyld)
==17115== by 0x1021E84A9: ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, char const*, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) (in /usr/lib/dyld)
==17115== by 0x1021E8440: ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, char const*, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) (in /usr/lib/dyld)
==17115== by 0x1021E7523: ImageLoader::processInitializers(ImageLoader::LinkContext const&, unsigned int, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) (in /usr/lib/dyld)
==17115== by 0x1021E75B8: ImageLoader::runInitializers(ImageLoader::LinkContext const&, ImageLoader::InitializerTimingList&) (in /usr/lib/dyld)
==17115== Address 0x7fff5fbfda8c is on thread 1's stack
==17115== in frame #2, created by task_set_special_port (???:)
==17115==
Assertion failed: (process_title.len + 1 == size), function uv_setup_args, file ../deps/uv/src/unix/proctitle.c, line 58.
==17115==
==17115== Process terminating with default action of signal 6 (SIGABRT)
==17115== at 0x103532D72: __pthread_sigmask (in /usr/lib/system/libsystem_kernel.dylib)
==17115== by 0x1034404A8: __abort (in /usr/lib/system/libsystem_c.dylib)
==17115== by 0x10344042E: abort (in /usr/lib/system/libsystem_c.dylib)
==17115== by 0x103407892: __assert_rtn (in /usr/lib/system/libsystem_c.dylib)
==17115== by 0x100BEC7B6: uv_setup_args (in /Users/junon/n/bin/node)
==17115== by 0x100A7EC9F: node::Start(int, char**) (in /Users/junon/n/bin/node)
==17115== by 0x100000E33: (below main) (in /Users/junon/n/bin/node)
==17115==
==17115== HEAP SUMMARY:
==17115== in use at exit: 71,518 bytes in 369 blocks
==17115== total heap usage: 469 allocs, 100 frees, 108,584 bytes allocated
==17115==
==17115== LEAK SUMMARY:
==17115== definitely lost: 0 bytes in 0 blocks
==17115== indirectly lost: 0 bytes in 0 blocks
==17115== possibly lost: 7,272 bytes in 115 blocks
==17115== still reachable: 10,270 bytes in 98 blocks
==17115== suppressed: 53,976 bytes in 156 blocks
==17115== Rerun with --leak-check=full to see details of leaked memory
==17115==
==17115== For counts of detected and suppressed errors, rerun with: -v
==17115== Use --track-origins=yes to see where uninitialised values come from
==17115== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 1 from 1)
[1] 17115 abort valgrind `which node` test-pass.js
How are you supposed to check for memory leaks within C++ add-ons for Node.js? I see mentions of using node_g from around 2010, but that executable appears to be missing from my installation.
I am new to Valgrind. It throws 2 errors during memory check for the following code (http://en.cppreference.com/w/cpp/thread/lock_guard). Not sure how to interpret those errors.
#include <thread>
#include <mutex>
#include <iostream>
int g_i = 0;
std::mutex g_i_mutex; // protects g_i
void safe_increment()
{
std::lock_guard<std::mutex> lock(g_i_mutex);
++g_i;
std::cout << std::this_thread::get_id() << ": " << g_i << '\n';
}
int main()
{
std::cout << __func__ << ": " << g_i << '\n';
std::thread t1(safe_increment);
std::thread t2(safe_increment);
t1.join();
t2.join();
std::cout << __func__ << ": " << g_i << '\n';
}
I compiled this code on Mac using the following command:
clang++ simplethread.cpp -o simplethread -lpthread -std=c++11
The code runs as expected, but I get the following output from Valgrind.
$ valgrind --tool=memcheck ./simplethread
==34831== Memcheck, a memory error detector
==34831== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==34831== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==34831== Command: ./simplethread
==34831==
==34831== Syscall param msg->desc.port.name points to uninitialised byte(s)
==34831== at 0x10045F34A: mach_msg_trap (in /usr/lib/system/libsystem_kernel.dylib)
==34831== by 0x10045E796: mach_msg (in /usr/lib/system/libsystem_kernel.dylib)
==34831== by 0x100458485: task_set_special_port (in /usr/lib/system/libsystem_kernel.dylib)
==34831== by 0x1005F410E: _os_trace_create_debug_control_port (in /usr/lib/system/libsystem_trace.dylib)
==34831== by 0x1005F4458: _libtrace_init (in /usr/lib/system/libsystem_trace.dylib)
==34831== by 0x1000A99DF: libSystem_initializer (in /usr/lib/libSystem.B.dylib)
==34831== by 0x10001BA1A: ImageLoaderMachO::doModInitFunctions(ImageLoader::LinkContext const&) (in /usr/lib/dyld)
==34831== by 0x10001BC1D: ImageLoaderMachO::doInitialization(ImageLoader::LinkContext const&) (in /usr/lib/dyld)
==34831== by 0x1000174A9: ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, char const*, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) (in /usr/lib/dyld)
==34831== by 0x100017440: ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, char const*, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) (in /usr/lib/dyld)
==34831== by 0x100016523: ImageLoader::processInitializers(ImageLoader::LinkContext const&, unsigned int, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) (in /usr/lib/dyld)
==34831== by 0x1000165B8: ImageLoader::runInitializers(ImageLoader::LinkContext const&, ImageLoader::InitializerTimingList&) (in /usr/lib/dyld)
==34831== Address 0x10488ed4c is on thread 1's stack
==34831== in frame #2, created by task_set_special_port (???:)
==34831==
main: 0
==34831== Thread 2:
==34831== Invalid read of size 4
==34831== at 0x1005BC899: _pthread_body (in /usr/lib/system/libsystem_pthread.dylib)
==34831== by 0x1005BC886: _pthread_start (in /usr/lib/system/libsystem_pthread.dylib)
==34831== by 0x1005BC08C: thread_start (in /usr/lib/system/libsystem_pthread.dylib)
==34831== Address 0x18 is not stack'd, malloc'd or (recently) free'd
==34831==
==34831==
==34831== Process terminating with default action of signal 11 (SIGSEGV)
==34831== Access not within mapped region at address 0x18
==34831== at 0x1005BC899: _pthread_body (in /usr/lib/system/libsystem_pthread.dylib)
==34831== by 0x1005BC886: _pthread_start (in /usr/lib/system/libsystem_pthread.dylib)
==34831== by 0x1005BC08C: thread_start (in /usr/lib/system/libsystem_pthread.dylib)
==34831== If you believe this happened as a result of a stack
==34831== overflow in your program's main thread (unlikely but
==34831== possible), you can try to increase the size of the
==34831== main thread stack using the --main-stacksize= flag.
==34831== The main thread stack size used in this run was 8388608.
--34831:0:schedule VG_(sema_down): read returned -4
==34831==
==34831== HEAP SUMMARY:
==34831== in use at exit: 22,494 bytes in 168 blocks
==34831== total heap usage: 184 allocs, 16 frees, 28,638 bytes allocated
==34831==
==34831== LEAK SUMMARY:
==34831== definitely lost: 16 bytes in 1 blocks
==34831== indirectly lost: 56 bytes in 2 blocks
==34831== possibly lost: 72 bytes in 3 blocks
==34831== still reachable: 4,368 bytes in 10 blocks
==34831== suppressed: 17,982 bytes in 152 blocks
==34831== Rerun with --leak-check=full to see details of leaked memory
==34831==
==34831== For counts of detected and suppressed errors, rerun with: -v
==34831== Use --track-origins=yes to see where uninitialised values come from
==34831== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 1 from 1)
Segmentation fault: 11
What does these errors mean ?
Please let me know if there is more information I need to enter. The stackexchange robot seems to think there is not enough of it here.
The below stack trace is generated as a result of a an invalid callback pointer. I'd like to understand where the callback occurred in the code. I know how to do this in MIPS, but not in Intel architecture.
I get the following backtrace on sigsegv:
(gdb) bt
#0 0x000000361f20cc5a in ?? ()
Cannot access memory at address 0x7f382f1e1810
(gdb)
When I try to disassemble I get:
(gdb) disassemble
No function contains program counter for selected frame.
(gdb) info reg
rax 0x7f2bf3fb8790 139826753669008
rbx 0x7f3200197520 139852726760736
rcx 0x7f3200197540 139852726760768
rdx 0x0 0
rsi 0x7f2bf3fb87b0 139826753669040
rdi 0x0 0
rbp 0x7f2bf3fb87b0 0x7f2bf3fb87b0
rsp 0x7f382f1e1810 0x7f382f1e1810
r8 0x20000 131072
r9 0x453d780 72603520
r10 0x27 39
r11 0x7f2dcbfa9ec8 139834672455368
r12 0x7f2bf3fb87b0 139826753669040
r13 0x7f3196fd2790 139850963298192
r14 0x7f2c080008c0 139827089508544
r15 0xfffffffffffffe68 -408
rip 0x361f20cc5a 0x361f20cc5a
eflags 0x10206 [ PF IF RF ]
cs 0x33 51
ss 0x2b 43
ds 0x0 0
es 0x0 0
fs 0x0 0
gs 0x0 0
Processor information:
Intel(R) Xeon(R) CPU E5-2658A v3 # 2.20GHz