68472 - [xlib] Xlib-based Mozilla crashes at shutdown in nsClipboard::Callback

Status: RESOLVED FIXED

(Core :: XUL, defect)

Description

[Roland Mainz]

mozilla-2001-02-10-08-Mtrunk build with --enable-toolkit=xlib using Sun Workshop
6U2EA on Solaris 7 crashes at shutdown like this:
-- snip --
t@1 (l@4) terminated by signal BUS (invalid address alignment)
Current function is nsClipboard::Callback (optimized)
  171   }
(/opt/SUNWspro/bin/../WS6U2/bin/sparcv9/dbx) where
current thread: t@1
=>[1] nsClipboard::Callback(event = ???) (optimized), at 0xfde2e2f0 (line ~171)
in "nsClipboard.cpp"
  [2] nsWidget::DispatchEvent(this = ???, aEvent = ???, aStatus = ???)
(optimized), at 0xfde3c058 (line ~1287) in "nsWidget.cpp"
  [3] nsWidget::DispatchWindowEvent(this = ???, aEvent = STRUCT) (optimized), at
0xfde3be7c (line ~1186) in "nsWidget.cpp"
  [4] nsWidget::DispatchDestroyEvent(this = ???) (optimized), at 0xfde3bc5c
(line ~1121) in "nsWidget.cpp"
  [5] nsWidget::OnDestroy(this = ???) (optimized), at 0xfde3bba8 (line ~1096) in
"nsWidget.cpp"
  [6] nsWidget::Destroy(this = ???) (optimized), at 0xfde3a4a4 (line ~373) in
"nsWidget.cpp"
  [7] nsWidget::~nsWidget(this = ???) (optimized), at 0xfde39e74 (line ~151) in
"nsWidget.cpp"
  [8] __SLIP.DELETER__B(0x6bde08, 0x1, 0xfde7c38d, 0xfde2f7a4, 0xff3df650, 0x70)
(optimized), at 0xfde3d2d8
  [9] nsBaseWidget::Release(this = ???) (optimized), at 0xfde40698 (line ~45) in
"nsBaseWidget.cpp"
  [10] nsClipboard::~nsClipboard(this = ???) (optimized), at 0xfde2e07c (line
~82) in "nsClipboard.cpp"
  [11] __SLIP.DELETER__A(0x6dc6e8, 0x1, 0xfde7881a, 0xffbee5e4, 0xff104ec8, 0x0)
(optimized), at 0xfde2f7a4
  [12] nsClipboard::Release(this = ???) (optimized), at 0xfde2ddd4 (line ~71) in
"nsClipboard.cpp"
  [13] DeleteEntry(aKey = ???, aData = ???, closure = ???) (optimized), at
0xff1dfa24 (line ~258) in "nsServiceManager.cpp"
  [14] _hashEnumerateRemove(he = ???, i = ???, arg = ???) (optimized), at
0xff1701fc (line ~367) in "nsHashtable.cpp"
  [15] PL_HashTableEnumerateEntries(ht = 0x3be18, f = 0xff1701dc =
&`libxpcom.so`nsHashtable.cpp`_hashEnumerateRemove(register struct PLHashEntry
*he, register PRIntn i, register void *arg), arg = 0xffbee4a8), line 413 in
"plhash.c"
  [16] nsHashtable::Reset(this = ???, destroyFunc = ???, closure = ???)
(optimized), at 0xff170284 (line ~385) in "nsHashtable.cpp"
  [17] nsObjectHashtable::Reset(this = ???) (optimized), at 0xff1710e0 (line
~627) in "nsHashtable.cpp"
  [18] nsObjectHashtable::~nsObjectHashtable(this = ???) (optimized), at
0xff170fb0 (line ~593) in "nsHashtable.cpp"
  [19] __SLIP.DELETER__C(this = ???, delete = ???) (optimized), at 0xff1718d0
(line ~0) in "FNuMNaVbh6Sr4."
  [20] nsServiceManagerImpl::~nsServiceManagerImpl(this = ???) (optimized), at
0xff1dfc1c (line ~283) in "nsServiceManager.cpp"
  [21] __SLIP.DELETER__C(0x37aa8, 0x1, 0xff276f23, 0xff164c58, 0xff3df650, 0x2f)
(optimized), at 0xff1e0bf4
  [22] nsServiceManagerImpl::Release(this = ???) (optimized), at 0xff1dfd7c
(line ~292) in "nsServiceManager.cpp"
  [23] nsServiceManager::ShutdownGlobalServiceManager(result = ???) (optimized),
at 0xff1e0620 (line ~544) in "nsServiceManager.cpp"
  [24] NS_ShutdownXPCOM(servMgr = ???) (optimized), at 0xff164c58 (line ~690) in
"nsXPComInit.cpp"
  [25] main(argc = ???, argv = ???) (optimized), at 0x16980 (line ~1284) in
"nsAppRunner.cpp"
-- snip --

Comment 1

[Peter Trudelle]

->pinkerton, cc the Dr. for any needed help on Solaris

Comment 2

[Peter Trudelle]

cc blizzard in case this is a moz-xlib problem

Comment 3

[Mike Pinkerton (not reading bugmail)]

pav has a shiny solaris box

Comment 4

[May Chang]

Is this reproducible on any other platform?

Comment 5

[Roland Mainz]

> Is this reproducible on any other platform?

Unlikely. gcc on SPARC tries to avoid such problems by memcpy()ing stuff to fit
alignment needs (which is programmer-friendly but wastes CPU power a _lot_) -
and most other platforms do not have this "restriction"...

Comment 6

[Stuart Parmenter]

reassigning to roland.  please assign this to someone that works on the xlib 
port.

Comment 7

[Roland Mainz]

To Pavlov: OK... but I only can do this if someone with checkin-permissions on
CVS helps me a little bit, please... Any volunteers (pavlov :-) ?

Comment 8

[Roland Mainz]

More precise stack trace(+debug output before crash) from 2001-04-17 CVS
snapshot:
-- snip --
Creating a new nsIToolkit!
Enabling Quirk StyleSheet
Reading libimgjpeg.so
Reading libjpeg.so.62
Document http://www.absolutemodels.com/ninabrosh/images/012.jpg loaded
successfully
Disabling View Source StyleSheet
/ninabrosh/images/012.jpg
Creating a new nsIToolkit!
Enabling Quirk StyleSheet
Document http://www.mozilla.org/ loaded successfully
/
/content/search/search-panel.xul
blank
WEBSHELL- = 3
WEBSHELL- = 2
/content/navigator.xul
WEBSHELL- = 1
Shut down app shell component {18c2f989-b09f-11d2-bcde-00805f0e1353},
rv=0x00000000
### beging nsCacheService::Shutdown()
### starting ~nsMemoryCacheDevice()
t@1 (l@1) signal SEGV (no mapping at the fault address) in nsClipboard::Callback
at line 116 in file "nsClipboard.cpp"
  116     if (ev->type == SelectionRequest) {
(/opt/SUNWspro/bin/../WS6U2/bin/sparcv9/dbx) where
current thread: t@1
=>[1] nsClipboard::Callback(event = 0xffbeeae0), line 116 in "nsClipboard.cpp"
  [2] nsWidget::DispatchEvent(this = 0x83abe8, aEvent = 0xffbeeae0, aStatus =
nsEventStatus_eIgnore), line 1276 in "nsWidget.cpp"
  [3] nsWidget::DispatchWindowEvent(this = 0x83abe8, aEvent = STRUCT), line 1184
in "nsWidget.cpp"
  [4] nsWidget::DispatchDestroyEvent(this = 0x83abe8), line 1117 in
"nsWidget.cpp"
  [5] nsWidget::OnDestroy(this = 0x83abe8), line 1095 in "nsWidget.cpp"
  [6] nsWidget::Destroy(this = 0x83abe8), line 373 in "nsWidget.cpp"
  [7] nsWidget::~nsWidget(this = 0x83abe8), line 151 in "nsWidget.cpp"
  [8] __SLIP.DELETER__B(0x83abe8, 0x1, 0xfe271c65, 0x3623c, 0xff3df650, 0x400),
at 0xfe24b30c
  [9] nsBaseWidget::Release(this = ???) (optimized), at 0xfe251f14 (line
~4194259) in "nsBaseWidget.cpp"
  [10] nsClipboard::~nsClipboard(this = 0x7cd1e8), line 82 in "nsClipboard.cpp"
  [11] __SLIP.DELETER__A(0x7cd1e8, 0x1, 0xfe26d74e, 0x1d904, 0x0, 0x0), at
0xfe22aa6c
  [12] nsClipboard::Release(this = 0x7cd1e8), line 71 in "nsClipboard.cpp"
  [13] DeleteEntry(aKey = ???, aData = ???, closure = ???) (optimized), at
0xff238358 (line ~258) in "nsServiceManager.cpp"
  [14] _hashEnumerateRemove(he = ???, i = ???, arg = ???) (optimized), at
0xff1e6288 (line ~367) in "nsHashtable.cpp"
  [15] PL_HashTableEnumerateEntries(0xffffffe8, 0xff1e6268, 0xffbeefe0, 0x8,
0x1, 0xff3c2038), at 0xff161a94
  [16] nsHashtable::Reset(this = ???, destroyFunc = ???, closure = ???)
(optimized), at 0xff1e6310 (line ~385) in "nsHashtable.cpp"
  [17] nsObjectHashtable::Reset(this = ???) (optimized), at 0xff1e70d4 (line
~627) in "nsHashtable.cpp"
  [18] nsObjectHashtable::~nsObjectHashtable(this = ???) (optimized), at
0xff1e6fb4 (line ~593) in "nsHashtable.cpp"
  [19] __SLIP.DELETER__C(this = ???, delete = ???) (optimized), at 0xff1e77b8
(line ~0) in "FNuMNjuO36SxI."
  [20] nsServiceManagerImpl::~nsServiceManagerImpl(this = ???) (optimized), at
0xff238544 (line ~283) in "nsServiceManager.cpp"
  [21] __SLIP.DELETER__C(0x3ac50, 0x1, 0xff2cf65b, 0xc5a30, 0xff3df650, 0xc00)
(optimized), at 0xff2394b8
  [22] nsServiceManagerImpl::Release(this = ???) (optimized), at 0xff2386a4
(line ~4194012) in "nsServiceManager.cpp"
  [23] nsServiceManager::ShutdownGlobalServiceManager(result = ???) (optimized),
at 0xff238f18 (line ~544) in "nsServiceManager.cpp"
  [24] NS_ShutdownXPCOM(servMgr = ???) (optimized), at 0xff1db1f4 (line ~473) in
"nsXPComInit.cpp"
  [25] main(argc = ???, argv = ???) (optimized), at 0x17118 (line ~1312) in
"nsAppRunner.cpp"
(/opt/SUNWspro/bin/../WS6U2/bin/sparcv9/dbx) print ev
ev = (nil)
-- snip --

Looking at http://lxr.mozilla.org/mozilla/source/widget/src/xlib/nsClipboard.cpp
-- snip --
// selectionrequest
112 nsEventStatus PR_CALLBACK nsClipboard::Callback(nsGUIEvent *event) {
113   XEvent *ev = (XEvent *)event->nativeMsg;
114 
115   // Check the event type
116   if (ev->type == SelectionRequest) {
-- snip --

Question: Why is "ev" here NULL - is this a legal value in nsGUIEvent ? if yes,
the quick fix would be easy: Check for NULL and return...

----

Accepting bug - assuming that blizzard or pavlov will help me by checkin-in the
fix...

Adding "want for mozilla 0.9" in the hope that this is the only problem for
"normal" Xlib-toolkit usage (except crashes when attempting to print...) - maybe
0.9 will be the first milestone where Xlib-toolkit is not busted...

Comment 9

[Roland Mainz]

Attachment: Patch for 2001-04-17-cvs to avoid crash at shutdown

Comment 10

[Roland Mainz]

Created quick hack fix - I assume that ev==nsnull is only true at shutdown.
Need r=/sr= ...

Comment 11

[Christopher Blizzard (:blizzard)]

I don't like it because it's hiding the real problem bug for the time I'll let
it get in the tree to fix the crash as long as you file a bug against yourself
to find the real cause.

r=blizzard

Comment 12

[Roland Mainz]

Attachment: Better patch for 2001-04-17-cvs to avoid crash at shutdown

Comment 13

[Roland Mainz]

Created new attachment based on blizzard's comment. Source now has reference to
bugid and some comments and code now uses an assert() to monitor this issue.

blizzard: Should I file a new bug to kill the real issue or should I simply
reuse this one ?

Comment 14

[Christopher Blizzard (:blizzard)]

Just use this one.  That patch looks fine.

Comment 15

[Robert O'Callahan (:roc) (email my personal email if necessary)]

a=roc+moz for 0.9 (on behalf of drivers)

Comment 16

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

sr=shaver.

Comment 17

[Roland Mainz]

Checked-in by bbaetz...
http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&file=nsClipboard.cpp&root=/cvsroot&subdir=mozilla/widget/src/xlib&command=DIFF_FRAMESET&rev1=1.10&rev2=1.11

Thanks !!

Comment 18

[Roland Mainz]

For some reason this bug still kills Mozilla at shutdown with
ev=={random_pointer} when widget/src/xlib/nsWidget.cpp is compiled with
optimisation... ouch...

Comment 19

[Roland Mainz]

Filed bug 91760 for the "crash at shutdown" issue...