"not MAP_STACK" message in dmesg / system message buffer

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

"not MAP_STACK" message in dmesg / system message buffer

Andre Smagin
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 system is amd64-current.

--
Andre

Reply | Threaded
Open this post in threaded view
|

Re: "not MAP_STACK" message in dmesg / system message buffer

Theo de Raadt-2
Andre Smagin <[hidden email]> 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 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.

Reply | Threaded
Open this post in threaded view
|

Re: "not MAP_STACK" message in dmesg / system message buffer

Theo de Raadt-2
Theo de Raadt <[hidden email]> wrote:

> Andre Smagin <[hidden email]> 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 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.

Reply | Threaded
Open this post in threaded view
|

Re: "not MAP_STACK" message in dmesg / system message buffer

Marc Espie-2
In reply to this post by Andre Smagin
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)