I manage my bug mail through a Gmail POP account that I check in Thunderbird. I use that POP account for other things, so I tag the email with "bugzilla" When I try to make a view filter for that "bugzilla" tag, Thunderbird falls into an infinite loop, doing a busy wait. I tracked this down to the loop here: http://lxr.mozilla.org/mozilla1.8/source/mailnews/base/search/src/nsMsgSearchTerm.cpp#1320 The problem is that the keyword value is: "bugzillatag bugzilla" (no quotes). while the m_value is "bugzilla". This input will continuously cause the loop to repeat without ever breaking free. I have verified that most of my messages have only the keyword "bugzilla" so I don't know how this specific message got into this state. The call stack is: #0 0x162406f8 in nsMsgSearchTerm::MatchKeyword at nsMsgSearchTerm.cpp:1320 #1 0x16245f7c in nsMsgSearchOfflineMail::ProcessSearchTerm at nsMsgLocalSearch.cpp:568 #2 0x1624438c in nsMsgSearchBoolExpression::OfflineEvaluate at nsMsgLocalSearch.cpp:169 #3 0x162462c0 in nsMsgSearchOfflineMail::MatchTerms at nsMsgLocalSearch.cpp:630 #4 0x16245064 in nsMsgSearchOfflineMail::MatchTermsForSearch at nsMsgLocalSearch.cpp:363 #5 0x16246700 in nsMsgSearchOfflineMail::Search at nsMsgLocalSearch.cpp:683 #6 0x16241fa4 in nsMsgSearchScopeTerm::TimeSlice at nsMsgSearchTerm.cpp:1545 #7 0x162517fc in nsMsgSearchSession::TimeSliceSerial at nsMsgSearchSession.cpp:701 #8 0x16251564 in nsMsgSearchSession::TimeSlice at nsMsgSearchSession.cpp:665 #9 0x16250c78 in nsMsgSearchSession::TimerCallback at nsMsgSearchSession.cpp:529 #10 0x01399458 in nsTimerImpl::Fire at nsTimerImpl.cpp:394 #11 0x01399714 in handleTimerEvent at nsTimerImpl.cpp:459 #12 0x0139098c in PL_HandleEvent at plevent.c:688 #13 0x013907a4 in PL_ProcessPendingEvents at plevent.c:623 #14 0x01390f78 in _md_EventReceiverProc at plevent.c:1559 I'm not entirely sure what the relationship between m_value and keyword should be. The problem that is causing the infinite loop here is that m_value == 'bugzilla' and keyword == 'bugzillatag bugzilla'. So then keywordLen = 8 (the length of m_value). As we step through the loop the first time, we pass the first if statement. But the matches = (statment) evaluates to false because (keywordLen == strlen(keywordLoc)) = false since keywordLen is 8 and strlen(keywordLoc) = 20. Similarly the incrementation strategy here: startOfKeyword = keywordLoc + keywordLen; keywordLoc = PL_strstr(keyword, keywordLoc + keywordLen + 1); Also fails to work because keywordLen is only 8, and so it increments to the "tag" part of bugzillatag bugzilla. Since "tag bugzilla" will still be found in the original keyword, this will return a valid keywordLoc and the loop will continue slicing up the keyword, continue to find that value in the original keyword and keep looping. It looks to me like you intended to have a space delimited list of keywords, but if that is the case, then why not use something like strtok? At the very least, you must ensure that keywordLen is the length of the first keyword before the space when entering the loop. And you'll need to reset keywordLen as you move through the loop so that it reflects the length of the next keyword that you are considering. But, like I said, I'm sure that a space delimited list was what you were after here. I have also verified that if I change the name of the tag to "bz" the problem goes away.
So what kind of filter should one set up to see this?
I'm sorry, I somehow missed your question. I have tried multiple times to recreate this and failed every time. I no longer have access to that system where the issue first occurred, so I can't re-test it very reliably. From what I recall, it seemed like the issue was something to do with the string matching inside the name of the filter. So, if a filter term was "bugzilla" and the filter name also included "bugzilla" then it seemed to occur. Sorry I can't be more help with this one. I can try setting up the same filter again if you don't have any luck.
Tried creating a custom view called "bugzillatag bugzilla" which would show all messages where Tag contains "bugzilla". Didn't seem to cause any problem.
is the stack enough to more forward? or do we close incomplete?
this code has changed on the trunk, see Bug 433175, which fixed this issue, I believe.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 433175
You need to log in before you can comment on or make changes to this bug.