Re: "not MAP_STACK" message in dmesg / system message buffer
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-7f7d5000: not MAP_STACK
> Feb 25 20:06:49 hamlet /bsd: [a.out]94530/186499 sp=7f7ff5fe58c0 inside
> 7f7fff7e7000-7f7e6000: not MAP_STACK
> Feb 25 20:07:09 hamlet /bsd: [a.out]9523/344960 sp=7f7ff5fd9fd0 inside
> 7f7fff7db000-7f7db000: 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)
Re: "not MAP_STACK" message in dmesg / system message buffer
Theo de Raadt wrote:
> 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-7f7d5000: not MAP_STACK
> > Feb 25 20:06:49 hamlet /bsd: [a.out]94530/186499 sp=7f7ff5fe58c0 inside
> > 7f7fff7e7000-7f7e6000: not MAP_STACK
> > Feb 25 20:07:09 hamlet /bsd: [a.out]9523/344960 sp=7f7ff5fd9fd0 inside
> > 7f7fff7db000-7f7db000: 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 system is amd64-current.
>
> Your stack allocation is too large. When it was being zero'd you ran out
> the range and hit address space which may not be stack.
More comments:
the MAP_STACK check happens early on kernel entry (syscall or fault),
we don't know if the page exists or not in both cases.. so this triggers first
Eventually this message will go away, and people will have to figure out
the reason for SIGSEGV on their own.
Re: "not MAP_STACK" message in dmesg / system message buffer
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-7f7d5000: not MAP_STACK
> Feb 25 20:06:49 hamlet /bsd: [a.out]94530/186499 sp=7f7ff5fe58c0 inside
> 7f7fff7e7000-7f7e6000: not MAP_STACK
> Feb 25 20:07:09 hamlet /bsd: [a.out]9523/344960 sp=7f7ff5fd9fd0 inside
> 7f7fff7db000-7f7db000: 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 system is amd64-current.
Your stack allocation is too large. When it was being zero'd you ran out
the range and hit address space which may not be stack.
"not MAP_STACK" message in dmesg / system message buffer
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-7f7d5000: not MAP_STACK
Feb 25 20:06:49 hamlet /bsd: [a.out]94530/186499 sp=7f7ff5fe58c0 inside
7f7fff7e7000-7f7e6000: not MAP_STACK
Feb 25 20:07:09 hamlet /bsd: [a.out]9523/344960 sp=7f7ff5fd9fd0 inside
7f7fff7db000-7f7db000: 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 system is amd64-current.
--
Andre
