Re^7: PANIC: underlying join failed threded tcp server

in reply to Re^6: PANIC: underlying join failed threded tcp server
in thread PANIC: underlying join failed threded tcp server

None of that info is particularly helpful to me at least but if you see something I don't, I'm all ears.

What I can see from that info is:

At line 3426:
```
RXD+ (982) > Command completed with a return code of 0
RXD+ (0) > _handle() output: 51686792
thread handle:2d00 thread-id: 4240x
[download]
```
A thread, with a perl thread Id (tid) of 982 completes and Windows thread handle:2d00 has (just prior to joining) a OS thread ID of 4240, and the join completes without error.
Later, at line 3775:
```
thread handle:2d00 thread-id: 0x
GetLastError() output: '6'
Join failed with 'Bad file descriptor' : 'The handle is
invalid' at rxd.pl line 1128.
[download]
```
Just prior to a join attempt, 'another thread' with the same OS thread handle 2d00, this time does not have an OS thread id, which indicates that the thread handle:2d00 is indeed an invalid handle as the system reports.

What that indicates is that either:

The OS is reusing the same OS thread handle -- which whilst possible seems unlikely.
Or this; threads->list(threads::joinable) is returning the handle of an already joined thread. Which also seems unlikely, but could happen if the (Perl) internal linked list got corrupted some how.

The next thing I would try is adding a similar trace line at the end of S_ithread_create(), something like:

S_ithread_create(
...
    printf( "ITCREATE: thread handle:%x thread-id: %dx\n", thread->han
+dle, GetThreadId( thread->handle ) );
    MY_POOL.running_threads++;
    return (thread);
}
[download]

And also in

STATIC void
S_ithread_free(pTHX_ ithread *thread)
{

...

#ifdef WIN32
    printf( "ITFREE: thread handle:%x thread-id: %dx\n", thread->handl
+e, GetThreadId( thread->handle ) );
    if (handle) {
        CloseHandle(handle);
    }
#endif

...

}
[download]

The idea is to isolate whether -- when the error occurs -- the invalid handle is to a thread that has already been freed -- in which case the bug is in threads::list() -- or to a thread that has not yet been freed -- in which case it would mean an OS error of some kind; perhaps resource constraint;

I breifly looked at trying to run your server here and trying to re-create the failure. Whilst the server runs and accepts connections from a telnet seesion, it won't accept input from it because (my) telnet sends character by character and it is expecting entire commands wrapped in your (incredibly complicated) comms protcol.

There is no way I am going to be able to reverse engineer a client that can talk that protocol.

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

RIP Neil Armstrong

In Section Seekers of Perl Wisdom