Closed Bug 76933 Opened 24 years ago Closed 23 years ago

[BiDi] Browser doesn't start with a new profile at the first time

Categories

(Core :: Internationalization, defect)

Product:
Core
Component:
Internationalization
Platform:
Other
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED DUPLICATE of bug 79179
Milestone:
mozilla0.9.1

People

(Reporter: ji, Assigned: ftang)

References

Details

(Keywords: crash, Whiteboard: need code review from heikki and nisheeth 2001-05-08 03:04 -)

Attachments

(4 files)

proposed fix. hold nsIViewManager in the struct by nsCOMPtr to guarantee it exist.
910 bytes, patch
Details | Diff | Splinter Review
the bloat/leak log without patch
82.15 KB, text/plain
Details
the bloat/leak log with patch
81.72 KB, text/plain
Details
Modified patch: gets rid of earlier bandaid in favor of Frank's bandaid
1.48 KB, patch
Details | Diff | Splinter Review
Build: 04/19 bidi build OS: RH 6.2J Browser doesn't come up with a new created profile at the first time. Steps to reproduce: 1. Run ./mozilla 2. Create a new profile 3. Select the new created profile and click on Start Mozilla. The browser doesn't come up. There are processes running at background. Kill the processes and restart mozilla with the same profile, browser will start .
I can reproduce here too.
QA Contact: andreasb → ylong
Yuying, are you also using Linux?
Yes, Linux RedHat-Ja - same as Xianglan's machine.
Summary: Browser doesn't start with a new profile at the first time → [BiDi] Browser doesn't start with a new profile at the first time
Compared the bidi and non-bidi build that Erik has delivered to us on 04/24. This only happens on bidi build.
But for non-Bidi build that same build as Xianglan tested, I got a whole blank page when I first run ./mozilla or ./mozilla -porfilemanage - Note not even get into profile manager window. Then it does start with a new profile name at the first time.
Blocks: 75982
Cannot reproduce on WinME with Window build. It looks like a Linux only problem.
In my Linux, the console show several of the following message while it *hang* Gdk-Message: Got event for unknown window: 0x2c0000e
I got two kind of problems on Linux. Crash or hang without crash.
Here is a stack trace that I get on Linux when I run with -ProfileManager, create a new profile, and click Finish to create the profile: (gdb) bt #0 0x42fecccd in ?? () #1 0x41b11527 in PresShell::GetViewManager (this=0x43165138, aResult=0xbfffc770) at nsPresShell.cpp:1719 #2 0x41c8ce4d in ReflowEvent::HandleEvent (this=0x431b5790) at nsPresShell.cpp:5607 #3 0x41b1f821 in HandlePLEvent (aEvent=0x431b5790) at nsPresShell.cpp:5624 #4 0x4012b0fb in PL_HandleEvent (self=0x431b5790) at plevent.c:588 #5 0x4012af0c in PL_ProcessPendingEvents (self=0x42fb8f20) at plevent.c:518 #6 0x4012d18c in nsEventQueueImpl::ProcessPendingEvents (this=0x42f6b570) at nsEventQueue.cpp:374 #7 0x4112f190 in nsAppShell::Spindown (this=0x42fe32e0) at nsAppShell.cpp:325 #8 0x421df6fa in nsXULWindow::ShowModal (this=0x42fccb80) at nsXULWindow.cpp:280 #9 0x421ec30e in nsWebShellWindow::ShowModal (this=0x42fccb80) at nsWebShellWindow.cpp:1081 #10 0x421dd76d in nsContentTreeOwner::ShowAsModal (this=0x42fcf2e0) at nsContentTreeOwner.cpp:392 #11 0x41e86024 in nsWindowWatcher::OpenWindowJS (this=0x8383be0, aParent=0x42d0bebc, aUrl=0x42fcfb60 "chrome://communicator/content/profile/createProfileWizard.xul", aName=0x42fb17d8 "CPW", aFeatures=0x42f7ac68 "chrome,modal=yes,titlebar=yes", aDialog=1, argc=0, argv=0x42fd0678, _retval=0xbfffcf28) at nsWindowWatcher.cpp:653 #12 0x4187d5c1 in GlobalWindowImpl::OpenInternal (this=0x42d0beb8, cx=0x42d3ded0, argv=0x42fd066c, argc=3, aDialog=1, aReturn=0xbfffcfb8) at nsGlobalWindow.cpp:3046 #13 0x41878eb1 in GlobalWindowImpl::OpenDialog (this=0x42d0beb8, cx=0x42d3ded0, argv=0x42fd066c, argc=3, aReturn=0xbfffcfb8) at nsGlobalWindow.cpp:2126 #14 0x41866c0e in WindowInternalOpenDialog (cx=0x42d3ded0, obj=0x82f1ce0, argc=3, argv=0x42fd066c, rval=0xbfffd074) at nsJSWindow.cpp:4419 #15 0x402091f4 in js_Invoke (cx=0x42d3ded0, argc=3, flags=0) at jsinterp.c:813 #16 0x4021fd87 in js_Interpret (cx=0x42d3ded0, result=0xbfffd920) at jsinterp.c:2706 #17 0x4020926d in js_Invoke (cx=0x42d3ded0, argc=1, flags=2) at jsinterp.c:830 #18 0x402095cc in js_InternalInvoke (cx=0x42d3ded0, obj=0x42ddd598, fval=1121837216, flags=0, argc=1, argv=0xbfffdbd4, rval=0xbfffdaa4) at jsinterp.c:902 #19 0x401d6287 in JS_CallFunctionValue (cx=0x42d3ded0, obj=0x42ddd598, fval=1121837216, argc=1, argv=0xbfffdbd4, rval=0xbfffdaa4) at jsapi.c:3334 #20 0x41858e1d in nsJSContext::CallEventHandler (this=0x42d0c4e0, aTarget=0x42ddd598, aHandler=0x42dde0a0, argc=1, argv=0xbfffdbd4, aBoolResult=0xbfffdb24, aReverseReturnResult=0) at nsJSEnvironment.cpp:939 #21 0x418b054c in nsJSEventListener::HandleEvent (this=0x42d80c70, aEvent=0x42fcc62c) at nsJSEventListener.cpp:154 #22 0x413fe609 in nsEventListenerManager::HandleEventSubType (this=0x42d80c38, aListenerStruct=0x42d80c98, aDOMEvent=0x42fcc62c, aCurrentTarget=0x42d80be8, aSubType=8, aPhaseFlags=7) at nsEventListenerManager.cpp:1035 #23 0x41401865 in nsEventListenerManager::HandleEvent (this=0x42d80c38, aPresContext=0x42d25330, aEvent=0xbfffe834, aDOMEvent=0xbfffe6a0, aCurrentTarget=0x42d80be8, aFlags=7, aEventStatus=0xbfffe87c) at nsEventListenerManager.cpp:1955 #24 0x41546e2c in nsXULElement::HandleDOMEvent (this=0x42d80be0, aPresContext=0x42d25330, aEvent=0xbfffe834, aDOMEvent=0xbfffe6a0, aFlags=1, aEventStatus=0xbfffe87c) at nsXULElement.cpp:3674 #25 0x41b1f701 in PresShell::HandleDOMEventWithTarget (this=0x42d5f680, aTargetContent=0x42d80be0, aEvent=0xbfffe834, aStatus=0xbfffe87c) at nsPresShell.cpp:5545 #26 0x41c0a563 in nsButtonBoxFrame::MouseClicked (this=0x42fb5aec, aPresContext=0x42d25330, aEvent=0xbfffead0) at nsButtonBoxFrame.cpp:180 #27 0x41c0a002 in nsButtonBoxFrame::HandleEvent (this=0x42fb5aec, aPresContext=0x42d25330, aEvent=0xbfffead0, aEventStatus=0xbfffef04) at nsButtonBoxFrame.cpp:124 #28 0x41b1f577 in PresShell::HandleEventInternal (this=0x42d5f680, aEvent=0xbfffead0, aView=0x0, aFlags=1, aStatus=0xbfffef04) at nsPresShell.cpp:5513 #29 0x41b1f2d0 in PresShell::HandleEventWithTarget (this=0x42d5f680, aEvent=0xbfffead0, aFrame=0x42fb5aec, aContent=0x42d80be0, aFlags=1, aStatus=0xbfffef04) at nsPresShell.cpp:5471 #30 0x4140c361 in nsEventStateManager::CheckForAndDispatchClick (this=0x42d77cf8, aPresContext=0x42d25330, aEvent=0xbffff008, aStatus=0xbfffef04) at nsEventStateManager.cpp:2349 #31 0x41409950 in nsEventStateManager::PostHandleEvent (this=0x42d77cf8, aPresContext=0x42d25330, aEvent=0xbffff008, aTargetFrame=0x42fb5aec, aStatus=0xbfffef04, aView=0x42f30ab0) at nsEventStateManager.cpp:1448 #32 0x41b1f5cf in PresShell::HandleEventInternal (this=0x42d5f680, aEvent=0xbffff008, aView=0x42f30ab0, aFlags=1, aStatus=0xbfffef04) at nsPresShell.cpp:5518 #33 0x41b1eff8 in PresShell::HandleEvent (this=0x42d5f680, aView=0x42f30ab0, aEvent=0xbffff008, aEventStatus=0xbfffef04, aForceHandle=1, aHandled=@0xbfffeea8) at nsPresShell.cpp:5425 #34 0x410cdcbb in nsView::HandleEvent (this=0x42f30ab0, event=0xbffff008, aEventFlags=28, aStatus=0xbfffef04, aForceHandle=1, aHandled=@0xbfffeea8) at nsView.cpp:364 #35 0x410d9d55 in nsViewManager::DispatchEvent (this=0x42d5e528, aEvent=0xbffff008, aStatus=0xbfffef04) at nsViewManager.cpp:2053 #36 0x410cd364 in HandleEvent (aEvent=0xbffff008) at nsView.cpp:67 #37 0x41143168 in nsWidget::DispatchEvent (this=0x42f30b38, aEvent=0xbffff008, aStatus=@0xbfffefa0) at nsWidget.cpp:1488 #38 0x41142dac in nsWidget::DispatchWindowEvent (this=0x42f30b38, event=0xbffff008) at nsWidget.cpp:1379 #39 0x41143220 in nsWidget::DispatchMouseEvent (this=0x42f30b38, aEvent=@0xbffff008) at nsWidget.cpp:1515 #40 0x41144595 in nsWidget::OnButtonReleaseSignal (this=0x42f30b38, aGdkButtonEvent=0x844cd80) at nsWidget.cpp:2064 #41 0x4114af00 in nsWindow::HandleGDKEvent (this=0x42f30b38, event=0x844cd80) at nsWindow.cpp:1465 #42 0x4113a781 in dispatch_superwin_event (event=0x844cd80, window=0x42f30b38) at nsGtkEventHandler.cpp:1022 #43 0x4113a324 in handle_gdk_event (event=0x844cd80, data=0x0) at nsGtkEventHandler.cpp:843 #44 0x406e30fb in gdk_event_dispatch () from /usr/lib/libgdk-1.2.so.0 #45 0x4070da86 in g_main_dispatch () from /usr/lib/libglib-1.2.so.0 #46 0x4070e041 in g_main_iterate () from /usr/lib/libglib-1.2.so.0 #47 0x4070e1e1 in g_main_run () from /usr/lib/libglib-1.2.so.0 #48 0x4063a7a9 in gtk_main () from /usr/lib/libgtk-1.2.so.0 #49 0x4112f20a in nsAppShell::Run (this=0x80adb00) at nsAppShell.cpp:360 #50 0x421e8014 in nsAppShellService::Run (this=0x8359448) at nsAppShellService.cpp:407 #51 0x420e867a in nsProfile::LoadDefaultProfileDir (this=0x8383d88, profileURLStr=@0xbffff5e8) at nsProfile.cpp:489 #52 0x420e7c77 in nsProfile::StartupWithArgs (this=0x8383d88, cmdLineArgs=0x8359740) at nsProfile.cpp:378 #53 0x8053a4a in InitializeProfileService (cmdLineArgs=0x8359740) at nsAppRunner.cpp:778 #54 0x8054848 in main1 (argc=2, argv=0xbffff954, nativeApp=0x0) at nsAppRunner.cpp:970 #55 0x805588a in main (argc=2, argv=0xbffff954) at nsAppRunner.cpp:1306 #56 0x4031dcb3 in __libc_start_main (main=0x805569c <main>, argc=2, argv=0xbffff954, init=0x804f8f4 <_init>, fini=0x806119c <_fini>, rtld_fini=0x4000a350 <_dl_fini>, stack_end=0xbffff94c) at ../sysdeps/generic/libc-start.c:78 (gdb)
I did some more debugging, and found that PresShell is holding on to a pointer to an nsViewManager that is being deleted before someone calls GetViewManager on PresShell. Don't know if this is a refcount problem, or something else.
This is sounding more and more similar to 76939, 71515 and other bugs (cross-referenced in 71515) which involve events being fired to a window while it's being destroyed Did hyatt's fix for 76495 make any difference to 76939? If so, it would be interesting to watch mIsDocumentGone in PresShell::GetViewManager to see if something similar would help with this bug.
In the debugger, I had a look at mIsDocumentGone in GetViewManager, and it was zero. So, no luck there (so far). I haven't been able to determine whether hyatt's fix helps 76939 since that bug is not always reproducible to begin with.
erik resign. reassign all his bug to ftang for now.
Assignee: erik → ftang
I am working on this one.
Status: NEW → ASSIGNED
the reason we need to access to the PresShell::GetViewManager is because ReflowEvent::HandleEvent call that. and look at mozilla/layout/html/base/src/nsPresShell.cpp 648 void HandleEvent() { 5649 nsCOMPtr<nsIPresShell> presShell = do_QueryReferent(mPresShell); 5650 if (presShell) { 5651 #ifdef DEBUG 5652 if (VERIFY_REFLOW_NOISY_RC & gVerifyReflowFlags) { 5653 dr 3.390 printf("\n*** Handling reflow event: PresShell=%p, event=%p\n", (void*)presShell.get(), (void*)this); 5654 nisheeth 3.279 } 5655 #endif 5656 // XXX Statically cast the pres shell pointer so that we can call 5657 // protected methods on the pres shell. (the ReflowEvent struct 5658 // is a friend of the PresShell class) 5659 PresShell* ps = NS_REINTERPRET_CAST(PresShell*, presShell.get()); 5660 PRBool isBatching; 5661 ps->SetReflowEventStatus(PR_FALSE); 5662 ps->GetReflowBatchingStatus(&isBatching); 5663 nisheeth 3.351 if (!isBatching) { 5664 nsCOMPtr<nsIViewManager> viewManager; 5665 // Set a kung fu death grip on the view manager associated with the pres shell 5666 // before processing that pres shell's reflow commands. Fixes bug 54868. 5667 presShell-> GetViewManager(getter_AddRefs(viewManager)); 5668 ps->ProcessReflowCommands(PR_TRUE); 5669 5670 // Now, explicitly release the pres shell before the view manager 5671 presShell = nsnull; 5672 viewManager = nsnull; 5673 } 5674 nisheeth 3.279 } 5675 It looks like a hack nisheeth put in. ask nisheeth to help nisheeth- currently we hit this in the bidi build on linux. This currently block us to land IBMBIDI as default on. Please hlep us to remove this one. the mViewManager of PresShell is already destory when we call the PresShell::GetViewManager. Do you need to check some state before call it ?
Keywords: crash
Target Milestone: --- → mozilla0.9.1
to see this problem- come to my cube or run ./configure --enable-bidi on linux before you build and run ./mozilla --profilemanager
ok 5693 ReflowEvent::ReflowEvent(nsIPresShell* aPresShell) 5694 { 5695 nisheeth 3.279 NS_ASSERTION(aPresShell, "Null parameters!"); 5696 5697 mPresShell = getter_AddRefs(NS_GetWeakReference(aPresShell)); 5698 5699 PL_InitEvent(this, aPresShell, 5700 (PLHandleEventProc) ::HandlePLEvent, 5701 (PLDestroyEventProc) ::DestroyPLEvent); 5702 } put it into a seperate thread by calling PL_InitEvent I think that cause the problem since we didn't hold a reference to the mPresShell->mViewManager here. The DocumentViewer could destory view manager in the main thread. I think the right thing to do is to hold a reference to viewmanager in the ReflowEvent as nsCOMPtr<nsIViewManager> and it will be destroy in ~ReflowEvent. In this way, we guarantee when the mPresShell call the GetViewManger, it is still alive.
sorry the line + printf("GetViewManager %p\n", *aResult); in the patch should be removed.
Whiteboard: need code review from heikki and nisheeth 2001-05-08 03:04 -
nisheeth said it migth be cause bo strong reference to nsIPrefShell. However, this does not make sense since most our changes are xp and we cannot reproduce this on window.
we probably need to break at PresShell::AddRef to see who add ref to it.
If I add the previous patch and set break point at ~PresShell. it will break at (gdb) bt #0 PresShell::~PresShell (this=0x83bf720, __in_chrg=3) at nsPresShell.cpp:1423 #1 0x418c8864 in PresShell::Release (this=0x83bf720) at nsPresShell.cpp:1377 #2 0x41c29cd6 in nsView::HandleEvent (this=0x83bf330, event=0xbfffc558, aEventFlags=28, aStatus=0xbfffc454, aForceHandle=1, aHandled=@0xbfffc3f8) at nsView.cpp:377 #3 0x41c35da5 in nsViewManager::DispatchEvent (this=0x83bf1e0, aEvent= 0xbfffc558, aStatus=0xbfffc454) at nsViewManager.cpp:2054 #4 0x41c29364 in HandleEvent (aEvent=0xbfffc558) at nsView.cpp:67 #5 0x40989348 in nsWidget::DispatchEvent (this=0x83bf398, aEvent=0xbfffc558, aStatus=@0xbfffc4f0) at nsWidget.cpp:1488 #6 0x40988f8c in nsWidget::DispatchWindowEvent (this=0x83bf398, event= 0xbfffc558) at nsWidget.cpp:1379 #7 0x40989400 in nsWidget::DispatchMouseEvent (this=0x83bf398, aEvent= @0xbfffc558) at nsWidget.cpp:1515 #8 0x4098a775 in nsWidget::OnButtonReleaseSignal (this=0x83bf398, aGdkButtonEvent=0x818f394) at nsWidget.cpp:2064 #9 0x40991150 in nsWindow::HandleGDKEvent (this=0x83bf398, event=0x818f394) at nsWindow.cpp:1474 #10 0x40980961 in dispatch_superwin_event (event=0x818f394, window=0x83bf398) at nsGtkEventHandler.cpp:1022 #11 0x40980548 in handle_gdk_event (event=0x818f394, data=0x0) at nsGtkEventHandler.cpp:856 #12 0x40b05ab2 in ?? () from /usr/lib/libgdk-1.2.so.0 #13 0x40b322c6 in ?? () from /usr/lib/libglib-1.2.so.0 #14 0x40b32801 in ?? () from /usr/lib/libglib-1.2.so.0 #15 0x40b328a3 in ?? () from /usr/lib/libglib-1.2.so.0 #16 0x40975387 in nsAppShell::DispatchNativeEvent (this=0x83b6450, aRealEvent=0, aEvent=0x0) at nsAppShell.cpp:397 #17 0x408fa5d7 in ?? () from /builds2/ftang/bidi/mozilla/dist/bin/components/ libnsappshell.so #18 0x4090730e in ?? () from /builds2/ftang/bidi/mozilla/dist/bin/components/ libnsappshell.so #19 0x408f876d in ?? () from /builds2/ftang/bidi/mozilla/dist/bin/components/ libnsappshell.so #20 0x405a47d4 in ?? () from /builds2/ftang/bidi/mozilla/dist/bin/components/ libembedcomponents.so #21 0x40686b01 in ?? () from /builds2/ftang/bidi/mozilla/dist/bin/libjsdom.so #22 0x40682411 in ?? () from /builds2/ftang/bidi/mozilla/dist/bin/libjsdom.so #23 0x4067016e in ?? () from /builds2/ftang/bidi/mozilla/dist/bin/libjsdom.so #24 0x402092b4 in js_Invoke (cx=0x81e22f8, argc=3, flags=0) at jsinterp.c:813 #25 0x4021ff89 in js_Interpret (cx=0x81e22f8, result=0xbfffd940) at jsinterp.c:2708 #26 0x4020932d in js_Invoke (cx=0x81e22f8, argc=1, flags=2) at jsinterp.c:830 #27 0x4020968c in js_InternalInvoke (cx=0x81e22f8, obj=0x824cbc0, fval=137708704, flags=0, argc=1, argv=0xbfffdbf4, rval=0xbfffdac4) at jsinterp.c:902 #28 0x401d62c7 in JS_CallFunctionValue (cx=0x81e22f8, obj=0x824cbc0, fval= 137708704, argc=1, argv=0xbfffdbf4, rval=0xbfffdac4) at jsapi.c:3337 #29 0x4066237d in ?? () from /builds2/ftang/bidi/mozilla/dist/bin/libjsdom.so #30 0x406b996c in ?? () from /builds2/ftang/bidi/mozilla/dist/bin/libjsdom.so #31 0x412c2249 in nsEventListenerManager::HandleEventSubType (this=0x82396a0, aListenerStruct=0x8239780, aDOMEvent=0x83a7174, aCurrentTarget=0x8239650, aSubType=8, aPhaseFlags=7) at nsEventListenerManager.cpp:1063 #32 0x412c54a5 in nsEventListenerManager::HandleEvent (this=0x82396a0, aPresContext=0x81c9a18, aEvent=0xbfffe854, aDOMEvent=0xbfffe6c0, aCurrentTarget= 0x8239650, aFlags=7, aEventStatus=0xbfffe89c) at nsEventListenerManager.cpp:1983 #33 0x4140db2c in nsXULElement::HandleDOMEvent (this=0x8239648, aPresContext= 0x81c9a18, aEvent=0xbfffe854, aDOMEvent=0xbfffe6c0, aFlags=1, aEventStatus= 0xbfffe89c) at nsXULElement.cpp:3675 #34 0x418d8381 in PresShell::HandleDOMEventWithTarget (this=0x82164b0, aTargetContent=0x8239648, aEvent=0xbfffe854, aStatus=0xbfffe89c) at nsPresShell.cpp:5605 #35 0x419c33a3 in nsButtonBoxFrame::MouseClicked (this=0x83854fc, aPresContext= 0x81c9a18, aEvent=0xbfffeaf0) at nsButtonBoxFrame.cpp:180 #36 0x419c2e42 in nsButtonBoxFrame::HandleEvent (this=0x83854fc, aPresContext= 0x81c9a18, aEvent=0xbfffeaf0, aEventStatus=0xbfffef24) at nsButtonBoxFrame.cpp:124 #37 0x418d81f7 in PresShell::HandleEventInternal (this=0x82164b0, aEvent= 0xbfffeaf0, aView=0#37 0x418d81f7 in PresShell::HandleEventInternal (this= 0x82164b0, aEvent=0xbfffeaf0, aView=0x0, aFlags=1, aStatus=0xbfffef24) at nsPresShell.cpp:5573 #38 0x418d7f50 in PresShell::HandleEventWithTarget (this=0x82164b0, aEvent= 0xbfffeaf0, aFrame=0x83854fc, aContent=0x8239648, aFlags=1, aStatus=0xbfffef24) at nsPresShell.cpp:5531 #39 0x412cffa1 in nsEventStateManager::CheckForAndDispatchClick (this=0x8298af8, aPresContext=0x81c9a18, aEvent=0xbffff028, aStatus=0xbfffef24) at nsEventStateManager.cpp:2349 #40 0x412cd590 in nsEventStateManager::PostHandleEvent (this=0x8298af8, aPresContext=0x81c9a18, aEvent=0xbffff028, aTargetFrame=0x83854fc, aStatus= 0xbfffef24, aView=0x82f7cb8) at nsEventStateManager.cpp:1448 #41 0x418d824f in PresShell::HandleEventInternal (this=0x82164b0, aEvent= 0xbffff028, aView=0x82f7cb8, aFlags=1, aStatus=0xbfffef24) at nsPresShell.cpp:5578 #42 0x418d7c78 in PresShell::HandleEvent (this=0x82164b0, aView=0x82f7cb8, aEvent=0xbffff028, aEventStatus=0xbfffef24, aForceHandle=1, aHandled=@0xbfffeec8) at nsPresShell.cpp:5485 #43 0x41c29cbb in nsView::HandleEvent (this=0x82f7cb8, event=0xbffff028, aEventFlags=28, aStatus=0xbfffef24, aForceHandle=1, aHandled=@0xbfffeec8) at nsView.cpp:364 #44 0x41c35da5 in nsViewManager::DispatchEvent (this=0x80add00, aEvent= 0xbffff028, aStatus=0xbfffef24) at nsViewManager.cpp:2054 #45 0x41c29364 in HandleEvent (aEvent=0xbffff028) at nsView.cpp:67 #46 0x40989348 in nsWidget::DispatchEvent (this=0x82f7d20, aEvent=0xbffff028, aStatus=@0xbfffefc0) at nsWidget.cpp:1488 #47 0x40988f8c in nsWidget::DispatchWindowEvent (this=0x82f7d20, event= 0xbffff028) at nsWidget.cpp:1379 #48 0x40989400 in nsWidget::DispatchMouseEvent (this=0x82f7d20, aEvent= @0xbffff028) at nsWidget.cpp:1515 #49 0x4098a775 in nsWidget::OnButtonReleaseSignal (this=0x82f7d20, aGdkButtonEvent=0x818f280) at nsWidget.cpp:2064 #50 0x40991150 in nsWindow::HandleGDKEvent (this=0x82f7d20, event=0x818f280) at nsWindow.cpp:1474 #51 0x40980961 in dispatch_superwin_event (event=0x818f280, window=0x82f7d20) at nsGtkEventHandler.cpp:1022 #52 0x40980504 in handle_gdk_event (event=0x818f280, data=0x0) at nsGtkEventHandler.cpp:843 #53 0x40b05ab2 in ?? () from /usr/lib/libgdk-1.2.so.0 #54 0x40b322c6 in ?? () from /usr/lib/libglib-1.2.so.0 #55 0x40b32801 in ?? () from /usr/lib/libglib-1.2.so.0 #56 0x40b32979 in ?? () from /usr/lib/libglib-1.2.so.0 #57 0x40a61f3a in ?? () from /usr/lib/libgtk-1.2.so.0 #58 0x409752da in nsAppShell::Run (this=0x8102900) at nsAppShell.cpp:360 #59 0x40903014 in ?? () from /builds2/ftang/bidi/mozilla/dist/bin/components/ libnsappshell.so #60 0x40ca867a in ?? () from /builds2/ftang/bidi/mozilla/dist/bin/components/ libprofile.so #61 0x40ca7c77 in ?? () from /builds2/ftang/bidi/mozilla/dist/bin/components/ libprofile.so #62 0x08053b59 in InitializeProfileService (cmdLineArgs=0x8100db8) at nsAppRunner.cpp:783 #63 0x08054958 in main1 (argc=1, argv=0xbffff994, nativeApp=0x0) at nsAppRunner.cpp:975 #64 0x0805599a in main (argc=1, argv=0xbffff994) at nsAppRunner.cpp:1311 #65 0x4031ecb3 in __libc_start_main (main=0x80557ac <main>, argc=1, argv= 0xbffff994, init=0x804f8f4 <_init>, fini=0x80612ac <_fini>, rtld_fini=0x4000a350 <_dl_fini>, stack_end=0xbffff98c) at ../sysdeps/generic/libc-start.c:78 (gdb) notice that it is release by nsView::HandleEvent line 377 which is 298 NS_IMETHODIMP nsView :: HandleEvent(nsGUIEvent *event, PRUint32 aEventFlags, 299 nsEventStatus* aStatus, PRBool aForceHandle, PRBool& aHandled) 300 { 301 NS_ENSURE_ARG_POINTER(aStatus); 302 303 //printf(" %d %d %d %d (%d,%d) \n", this, event->widget, event-> widgetSupports, 304 // event->message, event->point.x, event->point.y); 305 306 // Hold a refcount to the observer. The continued existence of the observer will 307 // delay deletion of this view hierarchy should the event want to cause its 308 // destruction in, say, some JavaScript event handler. 309 nsIViewObserver *obs; 310 if (NS_FAILED(mViewManager->GetViewObserver(obs))) 311 obs = nsnull; .... 377 NS_IF_RELEASE(obs); 378 379 return NS_OK; 380 } somehow obs is also a PresShell If I apply the patch, then mozilla will show nothign as ji describe origionally. so... that probably is not a good fix.
hum... this maybe gtk problem. I got a lot of Gdk-Message: Got event for unknown widget: 0x2800bf I seach my gtk+ source gtk+1.2.6 under ChangeLog it said Mon Aug 23 15:05:17 CDT 1999 Shawn T. Amundson <amundson@gtk.org> * Released GTK+ 1.2.4 .... Thu Jun 24 17:06:23 1999 Tim Janik <timj@gtk.org> * gdk/gdkevents.c (gdk_event_translate): removed old ""Got event for unknown window:" message. disabled ConfigureNotify discarding code, because it led to events being processed out of order. So... this stuff is fixed in gtk 1.2.4 - my gtk+ is 1.2.1 and erik is using gtk+1.2.3 ji- what is your version ? do a "rpm -q gtk+" could that "events being processed out of order" cause this ?
blizzard- which version of gtk+ should we use ? Need some help on gtk.... could this bug caused by that unknown event bug in the gtk?
I upgrade to gtk1.2.8 and there are no difference. I no longer get those message. but I will still crash if I don't apply the patch.
I think we have two problem instead one here. One is crash . One is hang after we create the new profile and select it. The crash could be solved by my earily patch. I still think that is the right fix. I have no idea how to adderss the hang. It seems after we try to load the user style sheet (it will failed, same as before/after the bidi changes) it hang and does not load view source style sheet or quike style sheet.
Frank, the reason for the hack Nisheeth put there was because the real fix seemed so difficult and risky at the time. It is all about refcount cycles, who should own who, in what order should things be released etc. You may have found the solution, but I doubt it. Bug 58830 is about PresShell/ViewManager ownership model. Anyway, if your fix is not the correct one it can a) cause a HUGE memory leak and/or b) cause a crash elsewhere. It needs a careful review, and leak/bloat testing. Since you have a Linux available, could you test if leaks/bloat changed? Also we should retest all the old preshell et al crasher bugs caused by wacky ownership with your patch. There are links to those bugs in bug 58830. Please check those out. If you do not crash, also check leaks/bloat.
Frank, the gtk version on my RH6.2J is "gtk+-1.2.6-7".
gtk+-1.2.6-7 for my RH6.2-Ja too.
I just learn the origional hanging problem is a dup of 79179.
I try my patch and run bloat/leak test- by 1. ./mozilla --profilemanager 2. click manager profile 3. create profile 4. type 'i001' and 'i002' (for the 2nd time) 5. select the newly created profile 6. after the page load, quit and the result is good. I didn't bloat/leak than the one have no fix. I use a non bidi build to test this.
Bidi build with the patch neither regress. I think it is a good fix. Probably not a perfect fix. But at least it is a better bandaid then the origional one.
I tried to reproduce the crash on the build pulled after the XPCDOM branch landing today and wasn't able to. I am able to reproduce the hang every time, though, but that is a different bug (bug 79179) that also happens on non BIDI builds. Frank, I agree that your idea of holding a strong reference to the view manager for the lifetime of the ReflowEvent object is a better bandaid to bug 58830. At the same time, however, it introduces a dependency on NSPR's event system for reliably cleaning up events. If there are bugs in the event system that prevent event finalizers from getting called, we will start leaking view managers and consequently views. I am not sure how valid this concern is, howeever, because the NSPR event system should be a fairly robust piece of code by now. I urge you to test this patch thoroughly and get advice from super reviewers. I'm attaching a patch that removes the earlier bandaid in deference to your new bandaid. Heikki, please review it. Frank, I'd suggest waterson and vidur as potential super reviewers. I'd also suggest that you update to the tip and ensure that the crash still exists. If it does not, it might make sense to leave the code as is.
confirm that the up to the tip bidi build won't crash. and the hang problem is a dup of 79179 mark this bug as 79179 remove this from bidi blocker. *** This bug has been marked as a duplicate of 79179 ***
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
Verified dup.
Status: RESOLVED → VERIFIED
add to cc list
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: