Re: zombie creation while debugging and crash in detach()...mutex neccessary - why?

[Mike Papper]

This problem was fixed by using a mutex in both the thread class and the 
function that created the thread (main). I dont think this should be 
neccessary as the thread should not goto its "detach" method (which does a 
delete this) until its run method finishes - and run should not start until 
detach is called from the calling thread.

BUT using a mutex here solved the problem. Any ideas? Perhaps the threads 
detach is called from the constructor in certain error cases?

Note: if I dont call detach fromt he calling thread (main) the new threads 
run method is never called.

Mike Papper

On Thursday 25 September 2003 09:16 pm, Mike Papper wrote:
> Running on linux...red hat 7.2 . CommonCPP version downloaded
> from commoncpp web site about 1 week ago.
>
> I have a program that uses a subclass of TCPSocket to create a new thread
> and hand off the connection to a TCPSession.
>
> The code is from some example somewhere, its like this:
> loop
>   subclassTCPSocket listen(Addr);
>   if (listen.isPendingConnection(timeout)) {
>     tcp = new ecsTCPSession(server);
>     tcp.detach();
>   end for
> end loop
>
> In the TCPSession (thread):
> if (isPending(Socket::pendingInput, 1000)) {
>       string tmp_data;
>       *tcp() >> tmp_data;
>       break;
> }
> tcp() << "Hello from server " << endl;
> // and the thread dies (and to verify, I do see debug output in its
> destructor)
>
> Sometimes this server crashes. So I ran in the debugger (using gdb) and
> what I saw was a zombie thread for each new socket accept. I also saw 2
> processes that were always there.
>
> Debugger Stack trace when it crashes:-------------------------------------
> 0x080614bc in ost::Thread::detach (this=0x8079e34, start=0x0) at
> thread.cpp:729
> 729     thread.cpp: No such file or directory.
>         in thread.cpp
> (gdb) where
> #0  0x080614bc in ost::Thread::detach (this=0x8079e34, start=0x0) at
> thread.cpp:729
> #1  0x080505a5 in main (argc=2, argv=0xbfffea44) at mcs.cpp:257
> #2  0x405a0657 in __libc_start_main (main=0x805007c <main>, argc=2,
> ubp_av=0xbfffea44, init=0x804e3d4 <_init>,
>     fini=0x806b734 <_fini>, rtld_fini=0x4000dcd4 <_dl_fini>,
> stack_end=0xbfffea3c) at ../sysdeps/generic/libc-start.c:129
> -------------------------------
> The call to ost::Thread::detach is made from my code (line 257 mentioned in
> the stack trace, the line for "main") that calls detach (see above) just
> after the call to new ecsTCPSession. Perhaps the thread object has already
> "deleted" itself before I get a chance to call detach (and there is a
> dangling pointer)? But I thought that run isnt called until the new thread
> is created. Is this an incorrect assumption? (If I remove the detach call,
> I see no output from the thread object -- so this call to detach is
> neccessary).
>
> Here is the line 728 and 729 and 730 as mentioned in the debug log (for
> thread.cpp inside the commoncpp detach method):
> -------------------
> 728: rtn = pthread_create(&priv->_tid, &priv->_attr,
> exec_t(&ccxx_exec_handler), this);
> 729:        if(!rtn && priv->_tid)
> 730:                return 0;
> -------------------------
>
> When I run outside of the debugger, I see the same numbered linux processes
> over and over - i..e, I do not see new threads being created. There are
> always 2 processes with the same PIDs (assuming one client connection at a
> time). Somehow the same thread is being resued - any ideas how?
>
> Additional Questions:
> ---------------------------
> 1) Is there a thread pool in commoncpp operating so that its normal to see
> the same 2 processes/linux threads being resued for several connections?
> (non-debugger situation). Or would linux be capable of this re-use of PID?
> 2)Why are the zombie processes created when running in the debugger?
> 3) Is there any good documentation on how to use this class library?
>
> Please Note: when I run on red hat 9, I always see exctly 1 process (new
> m:n threading model). Any way to see its threads?
> Also, this bug does not occur on rh9. Is this impl. dependent?

-- 
Mike Papper
Fantastic
address@hidden
650-356-2113