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

VERIFIED WORKSFORME

Status

P1
critical
VERIFIED WORKSFORME
18 years ago
10 years ago

People

(Reporter: laurel, Assigned: saari)

Tracking

({crash, platform-parity})

Trunk
mozilla0.9.5
PowerPC
All
crash, platform-parity
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

18 years ago
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.

Steps:
1.  Edit|Prefs|Themes. Change to Classic skin, OK/confirm out of alert and prefs
dialog.
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.
(Reporter)

Comment 1

18 years ago
Created attachment 41831 [details]
macsbug stdlog
(Reporter)

Comment 2

18 years ago
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.
(Reporter)

Updated

18 years ago
Keywords: pp
OS: Mac System 8.5 → Mac System 9.x

Comment 3

18 years ago
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...
Status: NEW → ASSIGNED
laurel, on recent trunk builds, can you reproduce this with the window manager
[x]?
(Reporter)

Comment 7

18 years ago
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"
(Reporter)

Comment 10

18 years ago
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*)+
000CC
  0E439DF0    PPC  0C1D22F4  nsMacMessagePump::DoActivate(EventRecord&)+0006C
  0E439DB0    PPC  0C1D2460  
nsMacMessagePump::DispatchOSEventToRaptor(EventRecord&, GrafPort
*)+00044
  0E439D70    PPC  0C1CCA9C  nsMacMessageSink::DispatchOSEvent(EventRecord&, 
GrafPort*)+00048
  0E439D30    PPC  0C1C5790  nsMacWindow::HandleOSEvent(EventRecord&)+00038
  0E439CF0    PPC  0C1C7144  nsMacEventHandler::HandleOSEvent(EventRecord&)+00070
  0E439CA0    PPC  0C1C85D8  nsMacEventHandler::HandleActivateEvent(EventRecord&
)+000C8
  0E439C40    PPC  0C1C6B18  nsMacEventDispatchHandler::SetActivated(nsWindow*)+
000C8
  0E439BF0    PPC  0C1C67D0  
nsMacEventDispatchHandler::DispatchGuiEvent(nsWindow*, unsigned 
int)+00090
  0E439B80    PPC  0C1B4920  nsWindow::DispatchWindowEvent(nsGUIEvent&)+00028
  0E439B40    PPC  0C1B4828  nsWindow::DispatchEvent(nsGUIEvent*, nsEventStatus&
)+000B8
  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 
int)+00090
  0E439790    PPC  0C1B4920  nsWindow::DispatchWindowEvent(nsGUIEvent&)+00028
  0E439750    PPC  0C1B4828  nsWindow::DispatchEvent(nsGUIEvent*, nsEventStatus&
)+000B8
  0E439700    PPC  0B635DD4  HandleEvent(nsGUIEvent*)+00064
  0E4396B0    PPC  0B64DB28  nsViewManager::DispatchEvent(nsGUIEvent*, 
nsEventStatus*)+00974
  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,
 nsEventStatus*)+000F0
  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()

Comment 15

18 years ago
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
crashing!
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 
owner?
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"

Comment 24

17 years ago
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
comments:

 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&)
const+00BC8
   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
(Reporter)

Comment 25

17 years ago
*** Bug 91391 has been marked as a duplicate of this bug. ***

Updated

17 years ago
Keywords: crash

Comment 26

17 years ago
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?

http://lxr.mozilla.org/seamonkey/search?string=dispatchfocus

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

still investigating.
(Reporter)

Comment 29

17 years ago
*** 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
Status: ASSIGNED → NEW
(Assignee)

Updated

17 years ago
Target Milestone: mozilla0.9.4 → mozilla0.9.5

Updated

17 years ago
Blocks: 99194

Comment 31

17 years ago
Saari is out of the office, so I think this one is gonna have to wait unless
Judson reassignes. Propose nsbranch-.

Comment 32

17 years ago
gone
Keywords: nsbranch-

Comment 33

17 years ago
removed keyword nsbranch since bug now has nsbranch-, per pdt mtg.
Keywords: nsbranch
(Assignee)

Comment 34

17 years ago
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.
(Assignee)

Comment 35

17 years ago
This did not crash for me on a fresh mac build. 
(Reporter)

Comment 36

17 years ago
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
reopen.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 37

17 years ago
Marking verified worksforme
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey

Updated

10 years ago
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.