Exception with large data member crashes ? Or something else (code fore review attached)

[v2_1]

I want to understand who is the exact culprit.

1) typedef ExceptionIdF AgentException;

2) char Mylog::str[5*4048];

3) rethrow

4) anything else?

The attached program core dumps.

This is the narrower version of the actual big code that is coring.

---------------
Bus error (core dumped)
-rw------- 1 vikrantl Developm 6334372 Feb 21 20:45 core
HP gdb 5.1.1 for PA-RISC 1.1 or 2.0 (narrow), HP-UX 11.00
and target hppa1.1-hp-hpux11.00.
Copyright 1986 - 2001 Free Software Foundation, Inc.
Hewlett-Packard Wildebeest 5.1.1 (based on GDB) is covered by the
GNU General Public License. Type "show copying" to see the conditions to
change it and/or distribute copies. Type "show warranty" for warranty/support.
..
Core was generated by `mutliex'.
Program terminated with signal 10, Bus error.
BUS_UNKNOWN - Unknown Error
#0 0xce20 in ff1 () at mutliex.cpp:216
216 {
(gdb) #0 0xce20 in ff1 () at mutliex.cpp:216
#1 0xd9f8 in ff2 () at mutliex.cpp:261
#2 0xda40 in ff3 () at mutliex.cpp:267
#3 0xda9c in ff4 () at mutliex.cpp:275
#4 0xde4c in dispatch2 (arg=0x40020368) at mutliex.cpp:340
#5 0xc2e98220 in ACE_OS_Thread_Adapter::invoke (this=0x40010920)
at OS_Thread_Adapter.cpp:94
#6 0xc2e97ef8 in ace_thread_adapter (args=0x40010920)
at Base_Thread_Adapter.cpp:122
#7 0xc005acc0 in __pthread_body+0x44 () from /usr/lib/libpthread.1
#8 0xc0063d04 in __pthread_start+0x14 () from /usr/lib/libpthread.1
(gdb) bash-3.00$ pwd
/export/homes/vikrantl/good50/VxAM/Current/source/sicl
bash-3.00$ tar cvf my.prg.tar mutliex.
mutliex.cpp mutliex.o
bash-3.00$ tar cvf my.prg.tar mutliex.pp mym.sh
tar: cannot stat mutliex.pp. Not dumped.
a mym.sh 5 blocks
bash-3.00$ tar cvf my.prg.tar mutliex.cpp mym.sh
a mutliex.cpp 21 blocks
a mym.sh 5 blocks
bash-3.00$

[v2_1]

patch info. attached

[Dennis Handly]

If you are throwing a large object, you must have room for it on your stack. If you have several throws, there are separate temps generated and that may exceed your 64Kb default thread stack. You have 5 AgentException in ff1. So you have 5 * 12 * 4024. Way too big for the default thread stack size. You need to use pthread_attr_setstacksize(3) or pthread_default_stacksize_np(3) to make it larger.

Or create the objects on the heap and manually destroy them.

[v2_1]

void ff1()
throw (AgentException)
{
Mylog m("ff1");
return;
#if 1

Hi Dennis Handly, thanks for the direction.

Even if I return before the actual line where the Exception would be thrown, would that space be consumed?

Secondly, for the original program, I see this problem occuring only on HP-UX, any of 11.x, any comments?

Thanks,
-V2

[v2_1]

And one more thing, this happens only if the ff functions are called from more than one threads.

Does the stack size for all the threads add up for the max. stack size? Or each gets to use the max. stack size?

[Dennis Handly]

>Even if I return before the actual line where the Exception would be thrown, would that space be consumed?

Yes on PA. But not for IPF, exceptions are allocated in the heap. (Use all you want, we'll make more. :-)

>I see this problem occuring only on HP-UX, any of 11.x, any comments?

Other OSes may have larger default thread stacks. Or they may not allocate exceptions on the stack. Or they may not be as sloppy as aCC3. :-(

>This happens only if the ff functions are called from more than one threads.

Yes, it happens only when you are on a thread stack, not the main thread, which has a giant stack.

>Does the stack size for all the threads add up for the max stack size? Or each gets to use the max stack size?

Each thread gets pthread_attr_setstacksize. The main thread gets maxssiz.

[v2_1]

Is there any way i can use an API to find out the current utilization on the stack?
Somthing like pthread_attr_getstacksize?

[Dennis Handly]

>Is there any way i can use an API to find out the current utilization on the stack?
Something like pthread_attr_getstacksize?

pthread_attr_getstacksize will only give you the current value of your attributes when you create the thread. Otherwise you'll have to get the initial thread stack addreses and the current SP value. I was going to mention how to do this in gdb but it was obvious why you were aborting.

So for your stack trace:
(gdb) frame 9
(gdb) p /x $save_sp = $sp
(gdb) frame 0
(gdb) p $sp - $save_sp

(For IPF the stack grows in the other direction.)

If you wanted to approximate an API, you could take the address of your parm in ace_thread_adapter and take the address of some local in your current function and the difference would be a rough estimate of your usage.

[Dennis Handly · Accepted solution]

You have currently have not assigned any points. If you have gotten your answers you should look at:
http://forums1.itrc.hp.com/service/forums/helptips.do?#33

[v2_1]

Thanks Dennis for excellent direction from you, I have resolved the issue by setting a larger stack size for the pthreads.

Regards,
-V2