Here's the gdb backtrace:
#0 0xdf6ff750 in _thrsys_write ()
#1 0xdf6ff70c in _write ()
#2 0xdf68e730 in _xflsbuf ()
#3 0xdf68f3c8 in _fwrite_unlocked ()
#4 0xdf68f248 in fwrite ()
#5 0x46ac8 in ?? ()
#6 0x45ea4 in ?? ()
.... (no symbols in python so pretty useless)
Here's another backtrace (same program, but from a different place in the code)
#0 0xdf6ff750 in _thrsys_write ()
#1 0xdf6ff70c in _write ()
#2 0xdf68e730 in _xflsbuf ()
#3 0xdf68e8e4 in _fflush_u ()
#4 0xdf68e838 in _fflush_u_iops ()
#5 0xdf6959ac in _fini ()
#6 0xdf7e3b24 in _lib_version ()
#7 0xdf652b00 in _exithandle ()
#8 0xdf695998 in exit ()
#9 0x3af54 in ?? ()
#10 0x3994c in ?? ()
Perhaps this is happening if you break the socket connection while printing to
it (stdout is assigned to the socket so we just use Python print statements to
write to the socket). Unfortunately, we didn't build our python with -g, so
we don't have definitive results as to where this is happening (but our sysadmin
will build a -g version soon).
It appears to be a bug in Solaris 2.3, not python, since this call should never hang.
Has anyone seen this before?
--- Steven T. Kirsch InfoSeek Corporation 2620 Augustine Dr #250 Santa Clara, CA 95054 stk@infoseek.com (408) 982-4463 FAX: (408) 986-1889