Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #383792

Re: > fails. Because heaps are unlimited whilst stacks are not.

Show all headers | View raw

fir wrote:
> fir wrote:
>> [answer to m.mclean..i post it separately as for me that low level
>> things are specially interesting and worth separate message imo..though
>> i kno sadly there are not much low lewel winapi likers people here, like
>> me who likes low lewel and uses winapi]
>>
>> this is not strictly true
>>
>> well important knowledge which not mantyy programers know i think is
>> that how the layout of program im memory of you system is exactly
>>
>> and i think this knowledge should be learn "by heart" just to increase
>> understanding
>>
>> i know somewhat how it looks like in win32 :
>>
>> generally the addres space aplication have os from 0x0000 0000 to 0x7fff
>> ffff - which is only 2 gigabytes
>>
>> (hovever i like it and still prefer writing my windows programs on win32
>> than win 64, 2 gigabytes of ram is enough for me)
>>
>> your program is by default placed at 0x0040 0000 (which is 4MB from
>> start of adres space)..there is smal pe header loaded to ram then your
>> assembly binary code (typical entry point it is first assemby
>> instruction to run is at 0x00401000 ) then you got loaded const data
>> (.data and .rdata)
>> after the machine code then you got, static empty arrays (.bss) (which
>> are
>> usually big like 100 MB or more depending how many static arrays you
>> got) (allso smaller sections also could be placed there .rsrc for
>> example, .tls, .idata (imports), .CRT, .tls)
>>
>> the dlls your program links to are placed from the top it is from 0x7fff
>> ffff down below, both system ones, part side ones or yours own
>>
>> system ones are optimised to not have .bss which consumes most of the
>> memory so system dlls do not occupy lot of ram (hovevevr system dlls
>> loads and i for example write pure winapi programs and still that system
>> dlls loaded in my program space are nearly 20 od system dlls)
>>
>> heap you got BETWEEN end of your code and begin of dlls, so if your
>> program uses 300 MB od static tables (my fault as i used tod eclate a
>> lot of static tables in various files) and your dlls in sum use 500 MB
>> (of their .bss mostly)  then your heap is limited to 1.3 GB on win32
>>
>> at least this is what i know
>>
>>
>> the stack in turn is betwwwen your app start that +4MB and the starting
>> point, im not exactly syre but its probably something about +3M down do
>> +1M approximatelly
>>
>> stack could be set to bigger in your exe heder your exe has 9may be
>> modified by -something switch in gcc comandline) and i not tested it
>> afair (or rather tested but forgot the strict conclusions) but i dont
>> se nthing specially wrong even in setting this stack to 100 MB
>>
>> 2 MB by default is silly and if you have 10 GB of ram putting 100 MB for
>> stack is not even a waste becouse if it is not used it only consumes
>> "logical" ram pages afair but reall ram is not even attached
>> (downside is it will not run on pc that have less that 100 MB ram as it
>> couldnt alloocate stac i guess but some must assume some numbers today
>> probably, and sadly i would assume at least 2-4 GB and assuming less is
>> optimisation)
>>
>> (I also dont checked if there are some hardcoded limits for stack size
>> like it cant be bigger than 1 Gb or so, could be checked)
>>
>> some vaules some can obtain just by printfing pointers in c application,
>> pointers to stack objectm, pointer to aray begoning pointer to some
>> function, maybe pointer to dlls attached (its function or datya) and
>> pointers to heap storage
>>
>>
>>
>
> note some experimentation
>
> void foo(int how)
> {
>    int b = 90;
>
>    printf("\n b %p ", &b);
>
>    if(how>0) foo(how-1);
>
> }
>
> int main(void)
> {
>
>    int a = 100;
>    printf("  main %p , a %p",  main, &a);
>
>    foo(10);
>
> //  (.... here rest of bigger program skipped as i dont wanted to start
> new project foor test
>
> }
>
> the result
>
>    main 00402BC0 , a 0022FF48
>   b 0022FF4C
>   b 0022FF0C
>   b 0022FEDC
>   b 0022FEAC
>   b 0022FE7C
>   b 0022FE4C
>   b 0022FE1C
>   b 0022FDEC
>   b 0022FDBC
>   b 0022FD8C
>   b 0022FD5C
>
> the entry point is about as i said, stack seem to be probably from
> 0x0023 0000 down below to 0x0003 0000, dont know if its weird if a
> variable is 'below' the first b - it seem meybe weird but i dont hinked
> why is that, i may yet run a crash test
>
> void foo(int how)
> {
>    int b = 90;
>    int tab[32*1024];
>
>    tab[0] = how;
>
>    printf("\n b %p tab %p ", &b, tab);
>
>    if(how>0) foo(how-1);
>
> }
>
> int main(void)
> {
>
>    int a = 100;
>    printf("  main %p , a %p",  main, &a);
>
>    foo(15);
>
>   //...
> }
>
>
> result
>
>    main 00402C10 , a 0022FF4C
>   b 0020FF0C tab 0020FF10
>   b 001EFEDC tab 001EFEE0
>   b 001CFEAC tab 001CFEB0
>   b 001AFE7C tab 001AFE80
>   b 0018FE4C tab 0018FE50
>   b 0016FE1C tab 0016FE20
>   b 0014FDEC tab 0014FDF0
>   b 0012FDBC tab 0012FDC0
>   b 0010FD8C tab 0010FD90
>   b 000EFD5C tab 000EFD60
>   b 000CFD2C tab 000CFD30
>   b 000AFCFC tab 000AFD00
>   b 0008FCCC tab 0008FCD0
>   b 0006FC9C tab 0006FCA0
>   b 0004FC6C tab 0004FC70
>
> floating window appear "there occured a problem with this application..
> do send a data on this problem to microsoft?"
>
> so it is like expected
>
> (hovevevr if i would be bill gates i would tell them to clearly note
> what kind of error this is if this is stack overflow say it is stack
> overflow)


