Any clues on what would do this to a process?

[JJ_4]

So, on an HP Itanium machine, a process is running, and then just "disappears".

Review of the syslog shows :

vmunix: Pid 6251 was killed due to failure in writing the User register stack- possible stack overflow.

What signal would the O/S (if it was the O/S) send the process?

[Fabian Briseño]

Hello JJ.
What OS version ?

What process is causing this, DB, application ?

Since when is thi happening ?

[TTr]

> possible stack overflow

Check the stack size in the kernel. If you have not changed it from the default size, consider increasing it if you think or you know that this process requires a large stack size. Otherwise the process has a bug or it was not meant to run on itanium based HP-UX.

[Fabian Briseño]

Hello JJ.
Maybe the following thread will help.

http://forums13.itrc.hp.com/service/forums/questionanswer.do?admit=109447627+1242832524002+28353475&threadId=861749

[JJ_4]

HP-UX Itanium 11.23

This is a set of processes which make up a Database Environment (generally two or more processes will be killed as above).

ulimit shows stacksize as a huge 128Mb ... so doubt it is actual "stack" overflow.

Machine had been up for 100 days and "no changes".

Increase the kernel stack size?? What parameter is that?

[TTr]

It's maxssiz and maxssiz_64bit. Whatever you database is, check if there are other kernel parameter settings that are recommended for this particular database.

[Fabian Briseño]

Hello JJ.
More threads to check.

http://docs.hp.com/en/TKP-90202/TKP-90202.pdf

[Steven E. Protter]

Shalom,

ulimit is not the only possible cause.

maxdsiz
maxssiz

and their 64 bit mates can all be part of this issue.

It is likely you will need to reboot your system to make all the required kernel changes.

SEP

[Don Morris_1]

No, you should check maxrsessiz / maxrsessiz_64bit -- note that you had a failure writing the *register stack*. In particular, you should get this message when the RSE stack write fails while trying to process a signal for a process in the kernel (and the kernel sends the kill signal to the process after the message).

[Dennis Handly]

> ulimit shows stacksize as a huge 128Mb ... so doubt it is actual "stack" overflow.

Perhaps you have infinite recursion so no matter how big you make it, you will always die. Make this smaller so you will die here first vs the RSE stack below.
It would be good to look at a stack trace from a core file.

Also, if you are on a thread stack, changing maxssiz or maxrsessiz won't help.

>Don: you should check maxrsessiz / maxrsessiz_64bit

I've only had to increase this to 16 Mb for one heavily recursive application.
Unfortunately you'll have to reboot to change this.