Though there's the supplied patch in CVS meanwhile this might be of interest ... -- Alexander Mai [EMAIL PROTECTED]
Alexander, You wrote: > just trying to build an example showing the crash you mentioned yesterday. > I took some example as of test/Xm/tex with a text widget, write something like > for char i=255;i>0;i-- > in the widget and wait for the crash. It doesn't happen in this case. > Can you supply such a simple example? I don't have a simple example, unfortunately, but I have managed to characterize the problem a bit more. The problem only occurs for fonts where the 'default_char' attribute is bogus. In our app we're using "-*-helvetica-*-r-*-*-12-*-*-*-*-*-*-*" for most panels, but "-adobe-*-bold-r-normal-*-12-*-*-*-m-*" for the text widgets that display files. It's only for the adobe font that 'default_char' is dangerously bogus (it's 21904). For the helvetica font, 'default_char' is 32 and for "-b&h-lucidatypewriter-bold-r-normal-sans-12-120-*" 'default_char' is 0; this latter case is handled adequately by the existing hack in _XmTextNextX. This is all on a RedHat 6.2 box with a standard XFree86 3.3.6 installation. Second, the crash only occurs when fs->per_char[fs->default_char] is out of bounds in _XmTextNextX. Even when using the problematic adobe font (for which fs->default_char = 21904), I found that for some builds of the app accessing fs->per_char[21904] doesn't result in a seg fault. TomP ------------------------------------------------------------------------- Tom Pollard [EMAIL PROTECTED] Schrodinger, Inc. 201-433-2014 x102 -------------------------------------------------------------------------
