johnm@auscso.UUCP (John B. Meaders) (09/29/87)
I had trouble getting smail2.5 (recent release) to run on my Compaq
Deskpro. The first time I ran it I got a panic and had to power down.
I remade the package and ran again and was rewarded with a core dump.
I looked at the dump and saw a lot of references to malloc. In the
Makefile there is a comment that System V.2 sites can use -lmalloc
for a faster malloc. I naturally had been using that library. After
seeing the references to malloc in the core dump, I commented out
the LIBS statement in the Makefile. I was rewarded with a successful
running of smail2.5. The deliver.c and alias.c modules complain about
different levels of indirection at compile time (only warning 47), but
this doesn't seem to hinder operation of the package. I had problems
with smail2.3 which could probably be solved by the same method.
I used CFLAGS = -O -s.
--
John B. Meaders, Jr. 1114 Camino La Costa #3083, Austin, TX 78752
ATT: Voice: +1 (512) 451-5038 Data: +1 (512) 371-0550
UUCP: ...!ut-sally!ut-ngp!auscso!jclyde!john
\johnmmjy@sdti.UUCP (09/30/87)
In article <398@auscso.UUCP> johnm@auscso.UUCP (John B. Meaders, Jr.) writes: >I had trouble getting smail2.5 (recent release) to run on my Compaq >Deskpro.... > [text about having tracked it down to use of malloc(3X) deleted] Gee, I guess Microport isn't the only AT unix to have a buggy malloc(3X)! Microport's fix for the problem is "use malloc(3C) instead." "Doctor, it hurts when I do this." "Well, don't do that." -- Mike Young - Software Development Technologies, Inc., Sudbury MA 01776 UUCP : {decvax,harvard,linus,mit-eddie}!necntc!necis!mrst!sdti!mjy Internet : mjy%sdti.uucp@harvard.harvard.edu Tel : +1 617 443 5779
guy%gorodish@Sun.COM (Guy Harris) (10/01/87)
> Gee, I guess Microport isn't the only AT unix to have a buggy malloc(3X)! > Microport's fix for the problem is "use malloc(3C) instead." Is it that malloc(3X) is buggy, or that it's SVID-compliant? There are a number of programs ("dc" comes to mind) that will compute the size of a block of memory that they need and, even if it's zero, call "malloc" with that size. The SVID specifies that this must return a NULL pointer, not a "pointer to a zero-length block of memory" (in most, possibly all, implementations of "malloc", you *can*, in a sense, get a pointer to a zero-length block of memory - what "malloc" really allocates is a control header followed by the block of storage, and the pointer it returns is to the first memory location after the header). Many C implementations will cause a program to bomb if it tries to use a NULL pointer as if it pointed to something (I've even seen this on VAXes with UNIX versions that provide a location 0, kids; attempts to *write* to low addresses blow up, as this is part of the text segment). Could this be the problem? Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com
mjy@sdti.UUCP (10/02/87)
In article <29699@sun.uucp> guy%gorodish@Sun.COM (Guy Harris) writes: >Is it that malloc(3X) is buggy, or that it's SVID-compliant? No, it's buggy. The core dumps come from within malloc(3x) itself. Microport is aware of the problem, but they don't seem to be anxious to fix it. I don't think they even plan on fixing it in their next release (2.3). They just say, "Workaround: Try using malloc(3c)". They must be understaffed. Doesn't sound like that hard a problem to fix. It's certainly easy to duplicate the symtoms :-). -- Mike Young - Software Development Technologies, Inc., Sudbury MA 01776 UUCP : {decvax,harvard,linus,mit-eddie}!necntc!necis!mrst!sdti!mjy Internet : mjy%sdti.uucp@harvard.harvard.edu Tel : +1 617 443 5779
gwyn@brl-smoke.UUCP (10/04/87)
In article <135@sdti.UUCP> mjy@sdti.UUCP (0000-Michael J. Young) writes: >In article <29699@sun.uucp> guy%gorodish@Sun.COM (Guy Harris) writes: >>Is it that malloc(3X) is buggy, or that it's SVID-compliant? >No, it's buggy. The core dumps come from within malloc(3x) itself. That doesn't prove that malloc() is at fault -- if your application has corrupted the arena block control headers that the malloc package uses, then eventually malloc() or free() can die horribly. However, it is true that every malloc implementation I've yet seen has been non-portable, and some downright broken. I thoroughly overhauled malloc.c 1.5 in order to fix it for ports of my System V emulation for 4.nBSD. Perhaps some UNIX vendors, preferably AT&T, should "buy back" the improvements.
marcos@caus-dp.UUCP (Marcos R. Della) (10/27/87)
I have been trying to install a copy of smail2.3 on my intel 310 system
(80286 processor) and have not had too much luck. I'm using an old copy
of pathalias and smail and was wondering if someone out there could email
me a copy of the newest versions of these two programs...
Thanks for any help that you can provide!
Marcos R. Della
--
...!lll-crg -> !csustan -\ | Whatever I said doesn't
...!sdsu ----->->!polyslo!caus-dp!marcos | mean diddly as I forgot
...!ihnp4 -> !csun ----/ | it even before finishing
...!dmsd ---/ | typing it all out!!!bob@rel.UUCP (11/27/87)
During the last several weeks there have been numerous solutions posted to
the net to resolved the interface problem with Xenix and smail 2.5. I
have tried all the solutions that I am aware of and my conclusion for the
best approach is a combination of two.
The first problem that you'll encounter if you follow the smail installation
docs is when you use Xenix mail for the local mailer in smail. The most
obvious thing you'll notice is double headers, since SCO "enhanced" mail to
work better in the Xenix environment. With two From: lines, SCO's mail will
almost always pick the wrong one to reply to when reading mail.
Here's solution number one:
Install Jon Zeeff's (jon@b-tech) lmail for your local mailer. I defined
lmail in defs.h (smail) to be /usr/lib/mail/lmail.
This eliminated the double headers and allowed SCO's mailer to properly
reply to all mail. The only problem with this solution is that you
have to use the smail svbinmail to originate mail and SCO's mail to
read mail. Also, I kinda got use to SCO mail's "enhanced" features that
were missing is svbinmail.
Solution number two:
Chip Salzenburg (chip@ateng) had an idea to substitute smail for SCO's execmail.
The first step was to "set execmail" in /usr/lib/mail/mailrc. Then substitute
Chip's execmail replacement for the real execmail. He also used SCO's
execmail for the local mailer.
The main advantage here was that you could now use domain style addressing
from within SCO's mailer. However, I still encounter one small problem.
The From: address was the process name (typically uucp) not the address
of the sender. This was caused by using execmail as the local mailer.
Final Solution:
Here's the solution that I'm using now and seems to work fairly well. If
anyone sees any problems, I would appreciate hearing your comments.
don't use svbinmail
use Jon Zeeff's lmail program, define lmail in smail to point here
add "set execmail" to your mailrc
use Chip Salzenburg's program to replace /usr/lib/mail/execmail
put smail where ever you defined it in defs.h
remove SCO's rmail
ln smail to rmail
This will allow you to use SCO's mailer to send an receive mail using
rfc976 style addresses.
I choose not to include the source for these programs since they are quite
large. If you are interested, I would contact either Jon or Chip directly,
or myself for a copy of the code. The only restriction is that you leave
the author's copyright intact when using the program.
I might add the Jon's lmail program also adds fowarding of mail boxes plus
fowarding to other programs.
--
Bob Leffler - Electronic Data Systems, GM Truck & Bus Account
bob@rel.EDS.COM or {cbosgd!edstb!edsdrd, mibte!fmsrl7}!rel!bob
Opinions expressed may not be those of my employer.chip@ateng.UUCP (Chip Salzenberg) (12/01/87)
In article <484@rel.eds.com> bob@rel.eds.com (Bob Leffler) writes: > >Chip Salzenburg (chip@ateng) had an idea to substitute smail for SCO's ^That's me^ >execmail. The first step was to "set execmail" in /usr/lib/mail/mailrc. >Then substitute Chip's execmail replacement for the real execmail. >He also used SCO's execmail for the local mailer. [Note that execmail is renamed, and this renamed execmail is used by smail for local mail.] >The main advantage here was that you could now use domain style addressing >from within SCO's mailer. Bob omits two other advantages of my solution: 1. The standard Xenix aliasing mechanism works, including pipe aliases such as `rnews: |/u/news/uurec'. (I have SENDMAIL undefined, so I have two alias files; Xenix aliases cannot be `@' addresses.) 2. Xenix-net (micnet) mail works. ("machine:user") The `mail.local' program is only for local mail; there is a separate program `mail.cln' for colon addresses. Execmail calls one or the other. >However, I still encounter one small problem. >The From: address was the process name (typically uucp) not the address >of the sender. This was caused by using execmail as the local mailer. My system does _not_ have this problem! Here is a sample header: From major!nix Tue Dec 1 12:54:22 1987 Received: by ateng.UUCP (smail2.5) id AA00212; 1 Dec 87 12:54:14 EST (Tue) Received: by major.UUCP (smail2.5) id AA00214; 1 Dec 87 12:51:40 EST (Tue) To: topedit Date: Tue, 1 Dec 87 12:51:38 EST Subject: Richard Stuer phone call Cc: nix X-Mailer: Elm [version 1.5] Message-Id: <8712011251.AA00214@major.UUCP> From: nix@major.UUCP (Nixdorf Proj Admin) (BTW, `topedit' is an alias that includes me.) I will be posting relevant files in a separate article. -- Chip Salzenberg "chip@ateng.UUCP" or "{codas,uunet}!ateng!chip" A T Engineering My employer's opinions are not mine, but these are. "Gentlemen, your work today has been outstanding. I intend to recommend you all for promotion -- in whatever fleet we end up serving." - JTK
jpp@slxsys.specialix.co.uk (John Pettitt) (12/03/87)
In article <484@rel.eds.com> bob@rel.eds.com (Bob Leffler) writes: >During the last several weeks there have been numerous solutions posted to >the net to resolved the interface problem with Xenix and smail 2.5. I >have tried all the solutions that I am aware of and my conclusion for the >best approach is a combination of two. lots of stuff about how to install smail deleted. I have just installed smail 2.5 on Xenix 386. The solution I used here was to replace /usr/lib/mail/execmail with a link to (copy of) /bin/smail. I also moved the old sco execmail to execmail.sco and used it as the local delivery agent. The above will not work as it stands because the command syntax for execmail is not the same as smail. This can be corrected by swapping the meaning of the -F and -f switches in smail (main.c and defs.h). The local delivery macro in defs.h should be set to give /usr/lib/mail/execmail.com -f from to. With this setup you get the sco mailer (mailx) and smail with both From and From: lines correct. Also as execmail is still used for 'local' delivery micnet (sco's RS232 "LAN") still works. -- John Pettitt G6KCQ, CIX jpettitt, Voice +44 1 398 9422 UUCP: ...uunet!mcvax!ukc!pyrltd!slxsys!jpp (jpp@slxsys.co.uk) Disclaimer: I don't even own a cat to share my views !