Avoid OutOfMemoryError (crash) in XMPPTCPConnection

Smack Smack Support
1

Hi,

We are using Smack 4.1.x releases and every day we are receiving a few crash reports like the one below.

java.lang.OutOfMemoryError

java.lang.Object[] of length 2147483647 exceeds the VM limit

I believe it’s because of the processHandledCount method in XMPPTCPConnection class:

https://github.com/igniterealtime/Smack/blob/92968e16304a3a4c138010580c46d2e7c8a 00743/smack-tcp/src/main/java/org/jivesoftware/smack/tcp/XMPPTCPConnection.java# L1792

The crash may happen because of two reasons:

As you may know, the SMUtils.calculateDelta may return value bigger than Integer.MAX_VALUE in case if serverHandledStanzasCount is bigger than handledCount.

I’m not entirely sure what should be the best way to fix the issue but I believe it should be enough to get rid of initial ArrayList capacity at all or use the handledCount as initial capacity if we really want to avoid unnecessary calls to increase ArrayList capacity during the iteration in the next steps. What do you think about it?

2

If I’m not mistaken and understood you correctly, then what you describe can only happen if the server reports an unlikely big handled count: 2147483647. This would mean that thare more then 2 billion unacked stanzas. And even if the reported handled count would be realistic, then deferring the ArrayList resizing would cause the same issue.

As you may know, the SMUtils.calculateDelta may return value bigger than Integer.MAX_VALUE in case if serverHandledStanzasCount is bigger thanhandledCount.

Right, and this is an invalid non-recoverable state.

3

Created [SMACK-721] Report illegal Stream Management states to avoid OOM Exception - IgniteRealtime JIRA

4

I wasn’t sure if the server reports too big handled count or if it returns the correct value but the handledCount is 0 in some cases (maybe some race condition where handledCount is being sometimes set to 0 from another place?) as I wasn’t able to reproduce the issue by myself, I just saw many crash reports from this place. Anyway, the solution which you described in the JIRA’s ticket will avoid OOM crash, thanks.