>Number:         1708
>Category:       bin
>Synopsis:       ldd(1) (i.e. ld.so aka rtld) goes crazy
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    bin-bug-people (Utility Bug People)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Oct 31 17:05:06 1995
>Last-Modified:
>Originator:     Thomas Eberhardt
>Organization:
CeVis, University of Bremen, Germany
>Release:        NetBSD-current 951031
>Environment:
	
System: NetBSD ed209 1.1_ALPHA NetBSD 1.1_ALPHA (ED209) #0: Sun Oct 29 05:46:28 MET 1995     thomas@ed209:/usr/src/sys/arch/i386/compile/ED209 i386

Machine: i386
>Description:
	ldd(1) prints garbage or crashes when given a binary that is
	linked with a shared library that depends on other libraries and
	the dependee (sp?) was also specified during linking, i.e.:

	/usr/local/lib/libtiff.so.3.4 was built with
	ldd -Bshareable -Bforcearchive -o libtiff.so.3.4 libtiff_pic.a \
		-L/usr/local/lib -ljpeg -lz

	and the program tiffinfo was built like this:

	gcc -o tiffinfo tiffinfo.o -L/usr/local/lib -ltiff -ljpeg -lz -lm

	then ldd produces something like the following:

	/usr/local/bin/tiffinfo:
	        -ltiff.3 => /usr/local/lib/libtiff.so.3.4 (0x1001b000)
	        -ld.6 => /usr/local/lib/libjpeg.so.6.0 (0x10048000)
	        -lrýÿP©rýÿPèô.0 => /usr/local/lib/libz.so.0.0 (0x10064000)
	        -lm.0 => /usr/lib/libm.so.0.1 (0x1006f000)
	        -lc.12 => /usr/lib/libc.so.12.3 (0x10082000)

	Applying the fix below produces:

	/usr/local/bin/tiffinfo:
	        -ltiff.3 => /usr/local/lib/libtiff.so.3.4 (0x1001b000)
	        -ljpeg.6 => /usr/local/lib/libjpeg.so.6.0 (0x10048000)
	        -lz.0 => /usr/local/lib/libz.so.0.0 (0x10064000)
	        -lm.0 => /usr/lib/libm.so.0.1 (0x1006f000)
	        -lc.12 => /usr/lib/libc.so.12.3 (0x10082000)

>How-To-Repeat:
	
>Fix:
	I haven't dived to deep into ld.so but came up with the following
	fix(?). If a library is already loaded map_object() returns the old
	link map and load_subs() overwrites the parent field that was
	already setup by the map_object() call that first loaded the library
	(in alloc_link_map()). Something gets messed up by the overwriting
	of the parent field so that ld_trace() later accesses wild memory
	during the printing of the shared object name. Sorry if this all
	sounds quite confusing, I think I still don't fully understand all
	of this.

*** rtld.c-	Sat Oct 14 01:33:32 1995
--- rtld.c	Tue Oct 31 22:01:20 1995
***************
*** 388,394 ****
  				newmap = alloc_link_map(NULL, sodp, smp, 0, 0);
  			}
  			LM_PRIVATE(newmap)->spd_refcount++;
- 			LM_PARENT(newmap) = smp;
  			next = sodp->sod_next;
  		}
  	}
--- 388,393 ----
>Audit-Trail:
>Unformatted: