setsockopt() on windows takes a SOCKET type, not an
int which isn't the same size on Win64. I don't have
a patch ready, but noticed it while fixing porting
TclSockMinimumBuffers() is found in generic/tclIOSock.c
IMHO, this function was over-factored into generic originally.
proposal for solution committed to branch bug-510001
For Tcl8.4 and 8.5 it effectively means removing the
stub entry for TclSockMinimumBuffers on WIN64
(On win32 everything stays as is). Extension writers
using this function (are there any?) will notice that
the function is gone. Tcl uses a small static
function with the correct signature in stead,
which does the right thing.
In Tcl 8.6, it is already solved by changing the
signature having ClientData as first parameter.
This way, everything is kept binary compatible.
Extension writers who want this function will
have to use their own, or wait for Tcl 8.6.
current 8.4 branch hangs in the test suite at test
event-11.5 . gdb points the blame at a routine:
Program received signal SIGINT, Interrupt.
TclSockMinimumBuffersOld (sock=0, size=0)
And that leads me to report it here.
8.5 branch experiences a similar hang
in test chan-16.9
Problem also experienced on OSX. Call graph is:
Sampling process 47709 for 3 seconds with 1 millisecond of run time between samples
Sampling completed, processing symbols...
Analysis of sampling tcltest (pid 47709) every 1 millisecond
Total number in stack (recursive counted multiple, when >=5):
Sort by top of stack, same collapsed (when >= 5):
Sample analysis of process 47709 written to file /dev/stdout
I *suspect* you've managed to make the code be defined to just call itself.
Bumping prio to 9 as this now hangs the test suite on multiple maintenance branches.
/* See bug 510001: TclSockMinimumBuffers needs plat imp */
# undef TclSockMinimumBuffers
# define TclSockMinimumBuffers(a,b) TclSockMinimumBuffersOld((int)(a),b)
That's at the bottom of tclIntDecls.h.
So on any system that's not WIN64, we've
got TCMBO endlessly calling itself recursively.
workaround committed. Solves the problem, but
I don't know that it's the right fix.
Yes, that's the right fix. Thanks!
Moved the #undef up in the file, placing it together
other #undef's which handle macros conflicting with
later definitions in that file as well.
All should be OK now.
WOW. A 10 year old suggestion :) You guys rock. I've out of the scene for ages, but just recently started on a new extension to get my feet back in coding again. Long live Tcl.