Closed Bug 90208 Opened 20 years ago Closed 20 years ago

app crashes when closing Search Msg/Filter Rules dialog in this case


(SeaMonkey :: MailNews: Message Display, defect, P1)



(Not tracked)



(Reporter: laurel, Assigned: saari)



(Keywords: crash, platform-parity)


(1 file)

Using july10 commercial branch build, mac OS 9.0
Cannot reproduce with linux or win98

Only seen when in classic skin, does not happen on same accounts when in Modern.

1.  Edit|Prefs|Themes. Change to Classic skin, OK/confirm out of alert and prefs
2.  Exit and restart, go to mail window, login to account ( mine was IMAP), let
inbox load.
3.  Search|Search Mail/News Messages. Type a character or two in the
default/first criteria row's text field. Do not press Enter or click Search to
engage a search.
4.  Click the Close button.

Result: Application exits, no talkback, but I do have a macsbug stdlog which
I'll attach.

Note:  Generally closing the search dialog after searching didn't have the same
effect.  It happens for me only when I close after typing into the text field
when there's no results, no previous activity.
Attached file macsbug stdlog
More info:  doesn't happen on trunk (there was a fix applied to trunk to make it
a window, remove close button).  Does happen with the Beta1/PR1/june7 branch build.
Keywords: pp
OS: Mac System 8.5 → Mac System 9.x
So it's not reproducable on the trunk, at all?
I'll investigate, navin has a dataloss bug he's working on.
Assignee: naving → sspitzer
I've got an old trunk build (before 0.9.2) that has this problem.

I can reproduce it.  debugging now...
laurel, on recent trunk builds, can you reproduce this with the window manager
No I couldn't.
I'm able to reproduce this, but I've quickly run out of mac debugging expertise.

I don't end up with a stack when I crash, which cramps my style.

ducarroz, can you take a look?
when I do crash, I get this:

"unmapped memory exception"
I'm hitting this on Filters, too. Mac only, today's branch and trunk.  Happens
when editing in Filter Rules, can't do it in a lot of situations in that dialog,
but this case is reproducible:
1.  Launch filters where there is an existing filter.
2.  Select filter, edit --> opens filter rules dialog populated with previously
enetered conditions. (Doesn't matter if it's a filter with lots of conditions or
just one existing condition.)
3.  Click More button. Place cursor in the text field of the newly added line,
type a character then OK the dialog.  Boom.
Summary: App exits when closing Search Msg dialog in this case → App exits when closing Search Msg/Filter Rules dialog in this case
I've kicked off a trunk build, so that I can look into the filter trunk problem.

maybe I can get a stack from that crash.

ducarroz is going to get his 0.9.2 branch build up, and investigate search.
still building, I'll resume work on this tomorrow.
I can now reproduc this crash with a branch build from last nigh (around 9 pm). 

Looks like we are crashing while dispatching a DOM event. cc'ing 
pinkerton and saari in case they have an idea. Investigating...
I can reproduce laurel's filter crash on the trunk.

I can't get a stack trace in the debugger (I get that same error), but when I 
don't use the debugger I get this in macsbugs:

 Calling chain using A6/R1 links
  Back chain  ISA  Caller
  00000000    PPC  0C8144DC  
  0E43A200    PPC  0C7F5ED0  main+001AC
  0E43A1A0    PPC  0C7F3120  main1(int, char**, nsISupports*)+00A68
  0E439F20    PPC  0C496700  nsAppShellService::Run()+00054
  0E439ED0    PPC  0C1CFD80  nsAppShell::Run()+0004C
  0E439E90    PPC  0C1D0A1C  nsMacMessagePump::DoMessagePump()+00044
  0E439E40    PPC  0C1D12B0  nsMacMessagePump::DispatchEvent(int, EventRecord*)+
  0E439DF0    PPC  0C1D22F4  nsMacMessagePump::DoActivate(EventRecord&)+0006C
  0E439DB0    PPC  0C1D2460  
