2016-08-04 4 views
1

Solaris/Linux 플랫폼 모두에 코어가 있는데 문제가 발생하지 않습니다. 나는 또 다른 핵심이C++ 힙 손상 및 valgrind

(gdb) where 
#0 0x001aa81b in do_lookup_x() from /lib/ld-linux.so.2 
#1 0x001ab0da in _dl_lookup_symbol_x() from /lib/ld-linux.so.2 
#2 0x001afa05 in _dl_fixup() from /lib/ld-linux.so.2 
#3 0x001b5c90 in _dl_runtime_resolve() from /lib/ld-linux.so.2 
#4 0x00275e4c in __gxx_personality_v0() from /opt/gnatpro/lib/libstdc++.so.6 
#5 0x00645cfe in _Unwind_RaiseException_Phase2 (exc=0x2a7b10, context=0xffd58434) at ../../../src/libgcc/../gcc/unwind.inc:67 
#6 0x00646082 in _Unwind_RaiseException (exc=0x2a7b10) at ../../../src/libgcc/../gcc/unwind.inc:136 
#7 0x0027628d in __cxa_throw() from /opt/gnatpro/lib/libstdc++.so.6 
#8 0x00276e4f in operator new(unsigned int)() from /opt/gnatpro/lib/libstdc++.so.6 
#9 0x08053737 in Receptor::receive (this=0x93c12d8, msj=...) at Receptor.cc:477 
#10 0x08099666 in EventProcessor::run (this=0xffd75580) at EventProcessor.cc:437 
#11 0x0809747d in SEventProcessor::run (this=0xffd75580) at SEventProcessor.cc:80 
#12 0x08065564 in main (argc=1, argv=0xffd76734) at my_project.cc:20 

솔라리스 플랫폼에서 : 리눅스 플랫폼에서 , 나는 다음과 같은 코어가

$ pstack core.ultimo 
core 'core.ultimo' of 9220:  my_project_sun 
----------------- lwp# 1/thread# 1 -------------------- 
0006fa28 __1cDstdGvector4CpnMDistribuidor_n0AJallocator4C2___Dend6kM_pk2_ (1010144, 1ce84, ffbd0df8, ffb7a18c, fffffff8, ffbedc7c) + 30 
0005d580 __1cDstdGvector4CpnMDistribuidor_n0AJallocator4C2___Esize6kM_I_ (1010144, 219, 1ce84, ffffffff, fffffff8, ffbedc7c) + 30 
0005ab14 __1cTReceptorHreceive6MrnKMensaje__v_ (33e630, ffbede70, ffffffff, 33e634, 33e68c, 0) + 1d4 
0015df78 __1cREventProcessorDrun6M_v_ (ffbede18, 33e630, dcc, 1, 33e730, 6e) + 350 
00159a50 __1cWSEventProcessorDrun6M_v_ (da08000, 2302f7, 111de0c, 159980, ff1fa07c, cc) + 48 
000b6acc main  (1, ffbeef74, ffbeef7c, 250000, 0, 0) + 16c 
00045e10 _start (0, 0, 0, 0, 0, 0) + 108 
----------------- lwp# 2/thread# 2 -------------------- 

...

코드의 조각 것은 :

이 코어는 무작위로 발생하며 프로세스가 수 주 동안 실행되는 경우가 있습니다. 코어의 크기는 또한, 경우 B.

내가 힙이 손상되었습니다하지만 지금 나는 "잘못된 읽기"등의 문제가 발생하지 않은 경우 볼 수 Valgrind의를 실행하고, "잘못된 쓰기"... 4291407872입니다 나는 실행중인 Valgrind의 나는 두 번 다음과 같은 메시지가 발견 : 나는 코드의 라인을 감지했지만 이러한 오류가 핵심으로 이어질 수

==19002== Syscall param semctl(arg) points to uninitialised byte(s) 

와? 나는 이전에 valgrind에서 이러한 오류를 보았으며 중요하지 않으며 "잘못된 읽기/쓰기"라고 말한 것은 아니라고 생각합니다.

이 문제를 해결하는 방법을 알고 계시다면 크게 감사하겠습니다.

+0

프로세스가 32 비트이고 코어가 약 4GB 인 것처럼 보입니다. 'std :: bad_alloc'을 잡아라. – rustyx

답변

3

핵심 크기는 단서입니다. 가장 큰 32 비트 부호없는 번호는 4,294,967,295입니다. 핵심은 프로세스가 메모리 부족이라는 것을 나타내는 것과 매우 비슷합니다. 가장 큰 원인은 메모리 누수입니다.

내 최근 기사 Memory Leaks in C/C++

Valgrind의 리눅스에 당신을 위해 문제를 찾을 수 있습니다 참조하십시오. 이를 위해서는 --leak-check 옵션으로 시작해야합니다. 프로세스가 정상적으로 종료 될 때 누수 여부를 확인하므로 프로세스를 종료하는 방법이 필요합니다.

Solaris에서 dbx로 Dtrace를 사용할 수도 있습니다. 내가 Valgrind의 실행 때

또한
1

, 나는 두 번 다음 메시지를 발견 :

==19002== Syscall param semctl(arg) points to uninitialised byte(s) 

을 나는 코드의 라인을 감지했지만 이러한 오류가 핵심으로 이어질 수 있을까?

예, 결과는 정의되지 않은 동작 일 가능성이 있으므로 SIGSEGV이 될 수 있습니다. (나는 실제 코드를 보지 않고서는 정의되지 않은 행동을하지 않을 것이라고 말하고 싶지 않지만 그렇다고 할 수있다.) 가능성이 높다면 그 코드가 SIGSEGV이 될 수있다. 그러나 다시 보았을 때 간헐적으로 실패한 것은 아니다. 그 모든 것을 자주합니다. 따라서 문제를 해결해야합니다.

valgrind 외에도 Solaris의 경우 libumemwatchmalloc을 사용하여 힙 메모리 관리 문제를 확인할 수 있습니다. 시작하려면 umem_debugwatchmalloc의 설명서 페이지를 참조하십시오.

Solaris에서 dbx을 사용하려면 Solaris Studio가 설치되어 있어야합니다 (무료). Solaris Studio는 dbx 디버거를 직접 호출하지 않고도 런타임 메모리 검사를 dbx으로 사용할 수있는 방법을 제공합니다. bcheck에 대한 매뉴얼 페이지를 참조하십시오. bcheck 매뉴얼 페이지는 Solaris Studio 설치 디렉토리 트리 man 디렉토리에 있습니다.

그리고 메모리 누수가 발생하면 시간 경과에 따라 프로세스 주소 공간이 커질 수 있습니다.