2017-05-14 2 views
0

segfault의 출처를 식별하는 방법에 대한 조언이 필요합니다. 아산 컴파일원인 : AddressSanitizer : 알 수없는 주소 (null 포인터)의 SEGV

:

==21093==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7f09d744d882 bp 0x000000001000 sp 0x62100001c538 T0) 
ASAN:DEADLYSIGNAL 
AddressSanitizer: nested bug in the same thread, aborting. 

은 GDB 시작 :

Program received signal SIGSEGV, Segmentation fault.  
0x00007ffff5eeb882 in __memset_avx2_erms() from /usr/lib/libc.so.6 
(gdb) bt 
#0 0x00007ffff5eeb882 in __memset_avx2_erms() from /usr/lib/libc.so.6 
#1 0xbebebebebebebebe in ??() 
#2 0xbebebebebebebebe in ??() 
... 

1. 편집 :

32 위에서 64 비트 (x86_64의)에 대해 컴파일 된 출력, 따라 출력이 생성됩니다 :

==8361==ERROR: AddressSanitizer failed to allocate 0x200000 (2097152) bytes of SizeClassAllocator32 (error code: 12) 
==8361==Process memory map follows: 
    0x00200000-0x00300000 
    0x00400000-0x00500000 
... 
    0xf7791000-0xf7792000 /lib32/ld-2.24.so 
    0xf7800000-0xffd00000 
    0xffe34000-0xffe55000 [stack] 
==8361==End of process memory map. 
==8361==AddressSanitizer CHECK failed: ../../../../../src/libsanitizer/sanitizer_common/sanitizer_common.cc:180 "((0 && "unable to mmap")) != (0)" (0x0, 0x0) 
ERROR: Failed to mmap 
,

2. 편집 :

Program received signal SIGSEGV, Segmentation fault. 
0x00007ffff5eeb882 in __memset_avx2_erms() from /usr/lib/libc.so.6 
(gdb) bt 
#0 0x00007ffff5eeb882 in __memset_avx2_erms() from /usr/lib/libc.so.6 
#1 0xbebebebebebebebe in ??() 
#2 0xbebebebebebebebe in ??() 
#3 0xbebebebebebebebe in ??() 
#4 0xbebebebebebebebe in ??() 
... 
(gdb) record instruction-history 
17798  0x00007ffff5eeb8b6 <__memset_avx2_unaligned_erms+22>: cmp $0x40,%rdx 
17799  0x00007ffff5eeb8ba <__memset_avx2_unaligned_erms+26>: ja  0x7ffff5eeb8ca <__memset_avx2_unaligned_erms+42> 
17800  0x00007ffff5eeb8ca <__memset_avx2_unaligned_erms+42>: cmp $0x800,%rdx 
17801  0x00007ffff5eeb8d1 <__memset_avx2_unaligned_erms+49>: ja  0x7ffff5eeb870 <__memset_avx2_erms> 
17802  0x00007ffff5eeb870 <__memset_avx2_erms+0>: vzeroupper 
17803  0x00007ffff5eeb873 <__memset_avx2_erms+3>: mov %rdx,%rcx 
17804  0x00007ffff5eeb876 <__memset_avx2_erms+6>: movzbl %sil,%eax 
17805  0x00007ffff5eeb87a <__memset_avx2_erms+10>: mov %rdi,%rdx 
17806  0x00007ffff5eeb87d <__memset_avx2_erms+13>: rep stos %al,%es:(%rdi) 
17807  0x00007ffff5eeb87f <__memset_avx2_erms+15>: mov %rdx,%rax 

그/왜이 segfault의 원인이 무엇을 의미하는지 확실하지?

+1

실행 파일 – mch

+0

@mch에 디버그 정보를 추가하도록 컴파일러에 지시해야합니다. 디버그 기호 – xlrg

+0

으로 컴파일됩니다. @mch OPs 스택이 손상되었으므로 (반환 주소 참조) debuginfo가 여기에서 문제가되지 않습니다. – yugr

답변

1

segfault의 출처를 식별하는 방법에 대한 조언이 필요합니다.

int main() 
{ 
    char buf[1]; 
    memset(buf, 0xbe, 1<<20); 
} 

AddressSanitizer가 오버 플로우를 잡을하지 않았다 놀라운 일이다 :

GDB 스택 추적과 유사한 스택 오버 플로우의 전형이다.

here에 설명 된대로 GDB 분기 추적 지원으로 디버깅하려고합니다.

P. 최소한의 예를 만들 수 있다면 Address Sanitizer 개발자들이 이에 관심을 가질 것입니다.

+0

불행히도 앱은 어떤 종류의 스택 전환을 사용하는 더 큰 프레임 워크를 사용합니다. 따라서 최소한의 예는 불가능합니다. – xlrg

관련 문제