From owner-freebsd-current  Sat Jul 15 09:42:24 1995
Return-Path: current-owner
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.10/8.6.6) id JAA12502
          for current-outgoing; Sat, 15 Jul 1995 09:42:24 -0700
Received: from irbs.irbs.com (irbs.com [199.182.75.129])
          by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id JAA12496
          for <freebsd-current@freefall.cdrom.com>; Sat, 15 Jul 1995 09:42:20 -0700
Received: (from jc@localhost) by irbs.irbs.com (8.6.11/8.6.6) id MAA02357 for freebsd-current@freefall.cdrom.com; Sat, 15 Jul 1995 12:42:16 -0400
From: John Capo <jc@irbs.com>
Message-Id: <199507151642.MAA02357@irbs.irbs.com>
Subject: Possible Bogus free()'s in ypserv
To: freebsd-current@freefall.cdrom.com (freebsd-current)
Date: Sat, 15 Jul 1995 12:42:15 -0400 (EDT)
Reply-To: jc@irbs.com
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 847       
Sender: current-owner@FreeBSD.org
Precedence: bulk

As an experiment, I built a system linked with gnu malloc.  The
only hitch so far is in ypserv.

In server.c:read_database() there are several places where the data
obtained from db->get() is being freed.  In my case it crashes in
free() from the calls at line 369 and 401.  ckey.data is an odd
value for one thing.  The normal libc free() silently returns due
to the magic check.  Gnu free() wanders off on a bogus linked list.

>From libc/stdlib/malloc.c:free()

        op = (union overhead *)((caddr_t)cp - sizeof (union overhead));
#ifdef DEBUG
        ASSERT(op->ov_magic == MAGIC);          /* make sure it was in use */
#else
        if (op->ov_magic != MAGIC)
                return;                         /* sanity */
#endif

So, should the data obtained from db->get() be freed and if so,
why is it not malloced memory?

-- 
John Capo