[ 
https://issues.apache.org/jira/browse/SSHD-1341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jiachen Lu updated SSHD-1341:
-----------------------------
    Description: 
h2. In a nutshell

I used some static analysis tools to discover a potential deadlock in version 
2.4.0 of mina-sshd. I would like to know if it is a false positive.
 
The related lock objects and trace are shown below.
 
I look forward to the community's assistance in confirming this issue. Thank 
you for your response. If you need more information, please feel free to 
contact me.
 
This deadlock might be similar to SSHD-966
 
h2. Deadlock Pair

Deadlock `synchronized void flush() throws IOException` (Trace 1) and 
`synchronized (encodeLock)` (Trace 2) acquire locks `this` in class 
`ChannelOutputStream` and `encodeLock` in reverse orders.
 
./sshd-core/src/main/java/org/apache/sshd/common/session/helpers/AbstractSession.java
 
{code:java}
912    protected IoWriteFuture doWritePacket(Buffer buffer) throws IOException 
{ 
913        // Synchronize all write requests as needed by the encoding 
algorithm 
914        // and also queue the write request in this synchronized block to 
ensure 
915        // packets are sent in the correct order 
916  >      synchronized (encodeLock) { 
917            Buffer packet = resolveOutputPacket(buffer); 
918            IoSession networkSession = getIoSession(); 
919            return networkSession.writePacket(packet); 
920        }
921    }{code}
 
 
 
Deadlock `synchronized void flush() throws IOException` (Trace 1) and 
`synchronized (encodeLock)` (Trace 2) acquire locks `this` in class 
`ChannelOutputStream` and `encodeLock` in reverse orders.
 
./sshd-core/src/main/java/org/apache/sshd/server/forward/TcpipServerChannel.java
{code:java}
203            public void messageReceived(IoSession session, Readable message) 
throws Exception {
204                if (isClosing()) {
205                    if (debugEnabled) {
206                        log.debug("doInit({}) Ignoring write to channel in 
CLOSING state", TcpipServerChannel.this);
207                    }
208                } else {
209                    Buffer buffer = new ByteArrayBuffer(message.available() 
+ Long.SIZE, false);
210                    buffer.putBuffer(message);
211                    out.write(buffer.array(), buffer.rpos(), 
buffer.available());
212 >                  out.flush();
213                }
214            } {code}
h2. Trace
h3. Trace1

  !image-2024-06-16-21-16-19-706.png!
h3.  
h3. Trace2 !image-2024-06-16-21-16-41-229.png!

 

  was:
h2. In a nutshell

I used some static analysis tools to discover a potential deadlock in version 
2.4.0 of mina-sshd. I would like to know if it is a false positive.
 
The related lock objects and trace are shown below.
 
I look forward to the community's assistance in confirming this issue. Thank 
you for your response. If you need more information, please feel free to 
contact me.
 
This deadlock might be similar to SSHD-966
 
h2. Deadlock Pair

Deadlock `synchronized void flush() throws IOException` (Trace 1) and 
`synchronized (encodeLock)` (Trace 2) acquire locks `this` in class 
`ChannelOutputStream` and `encodeLock` in reverse orders.
 
./sshd-core/src/main/java/org/apache/sshd/common/session/helpers/AbstractSession.java
 
{code:java}
912    protected IoWriteFuture doWritePacket(Buffer buffer) throws IOException 
{ 
913        // Synchronize all write requests as needed by the encoding 
algorithm 
914        // and also queue the write request in this synchronized block to 
ensure 
915        // packets are sent in the correct order 
916        synchronized (encodeLock) { 
917            Buffer packet = resolveOutputPacket(buffer); 
918            IoSession networkSession = getIoSession(); 
919            return networkSession.writePacket(packet); 
920        }
921    }{code}
 
 
 
Deadlock `synchronized void flush() throws IOException` (Trace 1) and 
`synchronized (encodeLock)` (Trace 2) acquire locks `this` in class 
`ChannelOutputStream` and `encodeLock` in reverse orders.
 
./sshd-core/src/main/java/org/apache/sshd/server/forward/TcpipServerChannel.java
{code:java}
203            public void messageReceived(IoSession session, Readable message) 
throws Exception {
204                if (isClosing()) {
205                    if (debugEnabled) {
206                        log.debug("doInit({}) Ignoring write to channel in 
CLOSING state", TcpipServerChannel.this);
207                    }
208                } else {
209                    Buffer buffer = new ByteArrayBuffer(message.available() 
+ Long.SIZE, false);
210                    buffer.putBuffer(message);
211                    out.write(buffer.array(), buffer.rpos(), 
buffer.available());
212 >                  out.flush();
213                }
214            } {code}
h2. Trace
h3. Trace1

  !image-2024-06-16-21-16-19-706.png!
h3.  
h3. Trace2 !image-2024-06-16-21-16-41-229.png!

 


> Deadlock in old version of SSHD
> -------------------------------
>
>                 Key: SSHD-1341
>                 URL: https://issues.apache.org/jira/browse/SSHD-1341
>             Project: MINA SSHD
>          Issue Type: Question
>    Affects Versions: 2.4.0
>            Reporter: Jiachen Lu
>            Priority: Minor
>         Attachments: image-2024-06-16-21-16-19-706.png, 
> image-2024-06-16-21-16-41-229.png
>
>
> h2. In a nutshell
> I used some static analysis tools to discover a potential deadlock in version 
> 2.4.0 of mina-sshd. I would like to know if it is a false positive.
>  
> The related lock objects and trace are shown below.
>  
> I look forward to the community's assistance in confirming this issue. Thank 
> you for your response. If you need more information, please feel free to 
> contact me.
>  
> This deadlock might be similar to SSHD-966
>  
> h2. Deadlock Pair
> Deadlock `synchronized void flush() throws IOException` (Trace 1) and 
> `synchronized (encodeLock)` (Trace 2) acquire locks `this` in class 
> `ChannelOutputStream` and `encodeLock` in reverse orders.
>  
> ./sshd-core/src/main/java/org/apache/sshd/common/session/helpers/AbstractSession.java
>  
> {code:java}
> 912    protected IoWriteFuture doWritePacket(Buffer buffer) throws 
> IOException { 
> 913        // Synchronize all write requests as needed by the encoding 
> algorithm 
> 914        // and also queue the write request in this synchronized block to 
> ensure 
> 915        // packets are sent in the correct order 
> 916  >      synchronized (encodeLock) { 
> 917            Buffer packet = resolveOutputPacket(buffer); 
> 918            IoSession networkSession = getIoSession(); 
> 919            return networkSession.writePacket(packet); 
> 920        }
> 921    }{code}
>  
>  
>  
> Deadlock `synchronized void flush() throws IOException` (Trace 1) and 
> `synchronized (encodeLock)` (Trace 2) acquire locks `this` in class 
> `ChannelOutputStream` and `encodeLock` in reverse orders.
>  
> ./sshd-core/src/main/java/org/apache/sshd/server/forward/TcpipServerChannel.java
> {code:java}
> 203            public void messageReceived(IoSession session, Readable 
> message) throws Exception {
> 204                if (isClosing()) {
> 205                    if (debugEnabled) {
> 206                        log.debug("doInit({}) Ignoring write to channel in 
> CLOSING state", TcpipServerChannel.this);
> 207                    }
> 208                } else {
> 209                    Buffer buffer = new 
> ByteArrayBuffer(message.available() + Long.SIZE, false);
> 210                    buffer.putBuffer(message);
> 211                    out.write(buffer.array(), buffer.rpos(), 
> buffer.available());
> 212 >                  out.flush();
> 213                }
> 214            } {code}
> h2. Trace
> h3. Trace1
>   !image-2024-06-16-21-16-19-706.png!
> h3.  
> h3. Trace2 !image-2024-06-16-21-16-41-229.png!
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org

Reply via email to