NetBSD Problem Report #7937

Received: (qmail 21662 invoked from network); 6 Jul 1999 18:05:47 -0000
Message-Id: <19990706180545.93E49152@jekyll.piermont.com>
Date: Tue,  6 Jul 1999 14:05:45 -0400 (EDT)
From: perry@piermont.com
Reply-To: perry@piermont.com
To: gnats-bugs@gnats.netbsd.org
Subject: malloc/sbrk interaction poorly documented
X-Send-Pr-Version: 3.95

>Number:         7937
>Category:       lib
>Synopsis:       malloc/sbrk interaction poorly documented
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    lib-bug-people
>State:          closed
>Class:          doc-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Jul 06 11:20:00 +0000 1999
>Closed-Date:    Sat Aug 27 23:18:08 +0000 2016
>Last-Modified:  Sat Aug 27 23:18:08 +0000 2016
>Originator:     Perry E. Metzger
>Release:        NetBSD-current
>Organization:
Perry Metzger		perry@piermont.com
--
"Ask not what your country can force other people to do for you."
>Environment:

System: NetBSD jekyll.piermont.com 1.4 NetBSD 1.4 (JEKYLL) #0: Mon May 3 09:58:15 EDT 1999 perry@jekyll.piermont.com:/usr/src/sys/arch/i386/compile/JEKYLL i386


>Description:

malloc and sbrk: are they friends or enemies? Who knows?

According to XPG, using both in the same program is not guaranteed to
be safe. Some say that "we've always allowed that". Some say "some of
our platforms have always caused programs to do bad things if you did
that". It is all unclear.

I've recently upgraded the brk/sbrk man page to indicate mixing malloc 
and sbrk is non-portable (in accordance with XPG). However, we have to 
document what _OUR_ API guarantees. Are you allowed to mix them, or
not? If so, we should document that explicitly on the *alloc and
brk/sbrk man pages. If not, we should explicitly document *that*. We
should note in either case that the behavior is undefined in a
portable context.

>How-To-Repeat:

man sbrk
man malloc

scratch head

>Fix:
Make a decision, document it and stick with it. My understanding is
that the new phk malloc() may force the issue.
>Release-Note:
>Audit-Trail:

From: "Erik E. Fair" <fair@clock.org>
To: NetBSD GNATS Problem Report Tracking System <gnats-bugs@gnats.netbsd.org>
Cc:  
Subject: Re: lib/7937
Date: Sun, 13 Jan 2002 01:14:30 -0800

 It has always been my understanding that since malloc(3) uses sbrk(2) 
 (and that is so stated in my copy of the 7th Edition manual), it is 
 not safe to mix their use; malloc(3) is the preferred interface 
 (particularly since other library routines and perhaps other program 
 segments will also use it).

 Unless we're prepared to change things such that malloc(3) and 
 sbrk(2) deliver RAM in distinct chunks of the address space of a 
 process, we should discourage sbrk(2)'s direct use by any userland 
 program. Perhaps a loader warning, ala mktemp, is in order.

 	Erik <fair@clock.org>
Responsible-Changed-From-To: lib-bug-people->atatat 
Responsible-Changed-By: perry 
Responsible-Changed-When: Mon Mar 31 08:16:07 PST 2003 
Responsible-Changed-Why:  
Andrew understands this stuff very well at this point. I don't... 

From: Andrew Brown <atatat@atatdot.net>
To: perry@piermont.com
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: lib/7937: malloc/sbrk interaction poorly documented
Date: Sun, 6 Apr 2003 19:00:01 -0400

 >malloc and sbrk: are they friends or enemies? Who knows?

 enemies, most probably.

 >According to XPG, using both in the same program is not guaranteed to
 >be safe. Some say that "we've always allowed that". Some say "some of
 >our platforms have always caused programs to do bad things if you did
 >that". It is all unclear.

 it would be truthful to say that "we've always allowed that", however,
 there should be big warning flags that surround the mere suggestion of
 such activities.

 >I've recently upgraded the brk/sbrk man page to indicate mixing malloc 
 >and sbrk is non-portable (in accordance with XPG). However, we have to 
 >document what _OUR_ API guarantees. Are you allowed to mix them, or
 >not? If so, we should document that explicitly on the *alloc and
 >brk/sbrk man pages. If not, we should explicitly document *that*. We
 >should note in either case that the behavior is undefined in a
 >portable context.

 i can imagine a system where malloc() was implemented using mmap() and
 anonymous memory, however, since our malloc merely pokes the heap
 (which is what {,s}brk() does), we should encourage not mixing them.

 >Make a decision, document it and stick with it. My understanding is
 >that the new phk malloc() may force the issue.

 i don't know that it does, since from a gross point of view, what it
 does is ultimately the same.  otoh, if you were using a malloc()
 implementation that used mmap() internally, *then* you would have to
 think.

 -- 
 |-----< "CODE WARRIOR" >-----|
 codewarrior@daemon.org             * "ah!  i see you have the internet
 twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
 werdna@squooshy.com       * "information is power -- share the wealth."

From: mouss <usebsd@free.fr>
To: gnats-bugs@gnats.netbsd.org, perry@piermont.com,
  Andrew Brown <atatat@atatdot.net>
Cc:  
Subject: Re: lib/7937: malloc/sbrk interaction poorly documented
Date: Fri, 05 Dec 2003 00:12:05 +0100

 The following small prog dumps core if calling sbrk().
 So unless I missed something, this shows that sbrk is dangerous when 
 mixed with malloc.

 As a consequence, a program that uses sbrk but still calls functions 
 like strdup (which calls malloc) without redefining malloc is not 
 guaranteed to work. nasty...

 In short, brk/sbrk should be reserved to those who use it to implement 
 malloc replacements...

 I think the manpage should recommened mmap instead of sbrk and that a 
 warning be issued if brk or sbrk are used (except in malloc/libc of course).

 -----
 #include <stdlib.h>
 #include <unistd.h>
 #include <string.h>

 int
 main(int argc, char** argv)
 {
 	char* buf;
 	int bytes;
 	int dobrk=0;

 	if (argc > 1) {
 		dobrk=1;
 	}

 	bytes = 8192;
 	buf = (char*) malloc(bytes);
 	if (dobrk) {
 		sbrk(-bytes);
 	}
 	memset(buf, 0, 8); /* dumps core */

 	return 0;
 }
 --------------------

Responsible-Changed-From-To: atatat->lib-bug-people
Responsible-Changed-By: wiz@NetBSD.org
Responsible-Changed-When: Sun, 21 Mar 2010 15:48:55 +0000
Responsible-Changed-Why:
Back to role account, atatat lost his commit bit.


State-Changed-From-To: open->closed
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Sat, 27 Aug 2016 23:18:08 +0000
State-Changed-Why:
My commit for PR 7934 tackled this as wel.
(well. grr)


>Unformatted:

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2014 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.