Theo de Raadt <dera...@openbsd.org> wrote:
> Andre Smagin <a...@smagin.com> 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.
