[comp.mail.sendmail] sendmail frozen config and Sun shared libraries

gamiddle@watmath.waterloo.edu (Guy Middleton) (06/05/91)

I just installed a new sendmail (5.65+IDA from DECWRL), and encountered the
strangest bug.

On a Sun, SunOS 4.1:

% sendmail -bz			# create frozen config file
% unlimit stacksize
% mail somebody@some.where.edu
% Who are you?			# getpwuid(getuid()) in conf.c fails

even better:
% unlimit stacksize
% sendmail -bz
% limit stacksize 8192
% mail somebody@some.where.edu
/usr/lib/sendmail: 8164 Memory fault
%

All of this works fine on other systems, and on a Sun if I compile without
shared libraries (using cc -Bstatic).  There is obviously some trick to
saving the data segment of a dynamically-linked program (as is done by
sendmail -bz).  Does anybody know what it is?

 -Guy Middleton, University of Waterloo		gamiddleton@watmath.waterloo.edu
		(+1 519 885 1211 x3472)		gamiddleton@watmath.uwaterloo.ca

phil@eecs.nwu.edu (William LeFebvre) (06/05/91)

In article <1991Jun4.173143.29157@watmath.waterloo.edu>, gamiddle@watmath.waterloo.edu (Guy Middleton) writes:

|> ...There is obviously some trick to
|> saving the data segment of a dynamically-linked program (as is done by
|> sendmail -bz).  Does anybody know what it is?

Yeah....don't do it.  :-)

Seriously, unless you have a long and complicated configuration file,*
freezing buys you very little.  Freezing used to be necessary on 
machines like VAXes and Sun 2's that took forever to do anything, but
I have found that on SPARC stations and even Sun 3's the performance
difference is usually negligible.

*Some people would claim that a sendmail configuration file is long
 and complicated by definition!

		William LeFebvre

casper@fwi.uva.nl (Casper H.S. Dik) (06/05/91)

gamiddle@watmath.waterloo.edu (Guy Middleton) writes:

>I just installed a new sendmail (5.65+IDA from DECWRL), and encountered the
>strangest bug.

[example deleted]

>All of this works fine on other systems, and on a Sun if I compile without
>shared libraries (using cc -Bstatic).  There is obviously some trick to
>saving the data segment of a dynamically-linked program (as is done by
>sendmail -bz).  Does anybody know what it is?

You can't reliably save the data segment of a dynamically linked
executable.

There are two reasons for this:

	o Parts of the data segment (the parts private to the library)
	  are mapped in memory at an unknown location.
	  (I don't know how a process can find all it's memory
	  mapped objects, except when digging in the kernel)
	
	o The first bit of the data segment contains the private information
	  of the runtime loader. One of the things stored here, the
	  procedure linkage table (plt), contains the addresses of the
	  resolved library functions. If you change the stack limit,
	  the library is mapped at a different location, and the addresses
	  filled in before the segment was dumped, are faulty.

If you want to dump the data segment (e.g. with undump or unexec), the
executable must be linked with -Bstatic

Casper
--
						|	Casper H.S. Dik
	RELIGION KILLS				|	casper@fwi.uva.nl