Description of problem: While condor was connected to the broker a vpn blib caused the condor_startd to crash. Upon investigation the following was found: First-chance exception at 0x7c812afb in condor_startd.exe: Microsoft C++ exception: qpid::TransportFailure at memory location 0x066cf444 The stack frame did not contain condor symbols and I was unable to trace w/o qpid .pdb files. Version-Release number of selected component (if applicable): qpid-cpp-0.7.946106-x.zip How reproducible: 100% Steps to Reproduce: 1. Connect to a broker across vpn (condor_startd) 2. disconnect vpn 3. <crash> Actual results: First-chance exception at 0x7c812afb in condor_startd.exe: Microsoft C++ exception: qpid::TransportFailure at memory location 0x066cf444 Expected results: graceful error propagation and cleanup.
The expected way of communicating loss of transport is the throwing of TransportFailure. I'm assuming you are using the QMF agent API? The question then is whether or not it is supposed to shield you from catching exceptions and convey error status in some other way.
Correct we are using qmf. From what I had seen the exception was not thrown into a code path that I could trap on, which means it was unhandled within a thread proc internal to qpid.