30120 - Crash at closing Composer window in JA locale

Status: VERIFIED FIXED

(Core :: Internationalization, defect, P3)

Description

[Teruko Kobayashi]

When you lose Composer window in JA locale, Mozilla will crash.

Steps of reproduce
1. setenv LANG to ja
2. launch mozilla
3. open Composer
4. turn on IME and type Japanese characters
5. close the composer by clicking close button at the right top corner of window

It will crash.  Tested 2000030209 Linux build.

Talkback incident ID 6195840

 Trigger Type:  Program Crash 

 Trigger Reason:  SIGSEGV: Segmentation Fault: (signal 11) 

 Call Stack:    (Signature = libX11.so.6 + 0x75b2a (0x406ecb2a) 7d5a9eca) 
     libX11.so.6 + 0x75b2a (0x406ecb2a) 
     libX11.so.6 + 0x75eea (0x406eceea) 
     libX11.so.6 + 0x762d7 (0x406ed2d7) 
     libX11.so.6 + 0x763f8 (0x406ed3f8) 
     libX11.so.6 + 0x64e51 (0x406dbe51) 
     libX11.so.6 + 0x4745b (0x406be45b) 
     libgdk-1.2.so.0 + 0x19d8f (0x40634d8f) 
     nsIMEGtkIC::~nsIMEGtkIC() 
     nsWidget::IMEDestroyIC() 
     nsWindow::DestroyNative() 
     nsWidget::Destroy() 
     nsWindow::~nsWindow() 
     nsBaseWidget::Release() 
     nsWidget::Release() 
     nsWindow::Release() 
     nsCOMPtr_base::~nsCOMPtr_base() 
     nsXULWindow::ShowModal() 
     nsWebShellWindow::ShowModal() 
     nsChromeTreeOwner::ShowModal() 
     GlobalWindowImpl::OpenInternal() 
     GlobalWindowImpl::OpenDialog() 
     nsCommonDialogs::DoDialog() 
     nsEditorShell::ConfirmWithCancel() 
     nsEditorShell::CheckAndSaveDocument() 
     XPTC_InvokeByIndex() 
     nsXPCWrappedNativeClass::CallWrappedMethod() 
     WrappedNative_CallMethod() 
     js_Invoke() 
     js_Interpret() 
     js_Invoke() 
     js_Interpret() 
     js_Invoke() 
     js_InternalInvoke() 
     JS_CallFunctionValue() 
     nsJSContext::CallEventHandler() 
     nsJSEventListener::HandleEvent() 
     nsEventListenerManager::HandleEventSubType() 
     nsEventListenerManager::HandleEvent() 
     GlobalWindowImpl::HandleDOMEvent() 
     nsWebShellWindow::ExecuteCloseHandler() 
     nsWebShellWindow::HandleEvent() 
     nsWidget::DispatchEvent() 
     handle_delete_event() 
     libgtk-1.2.so.0 + 0xea79d (0x405f279d) 
     libgtk-1.2.so.0 + 0xb2037 (0x405ba037) 
     libgtk-1.2.so.0 + 0xb152f (0x405b952f) 
     libgtk-1.2.so.0 + 0xaf800 (0x405b7800) 
     libgtk-1.2.so.0 + 0xe25b8 (0x405ea5b8) 
     libgtk-1.2.so.0 + 0x86320 (0x4058e320) 
     handle_gdk_event() 
     libgdk-1.2.so.0 + 0x16ab2 (0x40631ab2) 
     libglib-1.2.so.0 + 0xf2c6 (0x4065b2c6) 
     libglib-1.2.so.0 + 0xf801 (0x4065b801) 
     libglib-1.2.so.0 + 0xf979 (0x4065b979) 
     libgtk-1.2.so.0 + 0x85f3a (0x4058df3a) 
     nsAppShell::Run() 
     nsAppShellService::Run() 
     main1() 
     main() 
     libc.so.6 + 0x17cb3 (0x40220cb3)

