Read only archive ; use https://github.com/JacORB/JacORB/issues for new issues

Bug 759

Summary: Deadlock in GIOPConnection
Product: JacORB Reporter: Richard Ridgway <Richard_Ridgway>
Component: ORBAssignee: Gerald Brose <gerald.brose>
Status: RESOLVED DUPLICATE    
Severity: major CC: Richard_Ridgway, rnc
Priority: P4    
Version: 2.3.0 beta 2   
Hardware: All   
OS: All   
Attachments: Patch for Bug 759
ChangeLog for Patch for Bug 759

Description Richard Ridgway 2007-02-09 15:39:03 CET
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 CET
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 CET
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 CET
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 CET
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 CET
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 CET
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 CET
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 ***