Bug 603204

Summary: vpn reset caused qpid thread to throw an unhandled exception.
Product: Red Hat Enterprise MRG Reporter: Timothy St. Clair <tstclair>
Component: qpid-qmfAssignee: messaging-bugs <messaging-bugs>
Status: NEW --- QA Contact: MRG Quality Engineering <mrgqe-bugs>
Severity: medium Docs Contact:
Priority: low    
Version: betaCC: gsim
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Windows   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 603085    
Bug Blocks:    

Description Timothy St. Clair 2010-06-11 20:40:04 UTC
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.

Comment 1 Gordon Sim 2010-06-12 09:26:03 UTC
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.

Comment 2 Timothy St. Clair 2010-06-12 17:00:05 UTC
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.