Comment 1

[Teruko Kobayashi]

This is very bad behavior, so I put the beta1 in keywords.

Comment 2

[Hidetoshi Tajima]

I followed the steps, but could not reproduce the
problem. Teruko-san, my environment is redhat6.1
Linux, and gtk+ version is 1.2.6. Any difference
from yours?

Comment 3

[Hidetoshi Tajima]

I followed the steps, but could not reproduce the
problem. Teruko-san, my environment is redhat6.1
Linux, and gtk+ version is 1.2.6. Any difference
from yours?

Comment 4

[ji]

Tajima-san, the environment we use to reproduce the bug is 
Red Hat 6.0 + Japanese package, I'm not sure about the gtk+ version,
I'm asking our release engineer but haven't got the reply yet.

Comment 5

[Hidetoshi Tajima]

please run 'gtk-config --version' command, and send
me the output.

Comment 6

[ji]

The output of gtk-config is 1.2.1.

Comment 7

[ji]

According to leaf, the gtk+ version for linux build is 1.2.5.

Comment 8

[Hidetoshi Tajima]

Thanks, I'll look into the problem again with 1.2.5
glib and gtk+.

Comment 9

[Phil Peterson]

per PDT, if this problem is widespread, it might bde PDT+, but if not, it would 
be PDT-. Please let us know which it is.

Comment 10

[ji]

It can be reproduced on 3 out of 5 machines here. 

Comment 11

[Hidetoshi Tajima]

Any difference between the 3 machines and the rest
of the 2, such as in Linux distrubition, type of IME,
gtk version. libX11.so version, or Mozilla build?
Please let me know if I can visit you sometime next
week to look at them.

Comment 12

[ji]

All the three machines on which we CAN reproduce the crash are RH6.0 + Japanese
package. Another two  on which we CAN'T reproduce: one is RH6.0 + JPN package,
the other is RH6.1 + JPN package. There is 6th machine which is also RH6.0 + JPN 
package and we can't reproduce the crash on it either.

Comment 13

[ji]

Tajima-san, we are happy to show you the problem anyday nextweek.

Comment 14

[leger]

Putting on PDT+ radar for fix by 03/10

Comment 15

[Frank Tang]

I can reproduce this in my private build now. I will try to debug it.

Comment 16

[Frank Tang]

Here is my stack trace...
#0  0x40942b2a in _XimXGetReadData ()
#1  0x40942eea in _XimXRead ()
#2  0x409432d7 in _XimReadData ()
#3  0x409433f8 in _XimRead ()
#4  0x40931e51 in _XimProtoDestroyIC ()
#5  0x4091445b in XDestroyIC ()
#6  0x4088ad8f in gdk_ic_destroy ()
#7  0x40725b53 in nsIMEGtkIC::~nsIMEGtkIC (this=0x8b41a88, __in_chrg=3)
    at nsGtkIMEHelper.cpp:916
#8  0x4071d6f8 in nsWidget::IMEDestroyIC (this=0x8a54380) at nsWidget.cpp:3400
#9  0x4071eab7 in nsWindow::DestroyNative (this=0x8a54380) at nsWindow.cpp:214
#10 0x40716f6c in nsWidget::Destroy (this=0x8a54380) at nsWidget.cpp:434
#11 0x4071e961 in nsWindow::~nsWindow (this=0x8a54380, __in_chrg=3)
    at nsWindow.cpp:162
#12 0x40726af5 in nsBaseWidget::Release (this=0x8a54380) at nsBaseWidget.cpp:46
#13 0x40716dce in nsWidget::Release (this=0x8a54380) at nsWidget.cpp:368
#14 0x4071e79e in nsWindow::Release (this=0x8a54380) at nsWindow.cpp:101
#15 0x402d1bb4 in nsCOMPtr<nsIWidget>::~nsCOMPtr (this=0xbfffc840, __in_chrg=2)
    at ../../dist/include/nsCOMPtr.h:434