yet some crash test with stack set to 100 MB (-Wl,--stack,104857600)


void foo(int how)
{
   int b = 90;
   int tab[2*1024*1024];

   tab[0] = how;

   printf("\n b %p tab %p ", &b, tab);

   if(how>0) foo(how-1);

}

int main(void)
{

   int a = 100;
   printf("  main %p , a %p",  main, &a);

   foo(11);

  //.....
}

   main 00402C10 , a 0680FF4C
  b 0600FF0C tab 0600FF10
  b 0580FEDC tab 0580FEE0
  b 0500FEAC tab 0500FEB0
  b 0480FE7C tab 0480FE80
  b 0400FE4C tab 0400FE50
  b 0380FE1C tab 0380FE20
  b 0300FDEC tab 0300FDF0
  b 0280FDBC tab 0280FDC0
  b 0200FD8C tab 0200FD90
  b 0180FD5C tab 0180FD60
  b 0100FD2C tab 0100FD30
  b 0080FCFC tab 0080FD00

one more of depth and crashes but with longer delay until the floating 
window of error appear

besides setting stack to 100 MB seem to work ok

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

> fails. Because heaps are unlimited whilst stacks are not. fir <fir@grunge.pl> - 2024-03-20 15:02 +0100
  Re: > fails. Because heaps are unlimited whilst stacks are not. fir <fir@grunge.pl> - 2024-03-20 16:29 +0100
    Re: > fails. Because heaps are unlimited whilst stacks are not. fir <fir@grunge.pl> - 2024-03-20 16:50 +0100
      Re: > fails. Because heaps are unlimited whilst stacks are not. fir <fir@grunge.pl> - 2024-03-20 17:04 +0100
        Re: > fails. Because heaps are unlimited whilst stacks are not. fir <fir@grunge.pl> - 2024-03-20 17:38 +0100
  Re: > fails. Because heaps are unlimited whilst stacks are not. bart <bc@freeuk.com> - 2024-03-20 16:22 +0000
    Re: > fails. Because heaps are unlimited whilst stacks are not. fir <fir@grunge.pl> - 2024-03-20 17:47 +0100
      Re: > fails. Because heaps are unlimited whilst stacks are not. fir <fir@grunge.pl> - 2024-03-20 17:57 +0100
        Re: > fails. Because heaps are unlimited whilst stacks are not. fir <fir@grunge.pl> - 2024-03-20 18:11 +0100
        Re: > fails. Because heaps are unlimited whilst stacks are not. fir <fir@grunge.pl> - 2024-03-20 18:22 +0100
    Re: > fails. Because heaps are unlimited whilst stacks are not. fir <fir@grunge.pl> - 2024-03-20 18:41 +0100
      Re: > fails. Because heaps are unlimited whilst stacks are not. fir <fir@grunge.pl> - 2024-03-20 18:49 +0100

csiph-web