Closed Bug 284354 Opened 19 years ago Closed 19 years ago

[FIX]crash when submitting bugzilla query - Trunk [@ HandleDummyLayoutRequestPLEvent] [@ DummyLayoutRequestEvent::HandleEvent ]

Categories

(Core :: Layout, defect, P1)

defect

Tracking

()

VERIFIED FIXED
mozilla1.8beta2

People

(Reporter: bugzilla, Assigned: bzbarsky)

References

Details

(4 keywords)

Crash Data

Attachments

(2 files)

found using camino 2005030108-trunk NB.

1. go to https://bugzilla.mozilla.org/query.cgi?format=advanced

2. fill out/select some fields. what I did: selected New, Assigned, Reopened,
Resolved and entered "fixed-aviary1.0.1" as a keyword to search on.

3. hit the Search button.

results: camino crashes.

here's thread 0, but I'll attach the whole crash log soon.

Thread 0 Crashed:
0   <<00000000>> 	0x00000000 0 + 0
1   libxpcom_core.dylib      	0x0184c3c8 PL_HandleEvent + 0x24
2   libxpcom_core.dylib      	0x0184c2ec PL_ProcessPendingEvents + 0x80
3   com.apple.CoreFoundation 	0x90193ca8 __CFRunLoopDoSources0 + 0x1fc
4   com.apple.CoreFoundation 	0x90191560 __CFRunLoopRun + 0x1b0
5   com.apple.CoreFoundation 	0x90195e8c CFRunLoopRunSpecific + 0x148
6   com.apple.HIToolbox      	0x927d5f60 RunCurrentEventLoopInMode + 0xac
7   com.apple.HIToolbox      	0x927dc6c8 ReceiveNextEventCommon + 0x17c
8   com.apple.HIToolbox      	0x927fe6a0 BlockUntilNextEventMatchingListInMode +
0x60
9   com.apple.AppKit         	0x92dd2e44 _DPSNextEvent + 0x180
10  com.apple.AppKit         	0x92de98c8 -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] + 0x74
11  com.apple.AppKit         	0x92dfdc30 -[NSApplication run] + 0x21c
12  com.apple.AppKit         	0x92eba2b8 NSApplicationMain + 0x1d0
13  org.mozilla.navigator    	0x0000aa88 _start + 0x17c
14  org.mozilla.navigator    	0x0000a908 start + 0x30
Attached file whole crashlog
Priority: -- → P1
Target Milestone: --- → Camino0.9
Wevah saw HandleDummyLayoutRequestPLEvent on his stack, which I've seen too.
Boris, this looks like you.
Assignee: pinkerton → bzbarsky
Summary: crash when submitting bugzilla query → crash when submitting bugzilla query (HandleDummyLayoutRequestPLEvent)
this regressed between the 2005022708-trunk (works) and 2005022808-trunk
(crashes) builds.
Keywords: regression
What did a stack involving HandleDummyLayoutRequestPLEvent look like?  Give me
_something_ to work with here?  ;)

Also, note that presshell does revoke all its events when it's destroyed.  Are
we being bitten by the "revokeEvents doesn't always work" thing here?  It's been
mentioned in bug comments before...  I did just check, and the event is posted
with owner pointing to the presshell as a PresShell*, and the same thing is
passed to revokeEvents.
Keywords: helpwanted
Boris: in the logs I saw, the stack under HandleDummyLayoutRequestPLEvent looked
bad. In the log in this bug, it's non-existant  :)
Sure, but what did locals look like?  What did *this look like?   In particular,
did it look like the event's owner just pointed to deallocated memory?  Or to a
destroyed PresShell object?  Or something else?  Or was aEvent itself broken?
(In reply to comment #5)
> What did a stack involving HandleDummyLayoutRequestPLEvent look like?  Give me
> _something_ to work with here?  ;)

It looks exactly like the attached crash log, except that line 0 shows the call
to HandleDummyLayoutRequestPLEvent instead of just restating the address:

 #0   0x002d798c in _Z31HandleDummyLayoutRequestPLEventP7PLEvent

(It's munged like this because my log is under OS X 10.2.)
Reading back over, I guess that's not quite what you meant (but maybe it'll
help, anyway).
Attached patch Proposed patchSplinter Review
Patch per Simon's debugging... I think this should fix the problem.
Component: General → Layout: Misc Code
Product: Camino → Core
Target Milestone: Camino0.9 → mozilla1.8beta2
Version: unspecified → Trunk
This appears to fix the crash.
Comment on attachment 176007 [details] [diff] [review]
Proposed patch

roc, would you review?	I think the comment explains the setup, but please
sanity-check both that it matches the code and that the result ends up being
ok?  I've stared at this for so long at this point, that I no longer quite
trust myself.
Attachment #176007 - Flags: superreview?(roc)
Attachment #176007 - Flags: review?(roc)
Summary: crash when submitting bugzilla query (HandleDummyLayoutRequestPLEvent) → [FIX]crash when submitting bugzilla query (HandleDummyLayoutRequestPLEvent)
*** Bug 284335 has been marked as a duplicate of this bug. ***
I'm hitting this a lot with linux too.
OS: MacOS X → All
Hardware: Macintosh → All
Same for me with Mozilla 1.8b2 build 2005022805 on WinNT4. I've just wanted to
open a new bug (because TB did not find the stack) but with CVS blame I saw the
comment in bug 281157. Adjust summary.

My TB reports: TB4034524G, TB4052536H

Stack Signature	 DummyLayoutRequestEvent::HandleEvent 30df2a62
Product ID	MozillaTrunk
Build ID	2005022805
Trigger Time	2005-03-01 07:26:24.0
Platform	Win32
Operating System	Windows NT 4.0 build 1381
Module	gklayout.dll + (00017543)
URL visited	https://bugzilla.mozilla.org/
User Comments	several tabs open, wanted to search, crash after pressing the
search button on advanced search page
Since Last Crash	814 sec
Total Uptime	1969 sec
Trigger Reason	Access violation
Source File, Line No.
c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/base/nsPresShell.cpp,
line 6511
Stack Trace 	
DummyLayoutRequestEvent::HandleEvent 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/base/nsPresShell.cpp,
line 6511]
Summary: [FIX]crash when submitting bugzilla query (HandleDummyLayoutRequestPLEvent) → [FIX]crash when submitting bugzilla query [@ HandleDummyLayoutRequestPLEvent] [@ DummyLayoutRequestEvent::HandleEvent ]
Comment on attachment 176007 [details] [diff] [review]
Proposed patch

+  // 4)  Destroy() guarantees that the dummy layout request is removed by
+  //	  calling RemoveDummyLayoutRequest(), since we may already have no
+  //	  reflow commands around and we revoke our events.
'and we'? 'when we'? something else?
"and we" is the right phrasing for what I want to say.
Just seen this in my latest BeOS build (Search for
HandleDummyLayoutRequestPLEvent in bugzilla, click this bug, then click back).
The patch fixes it.
Comment on attachment 176007 [details] [diff] [review]
Proposed patch

as far as I can tell, your comments accurately describe the situation...
Attachment #176007 - Flags: superreview?(roc)
Attachment #176007 - Flags: superreview+
Attachment #176007 - Flags: review?(roc)
Attachment #176007 - Flags: review+
Fixed.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
*** Bug 284397 has been marked as a duplicate of this bug. ***
*** Bug 284644 has been marked as a duplicate of this bug. ***
Adding topcrash info for future reference.  Regressed on 2/28, fix checked in
3/2...and no crashes since according to Talkback.  Marking verified.
Status: RESOLVED → VERIFIED
Keywords: topcrash
Summary: [FIX]crash when submitting bugzilla query [@ HandleDummyLayoutRequestPLEvent] [@ DummyLayoutRequestEvent::HandleEvent ] → [FIX]crash when submitting bugzilla query - Trunk [@ HandleDummyLayoutRequestPLEvent] [@ DummyLayoutRequestEvent::HandleEvent ]
Crash Signature: [@ HandleDummyLayoutRequestPLEvent] [@ DummyLayoutRequestEvent::HandleEvent ]
Product: Core → Core Graveyard
Component: Layout: Misc Code → Layout
Product: Core Graveyard → Core
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: