erractic behavior allocating stack memory?

[Claus Olesen]

I got the following stack trace from one of our GUI apps
6 %SYSTEM-F-STKOVF, stack overflow, PC=FFFFFFFF8575E611, PS=0000001B
7 %TRACE-F-TRACEBACK, symbolic stack dump follows
8 image module routine line rel PC abs PC
9 DECW$XTLIBSHRR5 0 0000000000062611 FFFFFFFF8575E611
10 DECW$XTLIBSHRR5 0 0000000000063DE0 FFFFFFFF8575FDE0
11 DECW$XTLIBSHRR5 0 0000000000064FC0 FFFFFFFF85760FC0

I've omitted the remaining lines as they are from application code which I haven't yet scrutinized.

About the STKOVF the help/message says
"An attempt to allocate working storage on the stack exceeded the memory available for the stack."

First I wanted to see if I could recreate the STKOVF on demand. I used this test program

#include

#define S1 0x1e411ee0 //print
#define S2 0x1e411ee1 //ACCVIO
#define S3 0x1e413631 //silence
#define S4 0x7fffffe1 //STKALLEXC

#define S S2

int main()
{
char a[S];
a[0] = 'b'; //touch begin
a[S-1] = 'e'; //touch end
printf("%p %c\n",a,*a);
printf("%p %c\n",a+S-1,*(a+S-1));
}
built with
$ cc /nooptimize
$ link

But no luck. Besides, perhaps the STKOVF in the stack trace is not of the user stack - I don't know how to tell.
But what I got from running the test program is erractic.
Up until S1 the test program prints as expected.
Past that and up to S2 it crashes with ACCVIO.
Past that and up to S3 it is silent - no print and no system message.
Past S4 the compiler complains with STKALLEXC.

Granted, allocating that much on the stack is perhaps a rarity. Still, anyone else experienced this?

The system is OpenVMS/IA64 8.2-1.

[Dennis Handly]

>But what I got from running the test program is erratic.

(My experience is for HP-UX.)

If you are going to write programs like this, you may want to use memset or a for loop to go though each element.
On HP-UX, there is a guard page and if your request is so large, the beginning and end may skip right over it.

Basically illegal programs don't have to produce consistent nor understandable (to the hoi polloi) failures.

[Wim Van den Wyngaert]

Multithreading ?
http://groups.google.be/group/comp.os.vms/browse_thread/thread/11e7e02f67be2dab/4ba6f5e0a3a57445?hl=en&lnk=st&q=STKOVF+%22c%22#4ba6f5e0a3a57445

Wim

[John Gillings]

Claus,

STKOVF in a normal, single threaded process is unusual, and generally means something like runaway recursion (which is very obvious in the traceback, as you'll see pages of the same routine). The stack for a single thread is in P1 space and "large enough" for most normal processes.

More likely STKOVF occurs when threading, where each thread is allocated a limited sized stack, usually in P0 space. If you can run your program under DEBUG use EXAMINE/HEX SP to see where the stack is located. Anything higher than 40000000 is in P1 space, most commonly it will be a 7xxxxxxx address.

If you see an SP under 40000000 it's almost certainly a thread stack. The size is controlled by the threading package. They're usually quite small by default, so anything that needs significant chunks of stack (like DECwindows?) may require setting the appropriate attribute to increase the stack size. Or, if the code is under your control, move any large objects off the stack.

[Claus Olesen]

Thank you for your replies.

I started the app and attached the debugger
$ debug/keep
$ connect procname
DBG>EXA/HEX SP
0\%SP: 000000007ACF4A10
DBG>disconnect procname

It shows that the stack is the thread stack according to John.

However, as something new - the disconnect command crashed the application. Perhaps that's noise in this context. Then again - perhaps not. So I repeated the exercise but with the decburger app instead and also it crashed on disconnect. Here's its stack trace

Running DECburger...
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=0000000000000087, PC=FFFFFFFF805
E4051, PS=0000001B
%TRACE-F-TRACEBACK, symbolic stack dump follows
image module routine line rel PC abs PC
0 FFFFFFFF805E4051 FFFFFFFF805E4051
DECW$LCNLIBSHR 0 0000000000020A70 FFFFFFFF85424A70
DECW$LCNLIBSHR 0 0000000000020EC0 FFFFFFFF85424EC0
DECW$XLIBSHR 0 00000000001C7610 FFFFFFFF855DB610
DECW$XTLIBSHRR5 0 000000000008D1C0 FFFFFFFF857871C0
DECW$XTLIBSHRR5 0 0000000000092A80 FFFFFFFF8578CA80
DECW$XTLIBSHRR5 0 0000000000065220 FFFFFFFF8575F220
DECBURGER DECBURGER main 37449 0000000000000F60 0000000000030F60
DECBURGER DECBURGER __main 37369 00000000000000E0 00000000000300E0
PTHREAD$RTL THD_THREAD thdBase 243894 0000000000005CC0 FFFFFFFF84549690
PTHREAD$RTL THD_INIT pthread_main 243654 00000000000006C0 FFFFFFFF845006C0
0 FFFFFFFF80B2EAF0 FFFFFFFF80B2EAF0
DCL 0 000000000006B0C0 000000007AE250C0
%TRACE-I-END, end of TRACE stack dump

I also tried on a AXP/OpenVMS 7.2-1 and a I64/OpenVMS8.3 and the decburger app did not crash on debugger disconnect on either of those systems.

Do you think the crash on debugger disconnect on the v8.2-1 system could be just another manifestion of the same problem manisfested by the STKOVF? In other words might upgrading to v8.3 fix the STKOVF? (all eco's have already been installed on the v8.2-1 system)

Incidently, among the lines that I omitted from the STKOVF stack trace are the exact same 2 pthread lines as in the decburger stack trace.

As to Wims suggestion then the release notes for OpenVMS 8.3
http://h71000.www7.hp.com/doc/83final/6677/OVMS_83_REL_NOTES.PDF pt. 5.32.1 says that the default stack size has been increased by 24kb.

How could I increase the thread stack size for DECwindows? pthread_attr_setstacksize() requires a thread object.