[16963] in Athena Bugs
zwgc coredump
daemon@ATHENA.MIT.EDU (Greg Hudson)
Wed Jul 21 15:51:17 1999
Message-Id: <199907211951.PAA08164@small-gods.mit.edu>
To: bugs@MIT.EDU
Cc: marc@MIT.EDU
Date: Wed, 21 Jul 1999 15:51:06 -0400
From: Greg Hudson <ghudson@MIT.EDU>
Kevin Mitchell produced a zwgc core dump today on a sun4 system
(all-night-tool). He says he had dragged out a cut area in a
zephyrgram and was dragging out a new one. Here's the gdb command
giving the relevant zwgc binary and core file:
gdb /afs/dev/project/release/8.2/build/sun4x_56/athena/lib/zephyr/zwgc/zwgc /mit/coredumps/core.zwgc.sun4.klmitch
and here's the stack trace:
#0 0xef4e432c in __doscan_u () from /usr/lib/libc.so.1
#1 0x30120 in xmarkGetText () at xmark.c:380
#2 0x275f4 in xcut (dpy=0x78770, event=0xeffff150, desc_context=-1) at xcut.c:286
#3 0x2479c in xhandleevent (dpy=0x78770, w=83886535, event=0xeffff150) at xshow.c:551
#4 0x24820 in x_get_input (dpy=0x78770) at xshow.c:575
#5 0x24bd0 in mux_loop () at mux.c:187
#6 0x1fce8 in main (argc=1, argv=0xeffff39c) at main.c:275
There's a missing frame in there for string__CreateFromData(), which
is being passed a totally bogus pointer by xmark.c. Basically, in
xmarkGetText(), endblock is 59 and markgram->blocks is 8, so as soon
as the loop counter hits 8 it looks at markgram->blocks[8] for an
index and length, and of course gets garbage.
Obviously I could add a check to the for loop to avoid overrunning
markgram->blocks, but I'd like to know how endblock got set to such a
bogus value, especially if the previously selected cut region was from
the same windowgram.