#16 0x40652594 in nsXULWindow::ShowModal (this=0x8a54248)
    at nsXULWindow.cpp:317
#17 0x4065e1ee in nsWebShellWindow::ShowModal (this=0x8a54248)
    at nsWebShellWindow.cpp:1111                                      

(gdb) frame 7
#7  0x40725b53 in nsIMEGtkIC::~nsIMEGtkIC (this=0x8b41a88, __in_chrg=3)
    at nsGtkIMEHelper.cpp:916
916         gdk_ic_destroy((GdkIC *) mIC);
Current language:  auto; currently c++
(gdb) list
911         delete mPreedit;
912       }
913
914       if (mIC) {
915         // destroy a real XIC
916         gdk_ic_destroy((GdkIC *) mIC);
917       }
918
919       if (mIC_backup) {
920         // destroy a dummy XIC, see the comment in nsIMEGtkIC constructor.
(gdb) frame 7
#7  0x40725b53 in nsIMEGtkIC::~nsIMEGtkIC (this=0x8b41a88, __in_chrg=3)
    at nsGtkIMEHelper.cpp:916
916         gdk_ic_destroy((GdkIC *) mIC);
(gdb) print *mIC
$4 = {xic = 0x8b49c08, attr = 0x8b49b80, mask = GDK_IC_ALL_REQ}
(gdb)                      
                          (gdb) print *mIC->attr
$6 = {style = 514, client_window = 0x8a548e0, focus_window = 0x0,
  filter_events = 0, spot_location = {x = 0, y = 14}, line_spacing = 0,
  cursor = 0x0, preedit_fontset = 0x832c980, preedit_area = {x = 0, y = 0,
    width = 0, height = 0}, preedit_area_needed = {x = 0, y = 0, width = 0,
    height = 0}, preedit_foreground = {pixel = 0, red = 0, green = 0,
    blue = 0}, preedit_background = {pixel = 0, red = 0, green = 0, blue = 0},
  preedit_pixmap = 0x0, preedit_colormap = 0x813eb08, status_fontset = 0x0,
  status_area = {x = 0, y = 0, width = 0, height = 0}, status_area_needed = {
    x = 0, y = 0, width = 0, height = 0}, status_foreground = {pixel = 0,
    red = 0, green = 0, blue = 0}, status_background = {pixel = 0, red = 0,
    green = 0, blue = 0}, status_pixmap = 0x0, status_colormap = 0x0}
(gdb) print *mIC->xic
$7 = <incomplete type>         
        (gdb) frame 8
#8  0x4071d6f8 in nsWidget::IMEDestroyIC (this=0x8a54380) at nsWidget.cpp:3400
3400        delete mXIC;
(gdb) list
3395    void
3396    nsWidget::IMEDestroyIC()
3397    {
3398      if (!mXIC) return;
3399      if (mICPerShell == PR_FALSE || mIsToplevel == PR_TRUE) {
3400        delete mXIC;
3401      }
3402      mXIC = 0;
3403    }
3404
(gdb) print mICPerShell
$8 = 1
(gdb) print mIsToplevel
$9 = 1

Comment 17

[Frank Tang]

more finding, still in frame 8

(gdb) print this
$10 = (nsWidget *) 0x8a54380
(gdb) print *this
$11 = {<nsBaseWidget> = {<nsIWidget> = {<nsISupports> = {
        _vptr. = 0x4074ea00 <nsWindow virtual table>}, }, mRefCnt = 1,
    _mOwningThread = 0x8058bd8, mClientData = 0x8a54248,
    mEventCallback = 0x4065a188 <nsWebShellWindow::HandleEvent(nsGUIEvent *)>,
    mContext = 0x8a54608, mAppShell = 0x807a068, mToolkit = 0x8a544e0,
    mMouseListener = 0x0, mEventListener = 0x0, mMenuListener = 0x0,
    mBackground = 4290822336, mForeground = 0, mCursor = eCursor_standard,
    mWindowType = eWindowType_dialog, mBorderStyle = eBorderStyle_default,
    mIsShiftDown = 0, mIsControlDown = 0, mIsAltDown = 0, mIsDestroying = 1,
    mOnDestroyCalled = 0, mBounds = {x = 0, y = 0, width = 552, height = 80},
    mZIndex = 0, mChildren = {
      mRawPtr = 0x8a54498}}, <nsIKBStateControl> = {<nsISupports> = {
      _vptr. = 0x4074e9cc <nsWindow::nsIKBStateControl virtual table>}, },
  mIsToplevel = 1, static debugWidget = 0x0, static sDebugFeedback = 0,
  mHasFocus = 0, static focusWindow = 0x0, mIsDragDest = 0, mIMEEnable = 1,
  mIMEIsDeactivating = 0, static gPreeditFontset = 0x832c980,
  static gStatusFontset = 0x862dd30, static gInputStyle = 514,
  mXIC = 0x8b41a88, mIMECallComposeStart = 0, mIMECallComposeEnd = 1,
  mIMEShellWidget = 0x0, mICPerShell = 1, mICSpotTimer = 0x0,
  mXICFontSize = 0, mIMECompositionUniString = 0x0,
  mIMECompositionUniStringSize = 0, mGrabTime = 0, mWidget = 0x0,
  mMozBox = 0x0, mParent = {mRawPtr = 0x86b0de0}, mUpdateArea = 0x8a544c8,
  mShown = 0, mPreferredWidth = 0, mPreferredHeight = 0,
---Type <return> to continue, or q <return> to quit---
  mListenForResizes = 0, static gRollupListener = {mRawPtr = 0x0},
  static gRollupWidget = {mRawPtr = 0x0},
  static gRollupConsumeRollupEvent = 1, static sLastEventTime = 3327377699,
  static sLookAndFeel = 0x8193498, static sWidgetCount = 41,
  static mGDKHandlerInstalled = 1, static mTimeCBSet = 1,
  static sButtonMotionTarget = 0x0, static sButtonMotionRootX = -1,
  static sButtonMotionRootY = -1, static sButtonMotionWidgetX = 249,
  static sButtonMotionWidgetY = 68}
(gdb)                                      
Notice the mWindowType = eWindowType_dialog.  I crash AFTER I click the "close"
button of the composer and AFTER I click "NO" in the "Do you want to save this
document" dialog box . I think the trigger is NOT the composer window closing ,
but the dialog box closing. 

Comment 18

[Hidetoshi Tajima]

Frank, it sounds wrong to create XIC for the dialog
box widget as it does not have any input field. In
the current implementation, XIC is created in 
nsWidget::ResetInputState(). We'd better check why
ResetInputState() is called for that dialog widget.

Comment 19

[Masaki Katakai]

We probably meet two problems now,

  1) XDestroyIC() causes dumps core in Xlib

  2) ResetInputState() is called on the dialog
     that makes XIC and it will be destroyed at
     closing dialog

