gcmcnutt@mlsgcm.Ebay.sun.COM (Greg McNutt) (11/13/90)
After painstaking analysis and debug, I have discovered
the probably cause of the occasional xrn crashes that folks
have been seeing.
The following code fragment is from buttons.c in the function
setTranslations():
/*
* second and future times:
* install translations
*/
for (i = 0; i < sizeof(Translations) / sizeof(struct _translations); i++) {
if (Translations[i].tables[mode]) {
#ifdef DC
XtSetArg(args[0], XtNtranslations, Translations[i].tables[mode]);
XtSetValues(Translations[i].widget, args, XtNumber(args));
#else
XtOverrideTranslations(Translations[i].widget, Translations[i].tables[mode]);
#endif
}
}
}
As you can see, I have slightly altered the translations functionality
for subsequent mode switches.
Apparently, the various versions of Xt (typical) significantly alter
the way translation tables are handled. The current handling (through
fix 18) appears to free() resources on XtNtranslations type calls
which xrn is not set up to handle.
By using XtOverrideTranslations() instead, this symptom is circumvented
and data appears to be freshly allocated.
Of course, this is the typical dog chasing tail problem in that Xt is
changing as fast at xrn and they are *never* in sync.
The inernal characteristics of translation tables is loosely defined and
rapidly changing. I expect that my "band aid" will cease to function with
subsequent releases of Xt and xrn unless the developers can get in sync.
Give the fix a try and let me know if it too fixes your crash symptoms.
greg