Closed Bug 467840 Opened 16 years ago Closed 15 years ago

[crash] saved search (virtual folder) cross acc on group by sort abnormal view [@ nsMsgSearchDBView::FetchLocation]

Categories

(MailNews Core :: Backend, defect)

x86
Windows Vista
defect
Not set
critical

Tracking

(Not tracked)

VERIFIED WORKSFORME

People

(Reporter: ovidiu.grigorescu, Unassigned)

References

Details

(Keywords: crash)

Crash Data

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20081201 Thunderbird/3.0b1 completely new clean install of 3.0bpre completely new profile for test (seam very much a continuation of bug 465011) [I did pass the litmus ssearch stuff, as by that moment it got ok. see notes..] steps: 1gmail imap, and some other pop and imap acc 2 ssearch under the gmail imap account 3 choose lots of folders, most of them .. 4 use simple crit to have many messages (20,63 or 75 here, not goin for 10 or so) 5 gorup by sort (looks ok) 6 go to the inbox or all msg in same gmail imap 7 get back to ssearch: result: *the view shows some missing msg, empty rows (total 75msg, selected 75 with respective blanc ones, so they should show..) *the progress in status goes forever, as if the imap would look for whatever, till a msg is selected and shown .. +!! -twist +/- the group with odd blanc msg and eventually crash (usually shows the correct list on expand and crh after) Crash ID: bp-2fbd2fb7-b08a-4b3f-8016-1e98f2081203 Crash ID: bp-de51d0ff-21fd-4eeb-8195-d4dea2081203 Crash ID: bp-6509e79c-5fb7-4796-9e10-de7882081203 variation 1: [under local folders, only searching in pop folders ..] -it does not show odd rows, but seam correct -it crashes eventually on repeaded +/- on a group .. Crash ID: bp-ad6f9c01-4562-4e32-8cf8-b2c792081203 variation 2: -it looks ok, or not doesn't matter -change sorter up/down from column header (date here) crrs... Crash ID: bp-0d9a2de0-da3a-4398-9c3b-2876c2081203 expected: -same normal view with g by s, no progress bar or other activity, no crash repro: always, precisely like this, not only under gmail imap, under local folders also, only search pop stuff also .. notes: initially all got ok, did not get such. After a while (hours?) or after changes in those folders(?) etc, newmail/ moves/add acc/ change selected folders for search etc [bout all normal things that may go for a day.. litmus stuff] it started to do this. Constantly It seamed to start after I was in that ss with gbys and a new msg just arrived, speculating.. Or I got a crash that I dunno exactly if had to do with this or testing master password create/remove etc. in options, again speculating .. this related or not (master psw vs GbS) crash could be: Crash ID: bp-16799166-b46d-4819-81d7-63f832081203
pasting comment 0 into http://konigsberg.mozilla.org/crash-stats.html bp-de51d0ff-21fd-4eeb-8195-d4dea2081203 bp-6509e79c-5fb7-4796-9e10-de7882081203 bp-ad6f9c01-4562-4e32-8cf8-b2c792081203 Signature nsMsgSearchDBView::FetchLocation(int, nsAString_internal&) UUID 2fbd2fb7-b08a-4b3f-8016-1e98f2081203 Time 2008-12-03 14:51:55-08 Uptime 214 Last Crash 968 seconds before submission Product Thunderbird Version 3.0b1 Build ID 20081201164237 Branch 1.9.1 OS Windows NT OS Version 6.0.6001 Service Pack 1 CPU x86 CPU Info GenuineIntel family 6 model 15 stepping 2 Crash Reason EXCEPTION_ACCESS_VIOLATION Crash Address 0x0 Comments I was in a saved search, cross folder and accounts: -playing with goru by sort and threading, ok -was in group by sort -got a new mail in an account that auto check .. I think switched to that and back to the search or See the new msg in the search directly -clicked on a group head (todey or so) and twisted it i did not really follow the steps so maybe not so clear I'll try to repro 0 thunderbird.exe nsMsgSearchDBView::FetchLocation nsMsgSearchDBView.cpp:185 1 thunderbird.exe nsMsgSearchDBView::GetCellText nsMsgSearchDBView.cpp:175 2 thunderbird.exe nsTreeBodyFrame::PaintText layout/xul/base/src/tree/src/nsTreeBodyFrame.cpp:3609 3 thunderbird.exe nsTreeBodyFrame::PaintCell layout/xul/base/src/tree/src/nsTreeBodyFrame.cpp:3278 4 thunderbird.exe nsTreeBodyFrame::PaintRow layout/xul/base/src/tree/src/nsTreeBodyFrame.cpp:3077 5 thunderbird.exe nsTreeBodyFrame::PaintTreeBody layout/xul/base/src/tree/src/nsTreeBodyFrame.cpp:2880 6 thunderbird.exe PaintTreeBody layout/xul/base/src/tree/src/nsTreeBodyFrame.cpp:2808 the other two crashes um ... bp-0d9a2de0-da3a-4398-9c3b-2876c2081203 [@ nsMsgSearchDBView::GetMsgHdrForViewIndex] bp-16799166-b46d-4819-81d7-63f832081203 [@ 0x656d2d78 - nsMsgDatabase::ForceClosed]
Summary: [crash] saved search (virtual folder) cross acc on group by sort abnormal view → [crash] saved search (virtual folder) cross acc on group by sort abnormal view [@ nsMsgSearchDBView::FetchLocation]
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20081204 Thunderbird/3.0b1 same a. GbyS, leave folder and get back b. groups have missing /blanc rows c. on collapse one group .. Crash ID: bp-67d5ce04-dc0a-4041-8d5e-9e5c02081204 speculation: above crashes seam different, maybe cause the step is sometimes different, collapsing a messy group/change sorter etc or the context is, having pop or imap folders, havin more msg or less But it always starts after a. (with the abnormal Group view (pandora's [m]box) or a very normal one. Q: May be that the blanc or messy GbyS view is one thing and the crashes another?
sorry, no newsgroups in c2. I mean groups in group by sort (today etc)
Status: UNCONFIRMED → NEW
Component: Mail Window Front End → Backend
Ever confirmed: true
Product: Thunderbird → MailNews Core
QA Contact: front-end → backend
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b5pre) Gecko/20090511 Shredder/3.0b3pre WFM recently. seams gone as other tree bugs I've bugged around group by sort and threaded
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WORKSFORME
Thanks ovidiu. last crashes on crash-stats are 3.0b3/20090223121634 so Verified based on crash-stats (and hope we don't see a return in 3.0b3)
Status: RESOLVED → VERIFIED
Crash Signature: [@ nsMsgSearchDBView::FetchLocation]
You need to log in before you can comment on or make changes to this bug.