pthreads debugging support and stack size limits

[Galen Tackett]

This is a two part question. First, the short part:

1) The release notes have said since V7.0 that the pthreads debugger metering capability is broken. Here we are now at V8.2 and I believe they still say so. Is this feature permanently broken, or is fixing it just a [very] low priority?


2) Now for the long part:

We have a C++ pthreads application that's been running OK on our unpatched VMS V7.3 systems for some months. The hardware is an AlphaServer 4100 with 4 CPUs. Multiprocessing is disabled--I haven't been at this job long enough to know why.

As part of a recent upgrade cycle some of these systems are now running a new build of the application on V7.3 with these ECO kits: Update V3, SYS V8, ACRTL V4. Of course, Update V3 also includes PTHREADS V3, plus other ECOs that probably aren't related to Pthreads very closely (if at all.)

The new build of our application has been modified to allocate significantly more stack space for a certain specific thread. On the patched system where it's running now have an intermittent problem:

When pthread_attr_setstacksize is called before creating this thread it occasionally returns EINVAL.

The pthreads library manual has the following to say about why EINVAL might be returned here:

"The value specified by attr is not a valid thread attributes object, or the value specified by stacksize either is less than PTHREAD_STACK_MIN or exceeds a Threads Library-imposed limit."

We have ruled out the first two possibilities (invalid thread object or stacksize too small). But what is meant by "Threads Library-imposed limit?" Is it related to some system parameter or process quota?

When the application gets EINVAL it's coded to just throw an exception. The manual says nothing about any underlying VMS error status being available, so it's hard to know what else might be done at this point.

So how can we investigate this?

[Craig A Berry]

There is an example of setting the stack size here:

http://h18000.www1.hp.com/support/asktima/appl_tools/009E60A3-96F8B0E0-1C0186.html

You might compare with your code and see if anything interesting pops out.

There are some comments here:

http://h18000.www1.hp.com/support/asktima/appl_tools/009E60A3-96F8B0E0-1C0186.html

that say, among other things:

"Starting with OpenVMS Version 7.2, any thread that is created with a stack allocation of a specific, absolute size might fail during execution because of insufficient stack space. This failure indicates an existing bug in the application that was made manifest by the change in the Threads Library."

That's of course not very helpful in determining what existing bug, if any, you have. One thing I've heard of people doing is going through and changing any large automatic variables to be explicitly malloced and freed so they are using stack space.

But it appears your exception happens at the time you set the stack size, so none of this is likely to be relevant. How much stack space are you trying to allocate?

[Galen Tackett]

Craig,

Thanks for your input, which does cast a little more light on the stack space issue.

Do you know what is meant by "Threads Library-imposed limit" on stack size? You can see this in context at http://h71000.www7.hp.com/doc/73final/6493/6101pro_016.html#index_x_607 if you scroll down a bit when you get there.

One of our testers sent me an e-mail saying that we've made some progress on resolving this problem. I'll have to find out what's been done.

Galen

[Travis Craig]

Galen,

I can't really answer your root questions, either, but have two thoughts:

1. Multiprocessing might have been turned off to reduce the size of some window of opportunity for various threads of your process to interact destructively. We have found problems that only start to occur when we move from a uniprocessor to a multiprocessor. When we prevent the multi-threaded process from having more than one kernel thread, we don't see the problem anymore, because the computer looks like a uniprocessor to that process again. It probably doesn't really fix the problem. It just makes it less likely.

2. I think the change that Craig referred to that could cause a program to stop working was that they stopped rounding up stack sizes as much as they had before. Thus, your program could specify the same exact stack size as it had before and it would still receive at least that much, but not as much as it had before. Thus if it was already using more than the specified size, then it had a bug that was being hidden by the fact that the system was giving it more space than it had requested. When the system stopped giving it so much extra space, the bug might be revealed.

--Travis Craig

[Ian Miller.]

Have you looked at the process in
SDA with the PTHREAD SDA extension. Parhaps
PTHREAD STACKS
may show the process uses more stack that you think?