Yes, problem 2) causes 1). And it would be hard to fix 1).

I found that the dialog creates NS_FORM_INPUT_PASSWORD forms
on it. (Is that correct behavior?) Eventually, creating
NS_FORM_INPUT_PASSWORD form calls ResetInputState() that
creates a XIC. That is problem. This problem was originally
reported as 16940.

 16940: need an XP API to disable input methods
        for password fields

I have already attached the patch for 16940 as the 2nd
patch of 17419. I hope it can fix this problem.
But, I'll create new patch that just prevents
nsEditor calling ResetInputState() for your testing.
These codes are part of the 2nd patch of 17419.

(because the patch requires changing xp interface so
we can't integrated the whole changes to beta1.
See Frank's comment on 2000-03-08 12:37)

Please try the patch on your environment Redhat 6.0.

Comment 20

[Masaki Katakai]

Attachment: codes from a patch of 16940

Comment 21

[bobj]

ftang pls review asap.  pls run pre-checkin tests.  if all ok, a=bobj.

Comment 22

[Frank Tang]

To minimize the risk, I preferred to wrap the patch with #ifdef XP_UNIX

Comment 23

[Frank Tang]

I will build and run this after I arrive office. For beta1, we only need to 
latest patch along to fix it, right ? Since tajima/katakai cannot reproduce 
this, I will verify and check in if it fix the problem.

Comment 24

[bobj]

There is only one attachment (from 03/08/00 22:07) attached to this bug.
I assumed that was the one intended for Beta1:

Index: mozilla/editor/base/nsEditor.cpp
===================================================================
RCS file: /cvsroot/mozilla/editor/base/nsEditor.cpp,v
retrieving revision 1.248
diff -c -r1.248 nsEditor.cpp
*** mozilla/editor/base/nsEditor.cpp    2000/02/16 01:36:24     1.248
--- mozilla/editor/base/nsEditor.cpp    2000/03/09 05:24:59
***************
*** 1696,1701 ****
--- 1696,1706 ----
      return NS_OK;
  #endif
  
+   // don't need to call ResetInputState if passwd field
+   if (mFlags & nsIHTMLEditor::eEditorPasswordMask) {
+     return NS_OK;
+   }
+ 
    nsresult res = NS_OK;
    nsCOMPtr<nsIPresShell> shell;

And from ftang's last comment, I assume this change will be wrapped with
#ifdef XP_UNIX.

ftang, after testing, pls go ahead and check-in for tajima.  a=bobj. Thanks.

Comment 25

[Frank Tang]

The proposed patch is not good. We hit the nsEditor constructor twice when we
bring up the "Do you want to save this document "  dialogbox. That dialog box
have one picture, one label and 3 button you can see but no text field so it is
very strange . I talk to sfrazer in the editor group about this. He said they
reuse dialogbox and hide two password field hidden somewhere ( in some x,y not
visible in the window) so we hit the nsEditor twice. 

That is the reason why katakai hit password field, it is not the dialogbox
itself have that attribute. Therefore, the cause is hidden text field which
could be password OR not password field. 

tajima ask me to look at the gdk_im_begin. It seems the gdk_im_begin never get
called for the problem ic. tajima say the gdk_im_begin is the code which
initialize the focus window field of the xic and could cause the problem if we
do not call gdk_im_begin before the gdk_ic_destory. 

Comment 26

[Frank Tang]

I backup my comment. The last patch is good because password field have special 
construction than the normal text field.

The dialog box caused the crash is in 
xpfe/global/resources/content/commonDialog.xul
There are one input type=text and two input=password. When I set a break point 
in nsEditor::nsEditor(), it somehow only break twice instead of three time. And 
the reason is the code in layout/html/forms/src/nsGfxTextControlFrame.cpp
2205         if ((PR_FALSE==IsSingleLineTextControl()) || 
(NS_FORM_INPUT_PASSWORD == type))
2206         { // password controls and multi-line text areas get their subdoc 
right away
2207           rv = CreateSubDoc(&subBoundsInPixels);
2208         }
2209         else if (mDisplayFrame)

while the input=text will skip to the else while the input=password will hit 
2207. 

Therefore, the problem is not a generic text field problem. I think we should 
check in katakai's change for beta1 and investigate what will happen for 
multiline text field. 

Comment 27

[bobj]

ftang has determined that the proposed fix will work for Beta1.
He will check this in to the branch and trunk after the carpools are completed.

Comment 28

[Jim Roskind]

Carpools are complete... Please update the status whiteboard with a landing date.
Thanks,
Jim

Comment 29

[bobj]

ETA by Monday if tree is open.

Comment 30

[Frank Tang]

check in for tajima . check into branch as 1.149.2.1 check in to tip as 1.151

Comment 31

[ji]

Verified with linux 03-13-03-M15-nb1b build. It is fixed.