Read only archive ; use https://github.com/JacORB/JacORB/issues for new issues
Bug 759 - Deadlock in GIOPConnection
Summary: Deadlock in GIOPConnection
Status: RESOLVED DUPLICATE of bug 708
Alias: None
Product: JacORB
Classification: Unclassified
Component: ORB (show other bugs)
Version: 2.3.0 beta 2
Hardware: All All
: P4 major
Assignee: Gerald Brose
URL:
Depends on:
Blocks:
 
Reported: 2007-02-09 15:39 UTC by Richard Ridgway
Modified: 2011-01-19 14:40 UTC (History)
2 users (show)

See Also:

Attachments
Patch for Bug 759 (2.50 KB, patch)
2009-01-15 23:49 UTC, Weiqi Gao 		Details | Diff
ChangeLog for Patch for Bug 759 (804 bytes, application/octet-stream)
2009-01-15 23:50 UTC, Weiqi Gao 		Details
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Richard Ridgway 2007-02-09 15:39:03 UTC 
Potential deadlock here due to order of getWriteLock() and synchronized
(connect_sync) calls being swopped between two methods.
I haven't analysed this fully, nor come up with a fix yet, but am working on 
it.

//////////////////////////
ClientGIOPConnection.java
//////////////////////////
    public void closeAllowReopen()
    {
        if (logger.isDebugEnabled())
        {
            logger.debug (this.toString() + ": closeAllowReopen()");
        }

        try
        {
            synchronized (connect_sync)
            {
                getWriteLock();

//////////////////////////
GIOPConnection.java:
//////////////////////////
    private final void sendMessage( MessageOutputStream out )
        throws IOException
    {
        try
        {
            incPendingWrite ();
            getWriteLock();
            if (!transport.is_connected())
            {
                tcs_negotiated = false;

                if (logger.isDebugEnabled())
                {
                    logger.debug(this.toString()
                                 + ": sendMessage() -- opening transport");
                }

                synchronized (connect_sync)
Comment 1 Richard Ridgway 2007-02-09 16:16:20 UTC 
Having looked through the code, there appear to be no other places where this 
sequence occurs. As such, simply moving the getWriteLock() up above the 
synchronized(connect_sync) in ClientGIOPConnection.java will remove the 
possibility of this deadlock without any side effect.

Regards,

Richard
Comment 2 Marc Heide 2007-02-12 08:50:30 UTC 
Did you checked the last correction suggested for Bug 708?
I think this already addresses your problem.
Comment 3 Richard Ridgway 2007-02-19 10:40:21 UTC 
Checking CVS head web interface 19/02/2007 the problem is potentially still 
here. The order of acquiring the two locks is reversed between 
ClientGIOPConnection and GIOPConnection. Whether the situation can still 
(ever?) arise may have changed, but it still makes sense to correct this code.

By the way, the download of cvs daily head snapshot for 19/02 does not contain 
source code.
Comment 4 Weiqi Gao 2009-01-15 23:49:39 UTC 
Created attachment 357 [details]
Patch for Bug 759

This patch fixes a dead lock described in this bug report.
Comment 5 Weiqi Gao 2009-01-15 23:50:29 UTC 
Created attachment 358 [details]
ChangeLog for Patch for Bug 759

Change log for the patch that fixes a dead lock described in this bug report.
Comment 6 Weiqi Gao 2009-01-15 23:54:37 UTC 
I have attached a patch that addresses a dead lock situation stemming from this bug.  The dead lock was observed with a post 2.3.0 build that incorporated the fixes for Bug 708.
Comment 7 Nick Cross 2011-01-19 14:40:37 UTC 
Patch on this ticket looks like similar code has already been applied to CVS partially as a result of 708.

*** This bug has been marked as a duplicate of bug 708 ***