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

Liste des GroupesRevenir à cl c  
Sujet : Re: > fails. Because heaps are unlimited whilst stacks are not.
De : fir (at) *nospam* grunge.pl (fir)
Groupes : comp.lang.c
Date : 20. Mar 2024, 17:29:45
Autres entêtes
Organisation : i2pn2 (i2pn.org)
Message-ID : <utevdc$2gdd0$1@i2pn2.org>
References : 1
User-Agent : Mozilla/5.0 (Windows NT 5.1; rv:27.0) Gecko/20100101 Firefox/27.0 SeaMonkey/2.24
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)

Date Sujet#  Auteur
20 Mar 24 * > fails. Because heaps are unlimited whilst stacks are not.12fir
20 Mar 24 +* Re: > fails. Because heaps are unlimited whilst stacks are not.4fir
20 Mar 24 i`* Re: > fails. Because heaps are unlimited whilst stacks are not.3fir
20 Mar 24 i `* Re: > fails. Because heaps are unlimited whilst stacks are not.2fir
20 Mar 24 i  `- Re: > fails. Because heaps are unlimited whilst stacks are not.1fir
20 Mar 24 `* Re: > fails. Because heaps are unlimited whilst stacks are not.7bart
20 Mar 24  +* Re: > fails. Because heaps are unlimited whilst stacks are not.4fir
20 Mar 24  i`* Re: > fails. Because heaps are unlimited whilst stacks are not.3fir
20 Mar 24  i +- Re: > fails. Because heaps are unlimited whilst stacks are not.1fir
20 Mar 24  i `- Re: > fails. Because heaps are unlimited whilst stacks are not.1fir
20 Mar 24  `* Re: > fails. Because heaps are unlimited whilst stacks are not.2fir
20 Mar 24   `- Re: > fails. Because heaps are unlimited whilst stacks are not.1fir

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal