Re: 21.2.20 crash
Marcus Thiessel wrote:
Never seen such a strange stack trace. I was pressing button1 to
drag
the scrollbar here and there.
#0 0xc01eb938 in kill () from /usr/lib/libc.2
#1 0xa0db8 in fatal_error_signal ()
#2 <signal handler called>
#3 0xc0f12ecc in () from /usr/lib/X11R6/libXt.3
#4 0xc0f3fa00 in CallSetValues () from /usr/lib/X11R6/libXt.3
#5 0xc0f3f9a8 in CallSetValues () from /usr/lib/X11R6/libXt.3
[repeated lines snipped]
#62 0xc0f3f9a8 in CallSetValues () from /usr/lib/X11R6/libXt.3
#63 0xc0f3ff8c in XtSetValues () from /usr/lib/X11R6/libXt.3
This is similar to what I would expect if the Widget's class had
itself as its superclass. From /usr/src/xc/lib/Xt/SetValues.c:
static Boolean CallSetValues (class, current, request, new, args,
num_args)
WidgetClass class;
Widget current, request, new;
ArgList args;
Cardinal num_args;
{
Boolean redisplay = FALSE;
WidgetClass superclass;
XtArgsFunc set_values_hook;
XtSetValuesFunc set_values;
LOCK_PROCESS;
superclass = class->core_class.superclass;
UNLOCK_PROCESS;
if (superclass)
redisplay =
CallSetValues(superclass, current, request, new, args, num_args);
The main question is why the looping terminates after 58 iterations.
Whether a stack overflow is a plausible reason depends upon the OS. On
Linux, infinite recursion normally results in a backtrace of several
thousand stack frames, but another platform may have a much smaller
stack.
--
Glynn Clements <glynn(a)sensei.co.uk>