Xref: utzoo comp.sys.att:12133 comp.mail.sendmail:3031
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!jarthur!uunet!comp.vuw.ac.nz!mark
From: mark@comp.vuw.ac.nz (Mark Davies)
Newsgroups: comp.sys.att,comp.mail.sendmail
Subject: Re: Sendmail-5.65+IDA-1.4.3 on AT&T 3B2
Message-ID: <1991Apr13.071422.4412@comp.vuw.ac.nz>
Date: 13 Apr 91 07:14:22 GMT
References: <1991Apr12.204413.9515@nmrdc1.nmrdc.nnmc.navy.mil>
Sender: news@comp.vuw.ac.nz (News Admin)
Organization: Dept. of Comp. Sci., Victoria Uni. of Wellington, New Zealand.
Lines: 38
Nntp-Posting-Host: the-taj.comp.vuw.ac.nz
Originator: mark@the-taj.comp.vuw.ac.nz


In article <1991Apr12.204413.9515@nmrdc1.nmrdc.nnmc.navy.mil>,
rdc30@nmrdc1.nmrdc.nnmc.navy.mil (LCDR Michael E. Dobson) writes:
|> I can get it to compile and link with only a few warnings about
|> int/pointer
|> combinations.  It works fine for resolving all sorts of addresses in
|> test
|> mode.  It can even send local mail to users on the host.  In daemon
|> mode
|> it can deliver incoming mail, although it attempts to send a failure
|> message
|> back to the originator.  However, attempts to send a message via
|> SMTP
|> fail during the fprintf() call in smtpmessage() while sending the
|> intial HELO
|> message.  I get a bus error -- core dump.  Using the debugger shows
|> the failure
|> is occuring in an internal floating point routine, e_mant2().

|> We suspect something is munging the values in the FILE structs *SmtpOut, 
|> *SmtpIn, **outfile and **infile, but have been unable to track it down.

I just came across the same problem building sendmail on an interactive box.
The fix is to dup() the socket descriptor "s" before doing the two
fdopens of outfile and infile.  It seems that these systems don't like
the file descriptors being shared.

Here's the patch (sorry its not a context diff, but its pretty simple).

	# diff daemon.c~ daemon.c
	499c499
	<       *infile = fdopen(s, "r");
	---
	>       *infile = fdopen(dup(s), "r");


cheers
mark