pthread stack size

[Court Campbell]

I've perused a few man pages related to pthreads and have not been able to determine what the default stack size is on 11.31 on Itanium. pthread_attr_init does point that the default is 256k, but I am not sure if that is accurate.

We have a server running informatica. It was working correctly until the latest pthread patch PHCO_41407. After that patch we now find it necessary to set PTHREAD_DEFAULT_STACK_SIZE to a larger value. I have other machine that is not patched yet. I was wondering how to display the default stack size.

[James R. Ferguson]

Hi Court:

See if this helps:

http://h30499.www3.hp.com/t5/System-Administration/Pid-lt-nnn-gt-killed-due-to-trashed-stack/m-p/5106420#M445205

Regards!

...JRF...

[Court Campbell]

JRF: I did see that thread. Following the trail for that thread just get me to the same default of 256k. But leaves me confused as to why the application worked fine until we applied the patch. It makes me think the default is less. I only say that because the pthread calls from informatica should presumably be the same before and after the patch.

[James R. Ferguson]

Hi (again):

If you had already seen the thread reference I cited, then I assume that you have googled for other threads in the ITRC on this topic. There seem to be a fair number.

Perhaps you should open a call to the Response Center.

Regards!

...JRF...

[Dennis Handly · Accepted solution]

The default stacksize is 256. 1/2 of this is for the user stack and the other for the RSE stack.
(I'm on an internal patch after PHCO_41407.)

>I was wondering how to display the default stack size.

You can use tusc to find the size of the mmap(2): 266240 == 128 Kb * 2 + 4 kb guard

>because the pthread calls from informatica should presumably be the same before and after the patch.

Yes but the functions in libc or libpthread may use slight more stack space and that may be just enough to get an overflow.

>JRF: See if this helps:

threadId=1227330 is about PA. Integrity is slightly different, due to RSE.

[Court Campbell]

Dennis:

> Yes but the functions in libc or libpthread may use slight more stack space and that may be just enough to get an overflow.

This is the part that bothers me. If the functions use more stack space, why not also increase the default stack size to accommodate the function changes?

P.S. thanks for the info. I was actually waiting for your reply.

[Dennis Handly]

>why not also increase the default stack size to accommodate the function changes?

Because "slightly more" isn't enough to worry about? ;-)
And increasing it may break other applications that may run out of swap.
And most important of all, this isn't a 16 bit machine where every byte on the stack needs to be accounted.

Do you have a corefile of your thread stack overflow? How much was your "larger" value?

I have seen a problem with mallocNG and thread stacks where the recursion was over 5K frames.

[Court Campbell]

No core files that I am aware of. The informatica management piece could no start a service. The log files had no details. We only found "the fix" after putting in an SR with Oracle. They had another client running on HPUX where setting PTHREAD_DEFAULT_STACK_SIZE to a higher value resolved the issue. We now have it set to 524288.

[Dennis Handly]

>No core files that I am aware of.

Ok. We can't get the exact stack trace to figure out the calls and stack usage.

>where setting PTHREAD_DEFAULT_STACK_SIZE to a higher value resolved the issue. We now have it set to 524288.

Well that doubles it but doesn't tell you exactly how much bigger it needed. If you have time to experiment you could use: 331776