Conference clt::cma

1478.0. ""limit to method call in a thread?"" by SMURF::BAT (Segui la tua beatitudine) Tue Feb 04 1997 19:38

    Customer is running a DIGITAL UNIX variant -- old version.
    
    Is there an implicit limit to a method call in a thread?  
    (see end)  Or is there something else entirely going on here?
    
    ====================================================================
Date: Tue, 4 Feb 1997 11:53:43 -0500
From: [email protected] (Tammy Sandefur)
To: [email protected]
Subject: critical help please

hi Bat,


  I just received this from another new-b out at trident. Then I get a call
from Jr saying they need info by due date (friday).  

  My response (oh well) I wanted to say take a number, but I held back.

from steve:

Essentially, I have a c++ class that gets instantiated before I make a
pthread_init.  When I go to make a call against that class from within a
thread, I get a segment violation.  If, however, I make a call against
that class within my main(), it executes flawlessly.

I've ensured that I've done the proper typecasting and I've ensured that
the class variable I am using is valid.  I've ensured that the variable
is even the *exact* same variable in the main() and the thread.  For
instance, my class is sServerClass, with it's instantiation being
pServer.
Within main():  pServer->sendToClient(...) works just fine.  Within the
thread, pServer->sendToClient(...) causes a segment violation.
main::pServer and thread::pServer are exactly the same value.

I compile all my sources that are threaded with -D_REENTRANT, and pass
"-Wthreads -lpthreads -lmach -lc_r" to the linking stage.  I use gcc
2.7.2.1.  I do, however, use dec's linker.

error When the program does finally segment violate, I actually get an
exception error from the dce/thd subsystem (invalid memory address).
 

Thanks 

          
Tammy Sandefur
Digital Equipment
Ultrix & Osf Network Support
[email protected]
    =============================================================
Date: Tue, 4 Feb 1997 13:59:42 -0500
From: [email protected] (Tammy Sandefur)
To: [email protected]
Subject: more info from steve

I've been working on the problem I described to you earlier about my
threads not executing a method properly.  I managed to find a workaround.

If I go in and strip the method down to its BARE calls (ie, strip out any
superflous debugging information, streamline the flow a bit, ultimately
generating a smaller footprint), then the method works.  Which leads me to
believe that it is a stack corruption problem.

Well, I used pthread_attr_setstacksize() to set the stack size of the
thread to be 640k, just in case (yes, I went a bit on the extreme side),
but that didn't seem to have any affect ...

Is there an implicit limit to a method call in a thread?  Is there
something I'm doing wrong with my pthread_attr_setstacksize() call? (yes,
I do pthread_attr_create( &variable ); pthread_attr_setstacksize(
&variable, 640*1024); pthread_create( ..., variable ...) ) ...

          
Tammy Sandefur
Digital Equipment
Ultrix & Osf Network Support
[email protected]

>If I go in and strip the method down to its BARE calls (ie, strip out any
>superflous debugging information, streamline the flow a bit, ultimately
>generating a smaller footprint), then the method works.  Which leads me to
>believe that it is a stack corruption problem.

Yes, that seems likely.

>Well, I used pthread_attr_setstacksize() to set the stack size of the
>thread to be 640k, just in case (yes, I went a bit on the extreme side),
>but that didn't seem to have any affect ...

The important question is: was 640Kb actually extreme, or were you too
conservative? Sure, 640Kb is a LOT bigger than the default thread stack. But
it's still a lot smaller than the main thread's stack.

>Is there an implicit limit to a method call in a thread?

Not except relating to how much stack space is available.

>Is there something I'm doing wrong with my pthread_attr_setstacksize() call?

If there is, I can't tell you from the limited information in the note. You
might try calling pthread_debug() and issuing the "thread -f" command to see
the actual size of the stack for each thread.

	/dave

.0> If I go in and strip the method down to its BARE calls (ie, strip out any
.0> superflous debugging information, streamline the flow a bit, ultimately
.0> generating a smaller footprint), then the method works.  Which leads me to
.0> believe that it is a stack corruption problem.

Either that, or it's one of the debugging statements which is generating the
SEGV.  Is there any reason to believe that gcc generates thread-safe code? 
Likewise, is the customer using a thread-safe C++ run-time??

If you run the program under the debugger and catch the SEGV, what does the
stack trace show?


				Webb