Any way to over-ride the "-q" option to debug a possible race condition?

[Laurence Marks]

As a follow up/continuation, which I have solved how to short circuit
the "-q", I am stuck with trying to track this issue down. Any and all
suggestions welcome.

All I can see is (sometimes) in the output log information that the
ssh connection was closed, nothing else. This is on Northwestern's
(NU) supercomputer, so I don;t have access to the sshd logs. A couple
of the NU tech support people have been looking at this, but so far
they have nothing. They tell me that there is nothing odd in the sshd
logs. There is nothing I can see in the Debug 1 & Debug 3 output to
give any hints (I can send these to anyone who is interested as this
is beyond my pay grade).

Perhaps specific, can anyone give me conditions where ssh can turn
into a zombie? Do multiple and near simultaneous access to config
files matter? Is there anything that can be tweaked in the code to
provide more information about why a connection is closed? Anything
else?

The main ssh on the computer is OpenSSH_5.3p1, OpenSSL 1.0.0-fips 29
Mar 2010 ; this morning I compiled the latest tarball (OpenSSH_6.2p2,
OpenSSL 1.0.0-fips 29 Mar 2010) and this changed nothing
-- 
Professor Laurence Marks
Department of Materials Science and Engineering
Northwestern University
www.numis.northwestern.edu 1-847-491-3996
"Research is to see what everybody else has seen, and to think what
nobody else has thought"
Albert Szent-Gyorgi