Closed Bug 9398 Opened 27 years ago Closed 27 years ago

[PP]Crash when expanding/collapsing accounts in folder pane (multiple identities)

Categories

(MailNews Core :: Backend, defect, P2)

Product:
MailNews Core
Component:
Backend
Platform:
Other
Linux
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: fenella, Assigned: hyatt)

References

Details

Linux (1999-07-07-08 m8) Summary: When selecting an imap server from the folder pane, apprunner crashes. This only happens on multiple servers (1 pop, 1imap and 1 news server) only Steps to reproduce: 1. Use a prefs50.js file that only consists of 1 pop, 1 imap and 1 news server 2. Open Messenger from the Tasks menu 3. Click on the pop server from the folder pane, it works fine. 4. Click on the news server, it displays the news group folders, no problem 5. But when I click on the Imap server, crash immediately occurs. Note: I try using one imap account, it works fine. And I try a prefs50.js file that consists of 5 multiple IDs ( 2pop, 2 imap, and 1 news server), no crash either. This only happens to the 3 multiple ids only This does not occur on Win_nt and Mac. Reproducible consistently. Here is the stack trace: in nsTableRowGroupFrame::CalculateRowHeights () #1 0x409ca6eb in nsTableRowGroupFrame::Reflow () #2 0x408c0667 in nsContainerFrame::ReflowChild () #3 0x409c1bfc in nsTableFrame::ReflowMappedChildren () #4 0x409c0364 in nsTableFrame::ResizeReflowPass2 () #5 0x409bfd84 in nsTableFrame::Reflow () #6 0x409dc663 in nsTreeFrame::Reflow () #7 0x408c0667 in nsContainerFrame::ReflowChild () #8 0x409c5156 in nsTableOuterFrame::IR_InnerTableReflow () #9 0x409c4b9e in nsTableOuterFrame::IR_TargetIsInnerTableFrame () #10 0x409c4b60 in nsTableOuterFrame::IR_TargetIsChild () #11 0x409c4ac6 in nsTableOuterFrame::IncrementalReflow () #12 0x409c5cf8 in nsTableOuterFrame::Reflow () #13 0x408be5b1 in nsBlockReflowContext::ReflowBlock () #14 0x408ba84d in nsBlockFrame::ReflowBlockFrame () #15 0x408b9e38 in nsBlockFrame::ReflowLine () #16 0x408b9b7e in nsBlockFrame::ReflowDirtyLines () #17 0x408b93c7 in nsBlockFrame::Reflow () #18 0x409d5ad4 in nsBoxFrame::FlowChildAt () #19 0x409d5a26 in nsBoxFrame::FlowChildAt () #20 0x409d5396 in nsBoxFrame::FlowChildren () #21 0x409d506e in nsBoxFrame::Reflow () #22 0x408c0667 in nsContainerFrame::ReflowChild () #23 0x408c8322 in RootFrame::Reflow () #24 0x408c0667 in nsContainerFrame::ReflowChild () #25 0x408e6090 in ViewportFrame::Reflow () #26 0x408c91ec in nsHTMLReflowCommand::Dispatch () #27 0x408dac4a in PresShell::ProcessReflowCommands () #28 0x408d98c6 in PresShell::ExitReflowLock () #29 0x408db790 in PresShell::ContentInserted () #30 0x4069cafc in XULDocumentImpl::ContentInserted () #31 0x40683a3b in RDFElementImpl::InsertChildAt () #32 0x4068b5e3 in RDFGenericBuilderImpl::OnSetAttribute () #33 0x4069f523 in XULDocumentImpl::OnSetAttribute () #34 0x4068296a in RDFElementImpl::SetAttribute () #35 0x40294bb1 in NS_NewScriptDocumentType () #36 0x4030a272 in js_Invoke () #37 0x4030ff0e in js_Interpret () #38 0x4030a2c0 in js_Invoke () #39 0x4030ff0e in js_Interpret () #40 0x4030a2c0 in js_Invoke () #41 0x4030ff0e in js_Interpret () #42 0x4030a2c0 in js_Invoke () #43 0x4030a495 in js_InternalCall () #44 0x402f531d in JS_CallFunctionValue () #45 0x40299960 in nsJSEventListener::HandleEvent () #46 0x408b2a19 in nsEventListenerManager::HandleEvent () #47 0x406854ff in RDFElementImpl::HandleDOMEvent () #48 0x4068555c in RDFElementImpl::HandleDOMEvent () #49 0x4068555c in RDFElementImpl::HandleDOMEvent () #50 0x4068555c in RDFElementImpl::HandleDOMEvent () #51 0x4068555c in RDFElementImpl::HandleDOMEvent () #52 0x4068555c in RDFElementImpl::HandleDOMEvent () #53 0x4068555c in RDFElementImpl::HandleDOMEvent () #54 0x408b46ec in nsEventStateManager::CheckForAndDispatchClick () #55 0x408b3acc in nsEventStateManager::PostHandleEvent () #56 0x408dbfa6 in PresShell::HandleEvent () #57 0x40acc7bd in nsView::HandleEvent () #58 0x40ad3fad in nsViewManager::DispatchEvent () #59 0x40acb26e in _init () #60 0x401a1f26 in nsWidget::DispatchEvent () #61 0x401a1e7d in nsWidget::DispatchWindowEvent () #62 0x401a1fa3 in nsWidget::DispatchMouseEvent () #63 0x401a272b in nsWidget::OnButtonReleaseSignal () #64 0x401a2a6b in nsWidget::ButtonReleaseSignal () #65 0x80c4748 in gtk_window_set_default_size () #66 0x809d5a3 in gtk_signal_connect_object () #67 0x809cc2a in gtk_signal_connect_object () #68 0x809b366 in gtk_selection_data_set () #69 0x80bce90 in gtk_widget_size_request () #70 0x80864e5 in gtk_get_current_event () #71 0x8085a86 in gtk_main_iteration_do () #72 0x80d415b in gdk_input_add () #73 0x80e70e0 in g_list_length () #74 0x80e755b in g_list_length () #75 0x80e7675 in g_main_iteration () #76 0x808559b in gtk_main () #77 0x401977a3 in nsAppShell::Run () #78 0x400fe16a in nsAppShellService::Run () #79 0x8052406 in main ()
May be similar to bug http://bugzilla.mozilla.org/show_bug.cgi?id=9365 although that bug is reported on Win32 and this bug is reported on Linux. I don't want to mark as a duplicate since I am not sure.
Assignee: phil → hyatt
reassigning to hyatt. It looks like a tree/table problem.
Status: NEW → ASSIGNED
Target Milestone: M9
Moving to M9.
*** Bug 9462 has been marked as a duplicate of this bug. ***
Is there any way to get this fixed in M8? Many internal folks are running into this (hard to test IMAP) and I'm afraid many external folks will run into this as well with M8. In general, we've had a large regression with crashing when selecting folders or servers in the folder pane. Thanks.
I have a bunch of other crashes today, too, that are all similarly unreproducible, and some have some overlap of stack trace info (e.g., see /u/scurtis/reflow.txt, which is interesting, and occurred when I selected an IMAP message). I'm not sure if they're the same thing or not, but I'd hate to write them all up independently.
Severity: critical → blocker
big time blocker to testing - can we get a fix for M8?
Summary: [PP]Crash when selecting imap server on multiple identities → [PP]Crash when expanding/collapsing accounts in folder pane (multiple identities)
I'm taking the "imap server" bit out of the summary. There's another stack, nearly identical, at /u/scurtis/newscrash.txt which just occurred when I double-clicked on a news server. The bug that I just duped had it occur when double-clicking the top-level "accounts" line to collapse all accounts.
This class of bugs is making it really hard to solve other bugs since I keep hanging while trying to work on them. If you could look into this for M8, I'd really appreciate this. Sorry I'm just posting my new mantra. There are a bunch of crashes that look similar to this that are making it pretty hard for me to test IMAP. If you could look into it for M8, I'd be very appreciative. I know your swamped, but it could really help us.
I've found that if you resize the main window larger before you do any clicking, you crash a lot less. I'm at least able to do some testing this way.
Priority: P3 → P2
Target Milestone: M9 → M8
Setting p2 for M8
Status: ASSIGNED → RESOLVED
Closed: 27 years ago
Resolution: --- → FIXED
Fixed.
Status: RESOLVED → VERIFIED
Works OK for me using jul12 m8 build on linux rh5.2 with prefs file configuration as described.
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.