mail-api
mail-api copied to clipboard
NPE com.sun.mail.iap.Response com.sun.mail.imap.protocol.IMAPProtocol.readIdleResponse()
Describe the bug
Occasionally I see this in Bugsnag for FairEmail:
java.lang.NullPointerException: Attempt to invoke virtual method 'com.sun.mail.iap.Response com.sun.mail.imap.protocol.IMAPProtocol.readIdleResponse()' on a null object reference
at com.sun.mail.imap.IMAPFolder.handleIdle(SourceFile:3227)
at com.sun.mail.imap.IMAPFolder.idle(SourceFile:3135)
JavaMail version 1.6.4/Android
Unfortunately, checking if the folder is open does not fix the problem :-(
Can you reproduce this error, at least statistically? I believe I have a fix that adds the required locking to prevent the NPE, but I don't want to commit it unless there's a way to test that it's sufficient and safe.
For some reason I haven't seen this exception lately. Possible because of recent changes.
I'm pretty sure this is a real bug, but to avoid adding risk to releases in progress I'm going to defer the fix until later, and hopefully wait until there's a reproducible test case. Please let me know if the situation changes.
I've saved this fix on the branch Idle-NPE-fix-404. It need more testing to make sure it isn't introducing deadlocks before adding it to a future release.
Could this be related?
java.lang.ArrayIndexOutOfBoundsException: message number (0) out of bounds (0)
at com.sun.mail.imap.MessageCache.getMessage(SourceFile:116)
at com.sun.mail.imap.MessageCache.getMessageBySeqnum(SourceFile:148)
at com.sun.mail.imap.IMAPFolder.getMessageBySeqNumber(SourceFile:3999)
at com.sun.mail.imap.IMAPFolder.processFetchResponse(SourceFile:3604)
at com.sun.mail.imap.IMAPFolder.handleResponse(SourceFile:3586)
at com.sun.mail.iap.Protocol.notifyResponseHandlers(SourceFile:245)
at com.sun.mail.imap.protocol.IMAPProtocol.fetchSequenceNumber(SourceFile:2004)
at com.sun.mail.imap.IMAPFolder.getMessageByUID(SourceFile:2598)
It happens rarely in practice.
Probably not, but it's hard to say.
Some servers have been know to notify the client about messages that no longer exist. This feels more like something similar to that. It probably needs another "make sure the server isn't telling us something nonsensical" check.
Should I create a new issue for this?
It is also always:
message number (0) out of bounds (0..n)
Note that 0..n includes 0.
Yes please create a new issue. I f you have a protocol trace, that would be especially useful.