On Tue, Feb 25, 2020 at 08:30:11PM -0500, Andre Smagin wrote:
> Hello.
>
> While prototyping something in C, I made a mistake with
> pre-processor macros, which I narrowed down to this:
>
> int
> main()
> {
> char *test[10][2097152] = { { 0 } };
> }
>
> Running it results in
> $ ./a.out
> Segmentation fault (core dumped)
>
> and it also logs it in dmesg as
>
> Feb 25 20:05:49 hamlet /bsd: [a.out]52048/372328 sp=7f7ff5fd4150 inside
> 7f7fff7d5000-7f7ffffd5000: not MAP_STACK
> Feb 25 20:06:49 hamlet /bsd: [a.out]94530/186499 sp=7f7ff5fe58c0 inside
> 7f7fff7e7000-7f7ffffe6000: not MAP_STACK
> Feb 25 20:07:09 hamlet /bsd: [a.out]9523/344960 sp=7f7ff5fd9fd0 inside
> 7f7fff7db000-7f7ffffdb000: not MAP_STACK
>
> I have not seen a segfaulting program being logged in system
> message buffer before. Is it expected behaviour?
> Just curious, the message was a bit confusing.
The stack has never been infinite. Allocate too much, run into other issues.
ulimit -a will already tell you about stack size limits.
Baring that, well, running into already allocated memory will hose you.
No further test necessary since MAP_STACK entered the OS (that's sickeningly
beautiful btw)
