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

Groups > comp.lang.c > #383791

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

Show all headers | View raw

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)

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