353 - Pressing ESC in font selection menu crashes Mozilla

Status: VERIFIED WONTFIX

(MozillaClassic Graveyard :: XFE, defect, P3)

Description

[Aleksey Nogin]

Created by Aleksey Nogin ([e-mail]) on Thursday, May 14, 1998 3:36:58 PM PDT
Additional Details :
Hi,

When I go to Preferences|Font menu, choose some encoding,
click to open the list of availiable fonts and instead of
selecting some font, press ESC, Mozilla segfaults (I tried
it 3 times, it crashed all 3 times):

(gdb) bt
#0  0x40138780 in ?? () from /usr/X11R6/lib/libXt.so.6
#1  0x8677d1c in fe_FontCharSets ()
#2  0x817cb43 in _ComboBoxKbdCancel (w=0x8938400,
event=0xbfffe504, params=0x0,
    num_params=0x8935868) at ComboBox.c:777
#3  0x4014b20f in ?? () from /usr/X11R6/lib/libXt.so.6
#4  0x4014b699 in ?? () from /usr/X11R6/lib/libXt.so.6
#5  0x4014bb90 in ?? () from /usr/X11R6/lib/libXt.so.6
#6  0x4012c70a in ?? () from /usr/X11R6/lib/libXt.so.6
#7  0x4012cfcf in ?? () from /usr/X11R6/lib/libXt.so.6
#8  0x4012d1ea in ?? () from /usr/X11R6/lib/libXt.so.6
#9  0x809ec47 in fe_EventLoop () at mozilla.c:1004
#10 0x80a1901 in main (argc=1, argv=0xbffff898) at
mozilla.c:3373

Versions:
Mozilla: CVS-19980514 (todays lates update from the public
CVS server)
Redhat 5.0, Linux 2.0.32, glibc-2.0.7-7, gcc-2.7.2.3-8,
lesstif-current of May 14.
Updated by Aleksey Nogin ([e-mail]) on Sunday, August 16, 1998 10:30:33 PM PDT
Additional Details :
The problem still exists with
Communicator CVS sources as of Sun Aug 16
RedHat Linux 5.1 - kernel 2.0.35
glibc-2.0.7-19
gcc-2.7.2.3-11
egcs-c++-1.0.2-8
lesstif-current-1998.08.14-1

I was told that this should be a Lesstif problem.
Updated by Felix  ([e-mail]) on Tuesday, August 18, 1998 3:17:22 PM PDT
Additional Details :
I've hunted this bug for some hours today as well, using Purify.
The weird thing about this is as follows:

* It only happens in the DtComboBoxWidgets. These are only used in the
preferences section, under Fonts. Pressing ESC while in the first ComboBox
(labeled "For the Encoding:") works fine. Pressing ESC in *any* of the other
ComboBoxes crashes Mozilla, and also Netscape Communicator 4.0.5 (haven't tried
it with other versions, but I suspect it's the same).

Could anyone help me out on this one? I'm not sure whether this would be a Motif
problem, since Aleksey is using Lesstif. Perhaps something in the initialization
is set wrong that causes all ComboBoxes after the first one to have this bug?

I'm using Sun's C compiler under Solaris 2.5.1. I've managed to track down the
following:

cmd/xfe/DtWidgets/ComboBox.c

(around line 780):

/*
 * osfCancel virtual key hit.
 */
static void
_ComboBoxKbdCancel(Widget w,
                   XEvent *event,
                   String *params,
                   Cardinal *num_params)
{
    DtComboBoxWidget combo;
    DtComboBoxPart *combo_p;
    XtPointer data;
    Arg args[1];

    /* Get combo-box off list data */
    XtSetArg(args[0], XmNuserData, &data);
    XtGetValues(w, args, 1);


    combo = (DtComboBoxWidget)data;

/*********** combo is not getting assigned correctly here!!!!!! */
    combo_p = (DtComboBoxPart*)&(combo->combo_box);

    combo_p->popped_up = FALSE;
/* FELIX */
if (!(combo_p->shell)) {
        fprintf (stderr, "WARNING: SHELL IS ZERO!!!!\n");
        fprintf (stderr, "combo_p->type = %d\n", combo_p->type);
fflush (stderr);
return;
}
/* END FELIX */
    XtPopdown(combo_p->shell);

Comment 1

[Felix]

I'VE FULLY ANALYZED THE PROBLEM.

The problem is that the ComboBox lib uses Motif's XmNuserData as a placeholder
for its parent widget. Unfortunately, XmNuserData is also being used by the
PrefsDialogHandler to store the pitch, thus overwriting the parent widget
poitner that was stored there earlier.

Here's the code.

cmd/xfe/DtWidgets/ComboBox.c, around line 590:

// This is where the XmNuserData is initially assigned

    n = 0;
    /* Store combo widget in list for later use */
    XtSetArg(args[n], XmNuserData, (XtPointer)new); n++;

[...]

    combo_p->list = XmCreateScrolledList(combo_p->frame, "List",
                                         args, n);



file cmd/xfe/src/PrefsDialogGeneral.cpp line 1566:

// This is where the definition is being overwritten

	XtVaSetValues(list, XmNuserData, pitch, NULL);


// Later on, Netscape (and Mozilla) CRASH with a SIGSEGV.


I am not 100% sure how to fix this, but have some ideas:

* first of all, is it really necessary to save the pitch information for the
list? It doesn't seem that this value is being used for anything (i.e. I can see
it being set but haven't found any code where this variable is being read
again). If it isn't really needed, we could fix the bug immediately by not
setting the pitch information in XmNuserData.

* Is there any other Motif variable name besides XmNuserData that we could use?
Then, we could use a completely new one for the ComboBox. I'm not experienced in
Motif programming, so I don't know how easy/difficult this would be.

Comment 2

[Aleksey Nogin]

As far as I understand, Felix has only found what causes this problem, but
nobody has checked in or even produced the fix, so this bug report should remain
opened.

Comment 3

[ramiro]

My hope is that we will stop using the DtComboBox and start using our own in
mozilla/cmd/xfe/XfeWidgets/XfeCombBox/ComboBox.c.

However, if this plan does not work out, then I will try to fix this bug
later...

Comment 4

[Felix]

Ramiro, I know that you don't like the ComboBox supplied, and yes, there are
quite some issues with it. However, the resolution would be to substitute only
two instances of "XmNuserData" with a different Motif variable/resource.

I think I could even go ahead and fix the problem, but then again, I'm pretty
new to Motif programming and wouldn't be sure which variable/resource to use
instead of XmNuserData. If you could choose one, changing those two instances
would be a snap.

Comment 5

[ramiro]

old code base.

marking wontix.

Comment 6

[leger]

Marking Verified/Won't Fix