Submitted by Anonymous (not verified) on Fri, 06/15/2012 - 12:07
I have a (proprietary) Motif application which is crashing when built on
SuSE 9.0/SuSE 9.1/Fedora3 (at least). We've not been able to find out
if something is wrong it the app, so I am digging into a debug build of
Motif 2.2.2 on SuSE 9.1 (Opteron 64-bit). In the end we're ending
up near the end of ContainerConvertProc():
else if (cs->target == atoms[XmA_COMPOUND_TEXT])
{
type = atoms[XmA_COMPOUND_TEXT];
value = XmCvtXmStringToCT(return_xmstr);
length = strlen((char*) value);
}
XmStringFree(return_xmstr);
}
The call to XmCvtXmStringToCT is returning NULL for value, so the
call to strlen crashes. I'm not familiar at all with the inner workings
of OpenMotif, so I'm hoping that someone on this list can tell
whether this is indicative of an application error. In other files
I see that the return of XmCvtXmStringToCT is checked for NULL
correctly, and indeed performing this check seems to fix the crash
that we are seeing. If this is a Motif bug what is the proper
channel for having it patched?
Thanks for any suggestions or pointers..
-Dan
‹ Books on Motif Work with OpenMotif2.1.31 and don't work with OpenMotif2.2.3 ›
Tue, 12/07/2004 - 13:37#1
Crash in Container.c
I had a similar problem in an application I maintain. Some of our users use a PC with Hummingbird Exceed to access the UNIX systems. If our app was up and running in Exceed and they minimized Exceed and then maximized it again, our app died. When I looked at the core file, it was very similar to what you are describing. If I remember correctly (I'm not at work right now -- I'll repost if I find that this is wrong) I set the XmNprimaryOwnership resource of the XmContainer to XmOWN_NEVER and the problem went away. It looked like the window manager was trying to perform a conversion when the focus was brought back to our application by Exceed being maximized.
Mon, 02/07/2005 - 20:39#2
Crashing in ConvertContainerProc
I'm sorry for the late response but I haven't checked this message board in a while. I had this problem several months ago and posted the fix to the usenet group (comp.windows.x.motif).
It's due to a bug in the version of Motif you are linking with that has been reported to Bugzilla and supposedly fixed in Motif 2.1.30. You can work around it by defining a dummy conversion callback for the container. It's not a bug in application -- it's a bug in Motif. The workaround that I posted to usenet is below:
> > I have come up with a workaround to my problem that stops the crash
> > and wanted to add it to the newsgroup in case it helps anyone else in
> > similar misery:
> >
> > My container contains a set of icon gadgets that are selectable and
> > de-selectable. When an icon is selected, the container's
> > XmNconvertCallback() is
> > automatically called to handle any possible "data transfer" that is
> > intended.
> > The widget's convert callback (ContainerConvertProc) crashes if it
> > checks for
> > selected items in the container and doesn't find any since it assumes
> > it is called only when a selection is made. However, if the icon
> > gadgets are rapidly selected and de-selected a few times, it is
> > possible for the XmNconvertCallback to get called although nothing is
> > currently selected. This causes the crash.
> >
> > To avoid the problem altogether, I created my own dummy
> > XmNconvertCallback function that refuses to do the data conversion. I
> > can dummy this function because I don't use the "transfer" feature in
> > my gui program. In the convert function, it is necessary to set the
> > conversion status to XmCONVERT_REFUSE or else the widget's conversion
> > functions will still be called after the dummy function completes.
> >
> > Here's some sample code to illustrate:
> > icon_container = (Widget)XmCreateContainer(parent, "icon_container",
> > args, ac);
> > ...
> > XtAddCallback(icon_container, XmNconvertCallback, icon_convert_cb,
> > (XtPointer)NULL);
> >
> > Then the callback is:
> > void icon_convert_cb( Widget w, XtPointer client_data, XtPointer
> > call_data)
> > {
> > char func[] = "icon_convert_cb";
> > XmConvertCallbackStruct* ccs =
> > (XmConvertCallbackStruct*)call_data;
> >
> > /* refuse to allow ContainerConvertProc() to be called after this
> > */
> > if(ccs)
> > ccs->status = XmCONVERT_REFUSE;
> > } /* icon_convert_cb() */
> >
> > Hope this is helpful to someone in the future.
> > Julie
Mon, 02/07/2005 - 20:59#3
further background
As further background, I know my problem is identical to the one described because I debugged Container.c and crashed in the identical routine (XmCvtXmStringToCT) due to a strlen of 0. Here's the debug output:
(gdb) where
#0 0xb7500d33 in strlen () from /lib/tls/libc.so.6
#1 0x081bb2ab in ContainerConvertProc (wid=0x840f598, closure=0x0,
cs=0xbfff9770) at Container.c:5268
#2 0x0819b8e6 in _XmConvertHandler (wid=0x840f598,
selection=0xbfff99d8, target=0xbfff9828, type=0xbfff97f4,
value=0xbfff97f8,
size=0xbfff97fc, fmt=0xbfff9800) at Transfer.c:265
#3 0x08203f37 in GetConversion ()
#4 0x08204290 in HandleSelectionEvents ()
#5 0x081f5388 in XtDispatchEventToWidget ()
#6 0x081f5b8e in _XtDefaultDispatcher ()
#7 0x081f5e2e in XtDispatchEvent ()
#8 0x081ff422 in XtAppProcessEvent ()
#9 0x080749e2 in main (argc=1, argv=0xbfffa874) at main-c.c:418
The strlen() crashes because of value being 0x0 in the following
section of code:
5264 else if (cs->target == atoms[XmA_COMPOUND_TEXT])
5265 {
5266 type = atoms[XmA_COMPOUND_TEXT];
5267 value = XmCvtXmStringToCT(return_xmstr);
5268 length = strlen((char*) value);
5269 }
It appears that value is 0 because no items are selected in the
container:
item_count = 0
cw->container.selected_item_count = 0
items = GetSelectedCwids(wid); = 0
Here's a more exact description of the Motif bug from another poster:
The bug is in XmCvtXmStringToCT(). Or, to be more precise, in cvtXmStringToText(). This internal function does not handle empty strings properly. (These functions are in ResEncod.c) It has a loop like this:
to->addr = (XPointer)NULL;
while ((comp = XmeStringGetComponent( &stack_context, True, False, &len, &val)) != XmSTRING_COMPONENT_END )
{
...
}
But a '\0' character is what defines XmSTRING_COMPONENT_END, so the function returns with to->addr still initialized to NULL.
After checking for a NULL from->addr string, to->addr OUGHT to be set: to->addr = (XPointer)XtNewString("");
That said, the implementation in Container.c should have followed good coding practices by ALWAYS checking for NULL before passing a value to a function (strlen) that could crash on bad input. Actually, I think strlen should handle it gracefully and just return zero for a NULL input. This is like some implementations of free() that crash if you pass a NULL pointer.
Again, you can workaround this bug (and crash) by supplying a dummy conversion callback for the container.