OMP_STACKSIZE silently exceeded

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

OMP_STACKSIZE silently exceeded

Eatdirt-2
Hi there,
I just want to report something which is standard-compliant, but utterly
sad about the behaviour of OMP_STACKSIZE.

I am running a fortran code, compiled with version 8.3.1, simulation in
which it is difficult to correctly estimate the STACKSIZE used.

I can see that when OMP_STACKSIZE is exceeded, the code is not reporting
anything but continue to run, even compiled with -g. Some THREADPRIVATE
arrays are actually becoming "wild" and start containing random values
without triggering any errors. That's like we're back to the 80s for
debugging parallel code :)

I've checked that, indeed, exceeding OMP_STACKSIZE, is implementation
dependent, but if we could trigger some segfault on this, that would be
much welcome!!!

I can post more details if needed,
Cheers,
Chris.

Reply | Threaded
Open this post in threaded view
|

Re: OMP_STACKSIZE silently exceeded

Tobias Burnus
Hi Chris,

On 10/7/19 4:13 PM, Eatdirt wrote:
> I just want to report something which is standard-compliant, but utterly
> sad about the behaviour of OMP_STACKSIZE.

I asked Jakub, GCC's OpenMP expert – and he replied (thanks!):

"That is standard behavior of pthread_attr_setstacksize etc.,
I think the default is that there is one page guardsize, easy to verify with
strace, but if they access beyond that, of course something else can be
mapped there.  We can't default to gigabytes of guard areas, that is very
costly and impossible on 32-bit targets."

Cf.
http://man7.org/linux/man-pages/man3/pthread_attr_setstacksize.3.html 
and http://man7.org/linux/man-pages/man3/pthread_attr_setguardsize.3.html

Cheers,

Tobias

Reply | Threaded
Open this post in threaded view
|

Re: OMP_STACKSIZE silently exceeded

Eatdirt-2
On 07/10/2019 20:52, Tobias Burnus wrote:

> Hi Chris,
>
> On 10/7/19 4:13 PM, Eatdirt wrote:
>> I just want to report something which is standard-compliant, but utterly
>> sad about the behaviour of OMP_STACKSIZE.
>
> I asked Jakub, GCC's OpenMP expert – and he replied (thanks!):
>
> "That is standard behavior of pthread_attr_setstacksize etc.,
> I think the default is that there is one page guardsize, easy to verify
> with
> strace, but if they access beyond that, of course something else can be
> mapped there.  We can't default to gigabytes of guard areas, that is very
> costly and impossible on 32-bit targets."
>
> Cf.
> http://man7.org/linux/man-pages/man3/pthread_attr_setstacksize.3.html
> and http://man7.org/linux/man-pages/man3/pthread_attr_setguardsize.3.html
>
> Cheers,


Good to know! Thanks for the links!!!

Best.

Reply | Threaded
Open this post in threaded view
|

Re: OMP_STACKSIZE silently exceeded

Janne Blomqvist-3
On Tue, Oct 8, 2019 at 8:38 AM Eatdirt <[hidden email]> wrote:

>
> On 07/10/2019 20:52, Tobias Burnus wrote:
> > Hi Chris,
> >
> > On 10/7/19 4:13 PM, Eatdirt wrote:
> >> I just want to report something which is standard-compliant, but utterly
> >> sad about the behaviour of OMP_STACKSIZE.
> >
> > I asked Jakub, GCC's OpenMP expert – and he replied (thanks!):
> >
> > "That is standard behavior of pthread_attr_setstacksize etc.,
> > I think the default is that there is one page guardsize, easy to verify
> > with
> > strace, but if they access beyond that, of course something else can be
> > mapped there.  We can't default to gigabytes of guard areas, that is very
> > costly and impossible on 32-bit targets."
> >
> > Cf.
> > http://man7.org/linux/man-pages/man3/pthread_attr_setstacksize.3.html
> > and http://man7.org/linux/man-pages/man3/pthread_attr_setguardsize.3.html
> >
> > Cheers,
>
>
> Good to know! Thanks for the links!!!

Does -fstack-check and/or -fstack-clash-protection help?

(I was under the impression that something like
-fstack-clash-protection was the default nowadays, but apparently I
was wrong)


--
Janne Blomqvist
Reply | Threaded
Open this post in threaded view
|

Re: OMP_STACKSIZE silently exceeded

Thomas König
Hi Janne,

> On Tue, Oct 8, 2019 at 8:38 AM Eatdirt <[hidden email]> wrote:
>>
>>> On 07/10/2019 20:52, Tobias Burnus wrote:
>>> Hi Chris,
>>>
>>> On 10/7/19 4:13 PM, Eatdirt wrote:
>>>> I just want to report something which is standard-compliant, but utterly
>>>> sad about the behaviour of OMP_STACKSIZE.
>>>
>>> I asked Jakub, GCC's OpenMP expert – and he replied (thanks!):
>>>
>>> "That is standard behavior of pthread_attr_setstacksize etc.,
>>> I think the default is that there is one page guardsize, easy to verify
>>> with
>>> strace, but if they access beyond that, of course something else can be
>>> mapped there.  We can't default to gigabytes of guard areas, that is very
>>> costly and impossible on 32-bit targets."
>>>
>>> Cf.
>>> http://man7.org/linux/man-pages/man3/pthread_attr_setstacksize.3.html
>>> and http://man7.org/linux/man-pages/man3/pthread_attr_setguardsize.3.html
>>>
>>> Cheers,
>>
>>
>> Good to know! Thanks for the links!!!
>
> Does -fstack-check and/or -fstack-clash-protection help?
>
> (I was under the impression that something like
> -fstack-clash-protection was the default nowadays, but apparently I
> was wrong)

Unfortunately it does not help much. We have increased our stack usage recently, leading to unexplained segfaults in code that used to work.

See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91543 .
Reply | Threaded
Open this post in threaded view
|

Re: OMP_STACKSIZE silently exceeded

Eatdirt-2
In reply to this post by Janne Blomqvist-3
On 08/10/2019 08:01, Janne Blomqvist wrote:
>
> Does -fstack-check and/or -fstack-clash-protection help?

Thank you, that does help indeed. With either one or the other flag, the
code now stops with a segfault when the stack seems to be exceeded.
Perfect!!!