~ vector() вызывает SIGSEGV при выходе

Question

Thats the Store Проблема с кредитом на кодовом замке Google. https://code.google.com/codejam/contest/351101/dashboard#s=p0

Мой код выдает SIGSEGV после запуска большого теста. Но ответ правильный!

#include <cstdio> 
#include <algorithm> 
#include <vector> 
using namespace std; 
int ps[1000]={0}; 
vector<int> indice[1000]; 
int main() { 
    int cases; scanf("%d", &cases); 
    for(int j=1;j<=cases;j++) { 
    printf("Case #%d: ", j); 
    int c, is; scanf("%d%d", &c, &is); 
    for(int i=0;i<=c;i++) ps[i]=0; 
    for(int i=0;i<=c;i++) indice[i].clear(); 
    for (int i = 0; i < is; i++) { 
     int it; scanf("%d", &it); 
     indice[it].push_back(i+1); 
     ps[it]=1; 
     if (c-it>0&&ps[c-it]) { 
     int a, b; 
     a = indice[it][0]; 
     b = indice[c-it][0]; 
     if(c==2*it&&indice[it].size()>1) { 
      b=indice[it][1]; 
     } 

     if (a!=b) { 
      printf("%d %d\n", min(a,b),max(a,b)); 
     } 
     } 
    } 
    } 
    return 0; 
} 

Поэтому я использую valgrind, чтобы узнать, что происходит .. но кажется, что это не моя проблема.

==17599== Invalid free()/delete/delete[]/realloc() 
==17599== at 0x4C2A4BC: operator delete(void*) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) 
==17599== by 0x401669: __gnu_cxx::new_allocator<int>::deallocate(int*, unsigned long) (new_allocator.h:98) 
==17599== by 0x4013CD: std::_Vector_base<int, std::allocator<int> >::_M_deallocate(int*, unsigned long) (stl_vector.h:156) 
==17599== by 0x400F60: std::_Vector_base<int, std::allocator<int> >::~_Vector_base() (stl_vector.h:142) 
==17599== by 0x400D8D: std::vector<int, std::allocator<int> >::~vector() (stl_vector.h:351) 
==17599== by 0x400C48: __tcf_0 (a.cpp:6) 
==17599== by 0x5383900: __run_exit_handlers (exit.c:78) 
==17599== by 0x5383984: exit (exit.c:100) 
==17599== by 0x5369773: (below main) (libc-start.c:258) 
==17599== Address 0x1 is not stack'd, malloc'd or (recently) free'd 
==17599== 
==17599== 
==17599== HEAP SUMMARY: 
==17599==  in use at exit: 128 bytes in 1 blocks 
==17599== total heap usage: 4,527 allocs, 4,527 frees, 113,664 bytes allocated 
==17599== 
==17599== LEAK SUMMARY: 
==17599== definitely lost: 0 bytes in 0 blocks 
==17599== indirectly lost: 0 bytes in 0 blocks 
==17599==  possibly lost: 0 bytes in 0 blocks 
==17599== still reachable: 128 bytes in 1 blocks 
==17599==   suppressed: 0 bytes in 0 blocks 
==17599== Rerun with --leak-check=full to see details of leaked memory 
==17599== 
==17599== For counts of detected and suppressed errors, rerun with: -v 
==17599== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2) 

Я так смущен ... Может кто-нибудь сказать мне, что происходит? Я новичок в C++ .. Большое спасибо.

Answer 1

Как я понимаю valgrind, он не может обнаружить, что вы пишете вне границ массивов, которые статически распределены. Итак, давайте выделим их в кучу.

Затем вы увидите ошибки, исходящие от valgrind. В том числе:

==7168== Invalid read of size 8 
==7168== at 0x4008D6: main (stl_vector.h:735) 
==7168== Address 0x4c39e10 is 8 bytes after a block of size 24,008 alloc'd 
==7168== at 0x4A07152: operator new[](unsigned long) (vg_replace_malloc.c:363) 
==7168== by 0x400791: global constructors keyed to indice (foo.cc:6) 
==7168== by 0x400C35: ??? (in /tmp/foo) 
==7168== by 0x4005F2: ??? (in /tmp/foo) 
==7168== 
==7168== Invalid read of size 8 
==7168== at 0x4008DA: main (stl_vector.h:735) 
==7168== Address 0x4c39e18 is 16 bytes after a block of size 24,008 alloc'd 
==7168== at 0x4A07152: operator new[](unsigned long) (vg_replace_malloc.c:363) 
==7168== by 0x400791: global constructors keyed to indice (foo.cc:6) 
==7168== by 0x400C35: ??? (in /tmp/foo) 
==7168== by 0x4005F2: ??? (in /tmp/foo) 
==7168== 

И с помощью GDB, я могу видеть, что SIGSEGV происходит, когда вы получаете доступ indice[1433], который находится вне границ indice.

я также представить себе, что ваш фактический вопрос в том, что для большого набора данных, переменные границы перечислены как:

N = 50 
3 ≤ I ≤ 2000 

Вы уверены, что не следует выделять элементы 2001, а не 1000?