nsMacMessagePump::DispatchOSEventToRaptor(EventRecord&, GrafPort
  0E439D70    PPC  0C1CCA9C  nsMacMessageSink::DispatchOSEvent(EventRecord&, 
  0E439D30    PPC  0C1C5790  nsMacWindow::HandleOSEvent(EventRecord&)+00038
  0E439CF0    PPC  0C1C7144  nsMacEventHandler::HandleOSEvent(EventRecord&)+00070
  0E439CA0    PPC  0C1C85D8  nsMacEventHandler::HandleActivateEvent(EventRecord&
  0E439C40    PPC  0C1C6B18  nsMacEventDispatchHandler::SetActivated(nsWindow*)+
  0E439BF0    PPC  0C1C67D0  
nsMacEventDispatchHandler::DispatchGuiEvent(nsWindow*, unsigned 
  0E439B80    PPC  0C1B4920  nsWindow::DispatchWindowEvent(nsGUIEvent&)+00028
  0E439B40    PPC  0C1B4828  nsWindow::DispatchEvent(nsGUIEvent*, nsEventStatus&
  0E439AF0    PPC  0C49F11C  nsWebShellWindow::HandleEvent(nsGUIEvent*)+00960
  0E439990    PPC  0BA35604  GlobalWindowImpl::Focus()+00470
  0E439880    PPC  0C1B12E4  nsWindow::SetFocus(int)+00018
  0E439840    PPC  0C1C69F0  nsMacEventDispatchHandler::SetFocus(nsWindow*)+0009C
  0E439800    PPC  0C1C67D0  
nsMacEventDispatchHandler::DispatchGuiEvent(nsWindow*, unsigned 
  0E439790    PPC  0C1B4920  nsWindow::DispatchWindowEvent(nsGUIEvent&)+00028
  0E439750    PPC  0C1B4828  nsWindow::DispatchEvent(nsGUIEvent*, nsEventStatus&
  0E439700    PPC  0B635DD4  HandleEvent(nsGUIEvent*)+00064
  0E4396B0    PPC  0B64DB28  nsViewManager::DispatchEvent(nsGUIEvent*, 
  0E4394B0    PPC  0B636FC8  nsView::HandleEvent(nsGUIEvent*, unsigned int, 
nsEventStatus*, i
nt, int&)+0039C
  0E439400    PPC  0B6AA3F8  PresShell::HandleEvent(nsIView*, nsGUIEvent*, 
nsEventStatus*, in
t, int&)+00330
  0E439360    PPC  0B6AA870  PresShell::HandleEventInternal(nsEvent*, nsIView*, 
unsigned int,
  0E4392F0    PPC  0BC68CE4  nsEventStateManager::PreHandleEvent(nsIPresContext*, 
nsEvent*, n
sIFrame*, nsEventStatus*, nsIView*)+00718
  0E438D00    PPC  0BD0C444  nsHTMLInputElement::HandleDOMEvent(nsIPresContext*, 
nsEvent*, ns
IDOMEvent**, unsigned int, nsEventStatus*)+00AF0
  0E438A40    PPC  0BDB0D34  nsGenericElement::HandleDOMEvent(nsIPresContext*, 
nsEvent*, nsID
OMEvent**, unsigned int, nsEventStatus*)+002F4

I'll go look at nsHTMLInputElement::HandleDOMEvent()
adding nsbranch in case we can get a fix.
Keywords: nsBranch
Priority: -- → P1
Target Milestone: --- → mozilla0.9.3
I get this on mac 8.6, so marking all.

no luck with this one yet, still debugging...
OS: Mac System 9.x → All
pink tells me this is a dup.

I'll go search for the bug.
this is almost certainly 87112.
I'll update my mac build and see if it has gone away.  (now that 87112 has been
marked fixed.)

if it does, I'll mark it a dup.
Depends on: 87112
I am running today'e debug build which has the fix for bug 87112 and I am still
I'll update my mac build and see if it has gone away.  (now that 87112 has been
marked fixed.)

if it does, I'll mark it a dup.
I still crash, even with peter's fix for #87112

peter, does this look like the same bug to you?  if so, would you be the right 
Summary: App exits when closing Search Msg/Filter Rules dialog in this case → app crashes when closing Search Msg/Filter Rules dialog in this case
I just got peter's last check in to nsObjectFrame.cpp.

still crashes.

mac, classic skin only, following laurel's steps on "2001-07-10 16:13"
With Laurel's steps on 7-10, it doesn't seem likley that this is a dup of bug
87112. You can try setting a breakpoint in nsObjectFrame::DispatchFocus, but
since the crah happens in Mail Rules, I can't even see how an nsObjectFrame
would be loaded in memory. Laurel's stack is different from the one pasted in

 Stack Addr  Frame Addr   ISA   Caller
   0F6EF6F4                PPC   6806E224
   0F6EF6E4                68K   0001ACEA
   0F6EF6DC                68K   100CAF60 HGETVOL+FD376
   0F6EF6C4                68K   000CC624
   0F6EF6B4                68K   FFC168E2 _UnimplTrap+01084
   0F6EF68C                68K   0070915C
   0F6EF688                68K   FFC101A4 _CursorDeviceDispatch+01684
   0F6EF664                68K   0060D890
   0F6EF5BC                PPC   1E7E8A54 nsFileSpec::Execute(const nsString&)
   0F6EF5A4                68K   0000000A
   0F6EF4B0                PPC   1EE02724 NS_NewImageDocument(nsIDocument**)+84D10
   0F6EF498                PPC   1E78B77C
nsSupportsHashtable::ReleaseElement(nsHashKey*, voi
d*, void*)+00020
   0F6EF468                PPC   FFCF6CA4 LowLevelExceptionHandler+002FC
   0F6EF450                PPC   1EE02724 NS_NewImageDocument(nsIDocument**)+84D10
   0F6EF3FC                PPC   1E7915AC nsCOMPtr_base::~nsCOMPtr_base()+00030
   0F6EF3F0                PPC   1EE02724 NS_NewImageDocument(nsIDocument**)+84D10
   0F6EF3E4                PPC   1E78B77C
nsSupportsHashtable::ReleaseElement(nsHashKey*, voi
d*, void*)+00020
*** Bug 91391 has been marked as a duplicate of this bug. ***
Keywords: crash
moving to 0.9.4
Target Milestone: mozilla0.9.3 → mozilla0.9.4
peter, thanks for the hint, sorry for the delay.

I tried again on my fresh mac trunk build, still crash.

I don't see nsObjectFrame::DispatchFocus(), did you mean something else?

using the debugger, I seem to be consistently dying in
nsGenericElement::GetBindingParent(), at NS_IF_ADDREF(*aContent);

still investigating.
*** Bug 92308 has been marked as a duplicate of this bug. ***
pink / saari, I'm going to throw this one back over the wall to xptoolkit, since
it isn't XP.

if you need help reproducing this crasher, I can stop by.

over to saari, since he's running xptoolkit and is a mac / event guru.
Assignee: sspitzer → saari
Target Milestone: mozilla0.9.4 → mozilla0.9.5
Blocks: 99194
Saari is out of the office, so I think this one is gonna have to wait unless
Judson reassignes. Propose nsbranch-.
Keywords: nsbranch-
removed keyword nsbranch since bug now has nsbranch-, per pdt mtg.
Keywords: nsbranch
Seth, it sounds like this isn't a focus issue, correct? I'm doing a build now to
get back up to date and I'll give this a whril.
This did not crash for me on a fresh mac build. 
Using today's branch builds for both OS X and OS 9.1, I can no longer reproduce
the crash in either search or filters.  Tried in classic theme (as how
originally reported) and also in modern, just in case.  Worksforme in current
build.  If development thinks there still may be a trailing issue here, please
Closed: 20 years ago
Resolution: --- → WORKSFORME
Marking verified worksforme
Product: Browser → Seamonkey
Component: MailNews: Search → MailNews: Message Display
QA Contact: laurel → search
You need to log in before you can comment on or make changes to this bug.