[omniORB] Thread stack size (again)
Bruce Visscher
visschb@rjrt.com
Thu, 23 Sep 1999 10:10:45 -0400
Hello omniORBers,
A user recently came to me with the following problem. He had an IDL
that looked something like (but more complicated of course):
struct x {
char x1[100];
};
struct y {
char y1[100];
};
struct z {
x xarray[10];
y yarray[10];
};
struct big {
z zarray[23];
};
interface i {
readonly attribute big mybig;
};
He found that the server would crash every time the client invoked the
accessor method. He also noticed that if he reduced the size of big
that the server would no longer crash. We discovered the problem was in
the dispatch member of the skeleton class:
> CORBA::Boolean
> _sk_i::dispatch(GIOP_S &_0RL_s,const char *_0RL_op,CORBA::Boolean _0RL_response_
> expected)
> {
> if (strcmp(_0RL_op,"_get_mybig") == 0)
> {
> if (!_0RL_response_expected) {
> throw CORBA::BAD_OPERATION(0,CORBA::COMPLETED_NO);
> }
> _0RL_s.RequestReceived();
> big _0RL_result = mybig();
This is being allocated on the stack from inside of a tcpSocketWorker
thread. Inside the omnithread implementation, we have the stack size
for Compaq (formerly Digital) systems set to 32768 so obviously, this
isn't going to work.
The solution in this case was to change the arrays of structs to bounded
sequences of structs. After doing this, everything is allocated on the
heap via new rather than on the stack.
OTOH, I wonder if it would be good to have the stack size configurable
either in omnithread and/or omniORB. Since this issue has come up
before (some wanting a *smaller* stack size) I wonder if others think
that this would be a worthwhile modification?
Thanks,
Bruce Visscher