Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 591420 - C++ clients on windows hang at program end
Summary: C++ clients on windows hang at program end
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Red Hat Enterprise MRG
Classification: Red Hat
Component: qpid-cpp
Version: Development
Hardware: All
OS: Windows
urgent
high
Target Milestone: 1.3
: ---
Assignee: Andrew Stitcher
QA Contact: MRG Quality Engineering
URL:
Whiteboard:
: 576501 (view as bug list)
Depends On:
Blocks: 578396
TreeView+ depends on / blocked
 
Reported: 2010-05-12 08:25 UTC by Gordon Sim
Modified: 2011-08-12 16:20 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-07-15 19:17:10 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Gordon Sim 2010-05-12 08:25:57 UTC
See https://issues.apache.org/jira/browse/QPID-2598

Comment 1 Gordon Sim 2010-05-12 17:17:39 UTC
*** Bug 576501 has been marked as a duplicate of this bug. ***

Comment 2 Pete MacKinnon 2010-05-14 15:08:07 UTC
Hey Gordon,

The grid team feels that this perhaps not exclusive to Windows.  In my plug-in testing on Linux, I see a general problem whenever Condor EXCEPTs in the process space that includes a QMF plug-in component. For example:

#0  0x002fe422 in __kernel_vsyscall ()
#1  0x0095af85 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
#2  0x003cb2b2 in qpid::client::(anonymous namespace)::IOThread::~IOThread() ()
#3  0x007dcdaf in exit () from /lib/libc.so.6
#4  0x080c0f21 in __wrap_exit ()
#5  0x080d63c6 in _EXCEPT_ ()
#6  0x080d9027 in email_open_implementation ()
#7  0x080d8c52 in email_open ()
#8  0x080d9047 in email_admin_open ()
#9  0x080aee12 in daemon::Obituary(int) ()
#10 0x080b103f in Daemons::DefaultReaper(int, int) ()
#11 0x080c592d in DaemonCore::CallReaper(int, char const*, int, int) ()
#12 0x080c5b3c in DaemonCore::HandleProcessExit(int, int) ()
#13 0x080c578f in DaemonCore::HandleDC_SERVICEWAITPIDS(int) ()
#14 0x080ba879 in DaemonCore::Driver() ()
#15 0x080d02ef in main ()

Instead of crashing on the exception, the process is hung on the Qpid dtor. This can have interesting and undesirable behaviour in a grid deployment since our daemons can be dynamically restarted in crash situations.

As Matt says, we have an inalienable right to crash. :-)

Comment 3 Gordon Sim 2010-05-14 15:16:33 UTC
Comment #2 sounds like a different issue and is probably better tracked by its own BZ. We will need more detail on what your program is doing in this case. Is there any signal handlers involved? Are there any other threads in the pstack output?

Comment 4 Gordon Sim 2010-05-28 14:29:04 UTC
Fixed on trunk (949176) and in release repo (bebf319d41b4f4abb9cd3b6cbb3af0183d249825)

Comment 5 Gordon Sim 2010-06-07 08:14:19 UTC
The hang will no longer occur so I am marking this modified. The 'fix' above is perhaps best described as a workaround in the code so I have raised another issue to track resolution of the broader issue in a cleaner fashion (this is not a blocker however): https://bugzilla.redhat.com/show_bug.cgi?id=601094


Note You need to log in before you can comment on or make changes to this bug.