Path: utzoo!utgpu!cunews!bnrgate!brtph3!brchh104!brchs1!bnr.ca!rice.edu!sun-spots-request
From: emperor!sugar!richd@uunet.uu.net (Richard Doherty)
Newsgroups: comp.sys.sun
Subject: Fgets and malloc_verify()
Keywords: SunOS
Message-ID: <1610@brchh104.bnr.ca>
Date: 13 Feb 91 22:03:00 GMT
Sender: news@brchh104.bnr.ca
Organization: Sun-Spots
Lines: 23
Approved: Sun-Spots@rice.edu
X-Original-Date: 7 Feb 91 02:07:20 GMT
X-Sun-Spots-Digest: Volume 10, Issue 31, message 15
X-Note: Submissions: sun-spots@rice.edu, Admin: sun-spots-request@rice.edu

It appears that malloc_debug() believes that fgets() makes a call to
malloc() with size of 0.  This in itself is alright, except that
malloc_debug() (and therfore malloc_verify()) abort as soon as they
discover this, making them useless for further debugging.

Details:

OS4.0.1 Sun4 (Sparc)

When NOT linked with /usr/lib/debug/malloc.o, fgets() does not display
this behavior -- determined by writing another malloc routine local to the
routine, and checking for size of 0.

Malloc_verify() called anytime after the call to fgets() reports that the
heap is corrupt (having a block size of 0 for one entry) and aborts.

This may indeed simply be a much more obscure memory problem in my program
itself.

It makes malloc_verify() useless (although, admittedly, I have never found
it all that useful in the first place).

--Rich