2017-05-14 6 views
0

J'ai besoin de quelques conseils pour identifier la source du segfault.cause de: AddressSanitizer: SEGV sur l'adresse inconnue (null pointeur)

compilé avec ASAN:

==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. 

a commencé avec 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. Edit:

la sortie ci-dessus a été compilé 64 bits (x86_64), sur 32 bits suivant la sortie est générée:

==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. EDIT:

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 

ne sais pas ce que cela signifie/pourquoi cela provoque une erreur de segmentation?

+1

Vous devez dire à votre compilateur d'ajouter des informations de débogage dans l'exécutable – mch

+0

@mch: il est compilé avec les symboles de débogage – xlrg

+0

@mch La pile OPs a été écrasée (voir les adresses de retour) donc debuginfo n'est pas le problème ici. – yugr

Répondre

1

J'ai besoin de quelques conseils pour identifier la source de la faute de seg- ment.

La trace de la pile GDB est typique de débordement de pile semblable à:

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

Il est surprenant que AddressSanitizer n'a pas pris ce débordement.

Je voudrais essayer de le déboguer avec le support de trace de branche GDB, comme décrit here.

P.S. Si vous pouvez construire un exemple minimal, les développeurs d'Address Sanitizer seront intéressés.

+0

Malheureusement, l'application utilise un cadre biger qui utilise une sorte de commutation de pile - donc un exemple minimal ne serait pas possible – xlrg