topic Re: Problem with PTHREAD_STACK_MIN in Operating System - HP-UX

Problem with PTHREAD_STACK_MIN

Ph Vouters — Wed, 27 Apr 2011 16:55:00 GMT

Hello,

I am running on an HP-UX B.11.31 IA64 with no patches installed (HP's AllianceONE program). While attempting to run all Ruby 1.9.2 p180 tests, it reveals I am suffering from the exact same symptom than the one described at http://stackoverflow.com/questions/717327/how-to-diagnose-trace-sendsig-useracc-failed-problem-in-hp-ux

On the computer I use, the following command shows:
# grep PTHREAD_STACK_MIN /usr/include/limits.h
# define PTHREAD_STACK_MIN 4096

Could you tell me what is your PTHREAD_STACK_MIN value on an up to date patched HP-UX B.11.31 IA64 system ?

Thank you in advance.
Philippe

Re: Problem with PTHREAD_STACK_MIN

Dennis Handly — Wed, 27 Apr 2011 17:09:47 GMT

>Could you tell me what is your PTHREAD_STACK_MIN value on an up to date

Why is this important? This value is just too small for real applications. The default is 256 Kb, with 1/2 used for the user stack and the other for the RSE stack.

Re: Problem with PTHREAD_STACK_MIN

Ph Vouters — Wed, 27 Apr 2011 17:23:40 GMT

Denis,

This is important because Ruby sets the stack size of a thread to PTHREAD_STACK_MIN. And in the case of one specific Ruby test, the stack is undersized.

The Ruby code is fairly dependant upon the value of PTHREAD_STACK_MIN if PTHREAD_STACK_MIN is defined which is the case on an HP-UX B.11.31 system.

Hence my very accurate question.

Philippe

Re: Problem with PTHREAD_STACK_MIN

Dennis Handly — Thu, 28 Apr 2011 03:28:47 GMT

>Ruby code is fairly dependent upon the value of PTHREAD_STACK_MIN

This value is too small on HP-UX, especially if you need a ucontext_t which is already > 4 Kb. You should take the default or experiment with minimum sizes.

Re: Problem with PTHREAD_STACK_MIN

Rajesh K Chaurasia — Thu, 28 Apr 2011 03:43:55 GMT

Have you considered using pthread_attr_setstacksize() and pthread_attr_setstacksize() to get the current value of stack size and set to higher value if needed. For the set function, valid values of stacksize attribute are,

PTHREAD_STACK_MIN or
stacksize (excerpt from the man page)...
This defines the size (in bytes) of the user stack for threads created with this attributes object. This value must be greater than or equal to the minimum stack size PTHREAD_STACK_MIN.

Ruby code should check and set thread stack size instead of relying on default value.

BTW, the value of PTHREAD_STACK_MIN is 4096 on latest HP-UX 11i v3 release.

Regards
-Rajesh

Re: Problem with PTHREAD_STACK_MIN

Ph Vouters — Thu, 28 Apr 2011 08:15:16 GMT

Thank you everyone. The problem is that the Ruby 1.9.2 source does code pthread_attr_setstacksize(PTHREAD_STACK_MIN) if PTHREAD_STACK_MIN is defined which is insufficient on HP-UX IA64 for the given thread.

I thus modified /usr/include/limits.h to include the lines:
# ifndef PTHREAD_STACK_MIN
# define PTHREAD_STACK_MIN 4096
# endif
like on OpenVMS and defined PTHREAD_STACK_MIN to 512*1024 in the CPPFLAGS before the ./configure.

I now face another problem farther while running the tests with the pthread library. pthread_attr_destroy(&attr) returns EINVAL although all previous pthread_attr_xxxx did return 0. I think I now would need the latest pthread patch.

Not being able to access the patch library due to HP's policy change, could someone tell me whether there are known problems with pthread_attr_destroy which have been corrected since stock HP-UX B.11.31 ?

Philippe

Re: Problem with PTHREAD_STACK_MIN

Rajesh K Chaurasia — Thu, 28 Apr 2011 08:38:07 GMT

It is not a good practice to re-define system header file constants. The modified code would work but other pieces of code may be confused. You can pass new stack size to pthread_attr_setstacksize().

For the failing pthread_attr_destroy(&attr) do you have a corresponding pthread_attr_init() call previously. If not, the attr may have invalid value.

Regards
-Rajesh

Re: Problem with PTHREAD_STACK_MIN

Ph Vouters — Thu, 28 Apr 2011 08:52:43 GMT

The Ruby 1.9.2 source code is pretty well coded regarding pthreads. The problem should rather lay inside the stock HP-UX B.11.31 pthread library implementation which looks to be buggy.

Concerning my change to limits.h, it is definitely not a good idea from the HP-UX pthread lab to set PTHREAD_STACK_MIN to an irrealistic value. The OpenVMS pthread.h looks to be much better coded regarding this aspect.

Philippe

Re: Problem with PTHREAD_STACK_MIN

Dennis Handly — Fri, 29 Apr 2011 06:29:33 GMT

>could someone tell me whether there are known problems with pthread_attr_destroy?

I don't see any patches mentioning it.

>it is definitely not a good idea from the HP-UX pthread lab to set PTHREAD_STACK_MIN to an unrealistic value.

Unrealistic perhaps, if you expect to get signals.

And you could use sigaltstack(2):
Each thread may define an alternate signal handling stack.

Re: Problem with PTHREAD_STACK_MIN

Rajesh K Chaurasia — Thu, 12 May 2011 05:02:50 GMT

PTHREAD_STACK_MIN is architecturally defined minimum stack size. The value may be impractical for general application. If you have issues please report to HP response center (need a valid HP-UX support contract) to have the behavior corrected.

The value of PTHREAD_STACK_MIN has remained same (4096) on PA-RISC/Integrity on all HP-UX releases.

Regards
-Rajesh

Re: Problem with PTHREAD_STACK_MIN

Ph Vouters — Thu, 12 May 2011 07:36:15 GMT

There is no bug in pthread_detach. This was simply caused by an indirect setjmp call through a Ruby's rb_raise in a thread leading to various run-time failures. Squeezing this rb_raise made Ruby behave much better.

Got a little problem with pthread_cond_timedwait. It looks like that the maximum acceptable delay is 874800000 seconds under HP-UX 11iv3.

About PTHREAD_STACK_MIN, no support contract => no problem report to HP.

Now the latest Ruby is available on HP-UX. It has already really interested two Chinese people. And this is what I really do care about.

Re: Problem with PTHREAD_STACK_MIN

James R. Ferguson — Thu, 12 May 2011 10:15:53 GMT

Hi:

> It has already really interested two Chinese people. And this is what I really do care about.

Who cares what nationality is interested? As a global community, why not simply say "...has really interested TWO PEOPLE".

...JRF...