Stack problème de débordement dans un programme récursive en C

Question

Je reçois un débordement de pile dans l'une des fonctions récursives je cours ..

Voici le code ..

void* buddyMalloc(int req_size) 
{ 
    // Do something here 
    return buddy_findout(original_index,req_size); // This is the recursive call 
} 

void *buddy_findout(int current_index,int req_size) 
{ 
    char *selected = NULL; 

    if(front!=NULL) 
    { 
     if(current_index==original_index) 
     { 
      // Do something here 
      return selected; 
     } 
     else 
     { 
      // Do Something here 
      return buddy_findout(current_index+1,req_size); 
     } 
    } 
    else 
    { 
     return buddy_findout(current_index-1,req_size); 
    } 
} 

Tenir compte de la valeur initiale de l'indice à 4. et il fait d'abord index-1 jusqu'à ce qu'il atteigne 0 indice. et puis il revient à l'index 4 en incrémentant .. C'est ce que je veux mettre en œuvre. Mais il donne un débordement de pile sur la carte mémoire dans l'invite de commande:

est ici la sortie de ma coquille:

*** glibc detected *** ./473_mem: free(): invalid pointer: 0x00c274c0 *** 
======= Backtrace: ========= 
/lib/tls/i686/cmov/libc.so.6[0xb50ff1] 
/lib/tls/i686/cmov/libc.so.6[0xb526f2] 
/lib/tls/i686/cmov/libc.so.6(cfree+0x6d)[0xb557cd] 
./473_mem[0x8048b44] 
./473_mem[0x8048b74] 
./473_mem[0x8048b74] 
./473_mem[0x8048944] 
./473_mem[0x8048c87] 
./473_mem[0x8048d31] 
./473_mem[0x8048f79] 
/lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe6)[0xafcb56] 
./473_mem[0x8048671] 
======= Memory map: ======== 
0017c000-00198000 r-xp 00000000 08:01 5224  /lib/libgcc_s.so.1 
00198000-00199000 r--p 0001b000 08:01 5224  /lib/libgcc_s.so.1 
00199000-0019a000 rw-p 0001c000 08:01 5224  /lib/libgcc_s.so.1 
00260000-00284000 r-xp 00000000 08:01 1927  /lib/tls/i686/cmov/libm-2.10.1.so 
00284000-00285000 r--p 00023000 08:01 1927  /lib/tls/i686/cmov/libm-2.10.1.so 
00285000-00286000 rw-p 00024000 08:01 1927  /lib/tls/i686/cmov/libm-2.10.1.so 
006cd000-006e8000 r-xp 00000000 08:01 6662  /lib/ld-2.10.1.so 
006e8000-006e9000 r--p 0001a000 08:01 6662  /lib/ld-2.10.1.so 
006e9000-006ea000 rw-p 0001b000 08:01 6662  /lib/ld-2.10.1.so 
00aa9000-00aaa000 r-xp 00000000 00:00 0   [vdso] 
00ae6000-00c24000 r-xp 00000000 08:01 1900  /lib/tls/i686/cmov/libc-2.10.1.so 
00c24000-00c25000 ---p 0013e000 08:01 1900  /lib/tls/i686/cmov/libc-2.10.1.so 
00c25000-00c27000 r--p 0013e000 08:01 1900  /lib/tls/i686/cmov/libc-2.10.1.so 
00c27000-00c28000 rw-p 00140000 08:01 1900  /lib/tls/i686/cmov/libc-2.10.1.so 
00c28000-00c2b000 rw-p 00000000 00:00 0 
08048000-0804a000 r-xp 00000000 00:14 2176  /media/windows-share/OS/Project2/473_mem 
0804a000-0804b000 r--p 00001000 00:14 2176  /media/windows-share/OS/Project2/473_mem 
0804b000-0804c000 rw-p 00002000 00:14 2176  /media/windows-share/OS/Project2/473_mem 
08483000-084a4000 rw-p 00000000 00:00 0   [heap] 
b7600000-b7621000 rw-p 00000000 00:00 0 
b7621000-b7700000 ---p 00000000 00:00 0 
b7716000-b7819000 rw-p 00000000 00:00 0 
b7827000-b782a000 rw-p 00000000 00:00 0 
bfb96000-bfbab000 rw-p 00000000 00:00 0   [stack] 
Aborted 

Merci à l'avance adi

Answer 1

Regardez les docs de votre compilateur pour voir s'il a l'optimisation "tail récursion". (Bien que maintenant votre problème de débordement de la pile devient un problème de boucle infinie!)

gcc -foptimize-sibling-calls ...

Answer 2

Où est front ensemble?

En appel:

else 
    { 
     return buddy_findout(current_index-1,req_size); 
    } 
} 

Lorsque front est NULL Vous venez tout juste de même fonction plus petite current_index et de garder en boucle et en boucle. Il n'y a pas de condition d'arrêt pour current_index == 0