Summary: | assertion failure in KIMAP::ImapInterval::setBegin | ||
---|---|---|---|
Product: | [Frameworks and Libraries] Akonadi | Reporter: | RJVB <rjvbertin> |
Component: | IMAP resource | Assignee: | Christian Mollekopf <chrigi_1> |
Status: | RESOLVED FIXED | ||
Severity: | crash | CC: | dvratil, kdepim-bugs, mollekopf, vkrause, winter |
Priority: | NOR | Keywords: | drkonqi |
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Compiled Sources | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
RJVB
2014-11-03 22:04:17 UTC
this is the exact assert I was trying to get help with today on #kontact. for me it happens in Fedora20 I don't even understand why the ASSERT is active, because I don't build in debug mode ... Anyway, directly upstream of the failing assert is this: ``` C++ //Prepare next chunk m_searchUidIntervall.setBegin(lastUidToSearch + 1); //Or are we already done? if (m_searchUidIntervall.begin() > m_searchUidIntervall.end()) { ``` where m_searchUidIntervall (with double l???) is the ImapInterval class where things go wrong. I think that the "or are we already done" test can never be true (the condition wouldn't pass the assert and ::end returns 0xFFFFFFFF if no end has been defined). But if it should be possible, then the assert is wrong. However, ImapInterval::setBegin is unchanged from kdepimlibs 4.13.3 so I'm at a loss. As a side note: 0xFFFFFFFF is NOT the maximum value an ImapInterval::Id (qint64) can reach ... (and for a signed int 0x7FFFFFF should have been used) !! try reverting 94b64eebb6a88846b221aad810045fecb4173f79 in kdepim-runtime/resources/imap I can try that myself tomorrow, but I'm leaving for the day. What's the official way of doing such a revert? (In reply to Allen Winter from comment #3) > try reverting 94b64eebb6a88846b221aad810045fecb4173f79 in > kdepim-runtime/resources/imap > > I can try that myself tomorrow, but I'm leaving for the day. Anyway, I think that this is what that patch should have looked like (partly): {{{ // Are we already done? if (lastUidToSearch >= m_searchUidIntervall.end()) { m_searchUidIntervall = KIMAP::ImapInterval(); } else { //Prepare next chunk m_searchUidIntervall.setBegin(lastUidToSearch + 1); } }}} Seems I was right: https://git.reviewboard.kde.org/r/120967/ didn't http://commits.kde.org/kdepim-runtime/af03ba2ba2390e2f114caa75d0e997900c456359 and http://commits.kde.org/kdepim-runtime/3e159c9e7bbb34301fa3616c9d6f8671a161a9f4 fix the same thing ? As pointed out by christophe, fixed in af03ba2b. Yes, I was beaten to it (or would have been if this were a race). In a RR I'd have pointed out that it isn't necessary to use a temp. variable, and that the 1st comment is a little off now, but the purpose is clear. Or so it is when you take the trouble of digging up the original commit message ... PS: wouldn't it be of interest to know why this issue was triggered on a GMail imap account, which AFAIK no longer provides Exchange features? (In reply to RJVB from comment #10) > PS: wouldn't it be of interest to know why this issue was triggered on a > GMail imap account, which AFAIK no longer provides Exchange features? The codepath is not exchange specific, it's just that the chunking is not actually used if it's not exchange (one large chunk). It would still hit the error after the first chunk though. The only thing that is a bit strange is that the error should be hit every time, meaning it should have shown up during testing? I'm not really familiar with IMAP UIDs, but what I gather from the original commit message is that they're not necessarily related to the actual number of messages in a folder. Indeed, it's quite suspicious that the error didn't show every time, and that merits someone having a look to understand why, IMHO (I just don't have the resources right now myself). The only logical explanation I see is that somehow the endpoint didn't get set in cases where the assert didn't fail. That could have been by design, but then the question becomes why I got the abort on something that's not supposed to be an exchange server! |