[comp.mail.sendmail] Sendmail-5.65+IDA-1.4.3 on AT&T 3B2

rdc30@nmrdc1.nmrdc.nnmc.navy.mil (LCDR Michael E. Dobson) (04/13/91)

I have been attempting to do this port with assistance from Neil Rickert,
Paul Pomes and Mark Baushke, but with only limited success.  Has anyone
already done this?  If not, perhaps someone has some insight into the
following problem which has stymied the four of us.

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.

Hopefully someone out there on the net has seen this behavior and can provide
a fix.

The OS is AT&T SysVR3.2.2 w/ WIN/TCP 3.0 (4.2BSD socket compatibility library).

Thanks for any suggestions,
-- 
Mike Dobson, Sys Admin for      | Internet: rdc30@nmrdc1.nmrdc.nnmc.navy.mil
nmrdc1.nmrdc.nnmc.navy.mil      | UUCP:   ...uunet!mimsy!nmrdc1!rdc30
AT&T 3B2/600G Sys V R 3.2.2     | BITNET:   dobson@usuhsb or nrd0mxd@vmnmdsc
WIN/TCP for 3B2                 | MCI-Mail: 377-2719 or 0003772719@mcimail.com

mark@comp.vuw.ac.nz (Mark Davies) (04/13/91)

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

rdc30@nmrdc1.nmrdc.nnmc.navy.mil (LCDR Michael E. Dobson) (04/15/91)

In article <1991Apr13.071422.4412@comp.vuw.ac.nz> mark@comp.vuw.ac.nz (Mark Davies) writes:
>
>In article <1991Apr12.204413.9515@nmrdc1.nmrdc.nnmc.navy.mil>,
>rdc30@nmrdc1.nmrdc.nnmc.navy.mil (LCDR Michael E. Dobson) writes:

[most of the desription of my problem deleted]

>|> 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");
>
>
BINGO!!  I applied the patch and the mail gets through!

Thanks^1000!

What's even more interesting, this trick is used a little earlier in the
code with the socket descriptor "t" .  Guess I should have spent some more
time studying the code :-)
-- 
Mike Dobson, Sys Admin for      | Internet: rdc30@nmrdc1.nmrdc.nnmc.navy.mil
nmrdc1.nmrdc.nnmc.navy.mil      | UUCP:   ...uunet!mimsy!nmrdc1!rdc30
AT&T 3B2/600G Sys V R 3.2.2     | BITNET:   dobson@usuhsb or nrd0mxd@vmnmdsc
WIN/TCP for 3B2                 | MCI-Mail: 377-2719 or 0003772719@mcimail.com