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.