Subject: Re: New sites for XFree86-2.0 shlib binaries
To: None <Mark_Weaver@brown.edu>
From: Bill Sommerfeld <sommerfeld@orchard.medford.ma.us>
List: current-users
Date: 12/01/1993 11:31:33
I tried running these, and got core dumps in all of the X toolkit
based code, looking like a NULL+constant pointer dereference somewhere
in libX11.so.

The binaries are all stripped, making the debugger not *all* that
useful, but..

backtrace:
(gdb) bt

#0  0x20f2258 in ?? (-37765204)
#1  0x20f230e in ?? ()
#2  0x20f3897 in ?? ()
#3  0x20f3c59 in ?? ()
#4  0x20f3f52 in ?? ()
#5  0x20f4049 in ?? ()
#6  0x20f41a3 in ?? ()
#7  0x20f4381 in ?? ()
#8  0x20d020c in ?? ()
#9  0x20d1011 in ?? (-37758428, -37758896, -37759296, -37757759, 34079205, -37758892, -37759288)
#10 0x20b0867 in ?? (-37758428, 190464, 84, 34083043, -37758432, 155720, 34083043)
#11 0x20811a8 in ?? ()
#12 0x207aac9 in ?? ()
#13 0x207ac99 in ?? ()
#14 0x20817c4 in ?? ()
#15 0x2904 in ?? ()
#16 0x109c in ?? ()


The faulting instruction in all of them seems to be:

		testb $<n>,1(%eax,%edx,1)

The instructions around the fault point:

0x20f224e:	cmpb   $0x0,(%ecx)
0x20f2251:	je     0x20f225f
0x20f2253:	movsbl (%ecx),%edx
0x20f2256:	movl   (%esi),%eax
0x20f2258:	testb  $0x8,1(%eax,%edx,1) <<< it died here
0x20f225d:	jne    0x20f2248
0x20f225f:	xorb   %al,%al
0x20f2261:	movl   -8(%ebp),%edi
0x20f2264:	cld    

Registers:

eax            0
ecx            0xfdbfbfac  -37765204
edx            0x00000023  35
ebx            0x02102060  34611296
esp            0xfdbfbf40  -37765312
ebp            0xfdbfbf54  -37765292
esi            0x00024058  147544
edi            0x0002405c  147548
eip            0x020f2258  34546264

1+0+35 = 36, which is not a valid pointer

Shared library memory map:

xterm:
	-lXaw.5 => /usr/X386/lib/libXaw.so.5.0 (0x2031000)
	-lXmu.5 => /usr/X386/lib/libXmu.so.5.0 (0x2060000)
	-lXt.5 => /usr/X386/lib/libXt.so.5.0 (0x2072000)
	-lXext.5 => /usr/X386/lib/libXext.so.5.0 (0x20ab000)
	-lX11.5 => /usr/X386/lib/libX11.so.5.0 (0x20b0000)
	-ltermcap.0 => /usr/lib/libtermcap.so.0.0 (0x2104000)
	-lc.1 => /usr/lib/libc.so.1.1 (0x2107000)
	-lXt.5 => /usr/X386/lib/libXt.so.5.0 (0x2150000)
	-lX11.5 => /usr/X386/lib/libX11.so.5.0 (0x2189000)

It seems at least somewhat odd that some libraries (X11, Xt) are
showing up twice.

My guess at the faulting routine would be the (static?) routine _rmblank
in XlcLoad.c:
	the pc of 0x020f2258 is between the -lX11 and -ltermcap libraries
	0x20f2258 - 0x20b0000 = 0x42258
	
the region around 0x42258 in an "nm -n" on libX11.so shows:

00042218 F XlcLoad.o
00042218 t ___gnu_compiled_c
00042218 t _rmblank			<---
00042218 t gcc2_compiled.
000422d8 t _Xfgetline
00042327 t LC0
0004232b t LC1
00042338 t _fgettoken
00042538 t _escape

The immediately preceding call is to 0x20f230e, which is consistant
with it being from Xfgetline, another static routine from the same
module.  I'm not going to bother doing any more stack frames of the
traceback, as I don't have XFree86 2.0 sources handy..
		

Any hints?  Which patches to ld.so could I have missed?

				- Bill

------------------------------------------------------------------------------