Looping forever,can this be right?

[Alex]

On x86 (and probably most other PCs),  data and program memory occupy the 
same address space.

The (virtual) memory is divded into 4096 byte (pages) frames. 
Segmentation faults only occur when a program accesses an address outside 
its valid page set.

The runtime stack holds the local variables that are used in a function. 
The SAME stack also holds the arguments passed to a function and the 
return address (for when the function ends).

If you write outside the bounds of an array on the stack,  you will likely 
overwrite the return address part.   Which means when the function ends, 
it will not return to where you expected.  Basically, if you write outside 
ANY array in a C/C++ program,  you cannot expect it to work correctly -- 
even if just a single element is incorrectly written.  (Off-by-one errors 
can be really nasty)

This is how the so-called "buffer-overflow" attacks work.  They manage to 
inject and execute executable code in this manner.  Do a google search on 
"Stack smashing for fun and profit"...  Sadly, I think many C programmers 
still don't know about this.

If you want to make sure a program segfaults when an invalid array index 
is accessed,  then do a READ and not a WRITE to that array.  This will not 
affect program stability but will have the intended affect.

-Alex

On Sat, 11 Mar 2006, Petur Thors wrote:

> Hi Sven.
> Yes I was doing the out of bound error on purpose, I was making sure it
> segfaulted, but this forever looping thing was not what I was expecting.
> The i loopcounter variable should not be affected by a[i] = 1 (which
> doesn't happen in a[i] = 11) but it seems to reset itself! This is very
> strange.
> It would be brilliant if someone could explain this totally different
> behavior depending on using a[i] = 1 (forever loop) or a[i] = 11
> (segfaults after 1531 loops) in the body of the for-loop.
> Thanks very much.
> Petur
>
> Sven Eschenberg wrote:
>
>>  Hi Petur,
>>
>>  This might look strange, but did you realize you are creating a buffer
>>  overflow (out of bound error) and thus I would expect a completely
>>  undefined behavior ... segfaulting really makes sense ... if you ask me
>>  ...
>>
>>  Regards
>>
>>  -Sven
>> 
>>
>>  Petur Thors wrote:
>> 
>> >  Hi
>> >  Please correct me if I'm totally lost here , but compiling this program 
>> >  (a.c)  with gcc -Wall -pedantic -o a a.c :
>> > 
>> >  #include <stdio.h>
>> >  int main(int argc,char **argv)
>> >  {
>> >     int i;
>> >     int a[10];
>> >     for(i = 0; i < 2000; i++) {
>> >         printf("a[%d] is %d\n",i,a[i]);
>> >         a[i] = 1;
>> >     }
>> >     return 0;
>>> }
>> > 
>> > 
>> >  and running it i get :
>> > 
>> >  a[0] is 0
>> >  a[1] is 0
>> >  a[2] is -2146329632
>> >  a[3] is 51
>> >  a[4] is 4195584
>> >  a[5] is 0
>> >  a[6] is 4195312
>> >  a[7] is 0
>> >  a[8] is -4327808
>> >  a[9] is 32767
>> >  a[10] is 0
>> >  a[11] is 11
>> >  a[2] is 1
>> >  a[3] is 1
>> >  a[4] is 1
>> >  a[5] is 1
>> >  a[6] is 1
>> >  a[7] is 1
>> >  a[8] is 1
>> >  a[9] is 1
>> >  a[10] is 1
>> >  a[11] is 11
>> >  a[2] is 1
>> >  a[3] is 1
>> >  a[4] is 1
>> >  a[5] is 1
>> >  a[6] is 1
>> >  a[7] is 1
>> >  ....
>> >  looping forever and ever........
>> > 
>> >  But when I change a[i] = 1 to a[i] = 11 (in the for loop) it segfaults 
>> >  at i = 1532.
>> > 
>> >  Please forgive me if I'm totally missing something obvious here but can 
>> >  this be correct ?
>> > 
>> >  gcc specs:
>> > 
>> >  Using built-in specs.
>> >  Target: x86_64-redhat-linux
>> >  Configured with: ../configure --prefix=/usr --mandir=/usr/share/man 
>> >  --infodir=/usr/share/info --enable-shared --enable-threads=posix 
>> >  --enable-checking=release --with-system-zlib --enable-__cxa_atexit 
>> >  --disable-libunwind-exceptions --enable-libgcj-multifile 
>> >  --enable-languages=c,c++,objc,java,f95,ada --enable-java-awt=gtk 
>> >  --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre 
>> >  --host=x86_64-redhat-linux
>> >  Thread model: posix
>> >  gcc version 4.0.2 20051125 (Red Hat 4.0.2-8)
>> >  Updated Fedora core 4
>> > 
>> >  Thanks in advance and best regards
>> >  Petur
>> > 
>> > 
>> 
>> 
>
>
>