NetBSD Problem Report #54050

From ryo_on@yk.rim.or.jp  Sat Mar  9 03:38:25 2019
Return-Path: <ryo_on@yk.rim.or.jp>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 827477A19B
	for <gnats-bugs@gnats.NetBSD.org>; Sat,  9 Mar 2019 03:38:25 +0000 (UTC)
Message-Id: <44GSnB60CRz36CQxB@mail.SiriusCloud.jp>
Date: Sat, 09 Mar 2019 11:22:17 +0900
From: ryoon@NetBSD.org
Reply-To: ryoon@NetBSD.org
To: gnats-bugs@NetBSD.org
Subject: malloc_usable_size() is provided on recent NetBSD-current, however malloc.h has no prototype
X-Send-Pr-Version: 3.95

>Number:         54050
>Category:       lib
>Synopsis:       malloc_usable_size() is provided on recent NetBSD-current, however malloc.h has no prototype
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    lib-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Mar 09 03:40:00 +0000 2019
>Last-Modified:  Tue Mar 12 19:25:01 +0000 2019
>Originator:     Ryo ONODERA
>Release:        NetBSD 8.99.35
>Organization:

>Environment:


System: NetBSD brownie 8.99.35 NetBSD 8.99.35 (DTRACE7) #8: Sat Mar 9 02:41:18 JST 2019 ryoon@brownie:/usr/world/8.99/amd64/obj/sys/arch/amd64/compile/DTRACE7 amd64
Architecture: x86_64
Machine: amd64
>Description:
It seems that recent NetBSD-current with jemalloc provides
malloc_usable_size(), however /usr/include/malloc.h has
no prototype definition.

This inconsistency breaks a build of pkgsrc/www/firefox-65.0.2nb1.

>How-To-Repeat:

cd /usr/pkgsrc/www/firefox
make install
>Fix:

I will add a workaround for pkgsrc/www/firefox.
However modifying malloc.h is preferable, if malloc_usable_size()
works well.

>Audit-Trail:
From: "Christos Zoulas" <christos@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/54050 CVS commit: src/include
Date: Fri, 8 Mar 2019 22:52:11 -0500

 Module Name:	src
 Committed By:	christos
 Date:		Sat Mar  9 03:52:11 UTC 2019

 Modified Files:
 	src/include: malloc.h

 Log Message:
 PR/54050: Ryo ONODERA: Add the jemalloc-specific api prototypes and extern.


 To generate a diff of this commit:
 cvs rdiff -u -r1.3 -r1.4 src/include/malloc.h

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: Joerg Sonnenberger <joerg@bec.de>
To: gnats-bugs@NetBSD.org
Cc: lib-bug-people@netbsd.org, gnats-admin@netbsd.org,
	netbsd-bugs@netbsd.org
Subject: Re: lib/54050: malloc_usable_size() is provided on recent
 NetBSD-current, however malloc.h has no prototype
Date: Sat, 9 Mar 2019 19:52:02 +0100

 On Sat, Mar 09, 2019 at 03:40:00AM +0000, ryoon@NetBSD.org wrote:
 > >Description:
 > It seems that recent NetBSD-current with jemalloc provides
 > malloc_usable_size(), however /usr/include/malloc.h has
 > no prototype definition.
 > 
 > This inconsistency breaks a build of pkgsrc/www/firefox-65.0.2nb1.

 I would actually very much prefer to go the reverse direction and do
 *not* expose the various statistic intefaces at all. They are a cancer
 that just tie libc down to a specific malloc implementation.
 Applications have no reason for demanding this stuff.

 Joerg

From: Ryo ONODERA <ryo@tetera.org>
To: gnats-bugs@NetBSD.org, christos@netbsd.org
Cc: 
Subject: Re: PR/54050 CVS commit: src/include
Date: Sun, 10 Mar 2019 12:38:23 +0900

 Hi,

 This change causes the following error in pkgsrc/lang/spidermonkey52.


 ld: ../../../memory/mozalloc/Unified_cpp_memory_mozalloc0.o:/usr/include/malloc.h:28: multiple definition of `malloc_conf'; Unified_cpp_js_src_shell0.o:/usr/include/malloc.h:28: first defined here
 ld: ../../../memory/mozalloc/Unified_cpp_memory_mozalloc0.o:/usr/include/malloc.h:26: multiple definition of `malloc_message'; Unified_cpp_js_src_shell0.o:/usr/include/malloc.h:26: first defined here

 Could you take a look at this problem?

 Thank you.

 "Christos Zoulas" <christos@netbsd.org> writes:

 > The following reply was made to PR lib/54050; it has been noted by GNATS.
 >
 > From: "Christos Zoulas" <christos@netbsd.org>
 > To: gnats-bugs@gnats.NetBSD.org
 > Cc: 
 > Subject: PR/54050 CVS commit: src/include
 > Date: Fri, 8 Mar 2019 22:52:11 -0500
 >
 >  Module Name:	src
 >  Committed By:	christos
 >  Date:		Sat Mar  9 03:52:11 UTC 2019
 >  
 >  Modified Files:
 >  	src/include: malloc.h
 >  
 >  Log Message:
 >  PR/54050: Ryo ONODERA: Add the jemalloc-specific api prototypes and extern.
 >  
 >  
 >  To generate a diff of this commit:
 >  cvs rdiff -u -r1.3 -r1.4 src/include/malloc.h
 >  
 >  Please note that diffs are not public domain; they are subject to the
 >  copyright notices on the relevant files.
 >  

 -- 
 Ryo ONODERA

From: Christos Zoulas <christos@zoulas.com>
To: "gnats-bugs@netbsd.org" <gnats-bugs@NetBSD.org>
Cc: lib-bug-people@netbsd.org,
 gnats-admin@netbsd.org,
 netbsd-bugs@netbsd.org,
 "ryoon@netbsd.org" <ryoon@NetBSD.org>
Subject: Re: PR/54050 CVS commit: src/include
Date: Sat, 9 Mar 2019 22:54:37 -0500

 I added the missing externs.

 christos

From: Kamil Rytarowski <n54@gmx.com>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: lib/54050: malloc_usable_size() is provided on recent
 NetBSD-current, however malloc.h has no prototype
Date: Tue, 12 Mar 2019 13:35:20 +0100

 On 09.03.2019 19:55, Joerg Sonnenberger wrote:
 > The following reply was made to PR lib/54050; it has been noted by GNATS.
 > 
 > From: Joerg Sonnenberger <joerg@bec.de>
 > To: gnats-bugs@NetBSD.org
 > Cc: lib-bug-people@netbsd.org, gnats-admin@netbsd.org,
 > 	netbsd-bugs@netbsd.org
 > Subject: Re: lib/54050: malloc_usable_size() is provided on recent
 >  NetBSD-current, however malloc.h has no prototype
 > Date: Sat, 9 Mar 2019 19:52:02 +0100
 > 
 >  On Sat, Mar 09, 2019 at 03:40:00AM +0000, ryoon@NetBSD.org wrote:
 >  > >Description:
 >  > It seems that recent NetBSD-current with jemalloc provides
 >  > malloc_usable_size(), however /usr/include/malloc.h has
 >  > no prototype definition.
 >  > 
 >  > This inconsistency breaks a build of pkgsrc/www/firefox-65.0.2nb1.
 >  
 >  I would actually very much prefer to go the reverse direction and do
 >  *not* expose the various statistic intefaces at all. They are a cancer
 >  that just tie libc down to a specific malloc implementation.
 >  Applications have no reason for demanding this stuff.
 >  
 >  Joerg
 >  
 > 

 I disagree, I do find the statistics API useful for part of external
 software. At some point of time this API would allow me to port an
 additional software at all as test-suite required mallctl interfaces to
 validate the code (LLVM scudo hardened allocator).

From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: lib/54050: malloc_usable_size() is provided on recent
 NetBSD-current, however malloc.h has no prototype
Date: Tue, 12 Mar 2019 13:41:31 +0100

 On Tue, Mar 12, 2019 at 12:35:00PM +0000, Kamil Rytarowski wrote:
 >  I disagree, I do find the statistics API useful for part of external
 >  software. At some point of time this API would allow me to port an
 >  additional software at all as test-suite required mallctl interfaces to
 >  validate the code (LLVM scudo hardened allocator).

 I strongly agree with Joerg here: it should not be part of libc.

 Most software abuses this interface (c.f. firefox about:memmory) and 
 anything that really needs more than the C standard should use its own 
 malloc library that provides whatever it needs without tying our libc
 to that particular malloc implementation.

 I have no problem with us proivding a libjemalloc.so.* from the same
 source we build the intree libc stuff and exposing the interface there,
 but we may stop providing that shared lib in future releases.

 Martin

From: christos@zoulas.com (Christos Zoulas)
To: gnats-bugs@NetBSD.org, lib-bug-people@netbsd.org, 
	gnats-admin@netbsd.org, netbsd-bugs@netbsd.org, ryoon@NetBSD.org
Cc: 
Subject: Re: lib/54050: malloc_usable_size() is provided on recent NetBSD-current, however malloc.h has no prototype
Date: Tue, 12 Mar 2019 09:21:45 -0400

 On Mar 12, 12:45pm, martin@duskware.de (Martin Husemann) wrote:
 -- Subject: Re: lib/54050: malloc_usable_size() is provided on recent NetBSD-

 |  I strongly agree with Joerg here: it should not be part of libc.

 I agree. I will move the extra symbols to -ljemalloc. We should not
 be binding libc with a malloc implementation.

 |  Most software abuses this interface (c.f. firefox about:memmory) and 
 |  anything that really needs more than the C standard should use its own 
 |  malloc library that provides whatever it needs without tying our libc
 |  to that particular malloc implementation.
 |  
 |  I have no problem with us proivding a libjemalloc.so.* from the same
 |  source we build the intree libc stuff and exposing the interface there,
 |  but we may stop providing that shared lib in future releases.

 Will do (expose the interface there).

 christos

From: Kamil Rytarowski <n54@gmx.com>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: lib/54050: malloc_usable_size() is provided on recent
 NetBSD-current, however malloc.h has no prototype
Date: Tue, 12 Mar 2019 19:05:09 +0100

 On 12.03.2019 14:21, Christos Zoulas wrote:
 > On Mar 12, 12:45pm, martin@duskware.de (Martin Husemann) wrote:
 > -- Subject: Re: lib/54050: malloc_usable_size() is provided on recent NetBSD-
 > 
 > |  I strongly agree with Joerg here: it should not be part of libc.
 > 
 > I agree. I will move the extra symbols to -ljemalloc. We should not
 > be binding libc with a malloc implementation.
 >  
 > |  Most software abuses this interface (c.f. firefox about:memmory) and 
 > |  anything that really needs more than the C standard should use its own 
 > |  malloc library that provides whatever it needs without tying our libc
 > |  to that particular malloc implementation.
 > |  
 > |  I have no problem with us proivding a libjemalloc.so.* from the same
 > |  source we build the intree libc stuff and exposing the interface there,
 > |  but we may stop providing that shared lib in future releases.
 > 
 > Will do (expose the interface there).
 > 
 > christos
 > 

 I will be happy to pick -ljemalloc for the additional functionality.
 Maintaining it partially externally has obvious benefits of jemalloc
 major library version bump without issues.

 On the other hand we will bind malloc.h with jemalloc.. should it be
 namespaced to jemalloc/malloc.h or jemalloc.h?

From: christos@zoulas.com (Christos Zoulas)
To: gnats-bugs@NetBSD.org, lib-bug-people@netbsd.org, 
	gnats-admin@netbsd.org, netbsd-bugs@netbsd.org, ryoon@NetBSD.org
Cc: 
Subject: Re: lib/54050: malloc_usable_size() is provided on recent NetBSD-current, however malloc.h has no prototype
Date: Tue, 12 Mar 2019 14:06:33 -0400

 On Mar 12,  6:05pm, n54@gmx.com (Kamil Rytarowski) wrote:
 -- Subject: Re: lib/54050: malloc_usable_size() is provided on recent NetBSD-

 |  I will be happy to pick -ljemalloc for the additional functionality.
 |  Maintaining it partially externally has obvious benefits of jemalloc
 |  major library version bump without issues.
 |  
 |  On the other hand we will bind malloc.h with jemalloc.. should it be
 |  namespaced to jemalloc/malloc.h or jemalloc.h?

 I can put the functions in jemalloc.h. It is trivial.

 christos

From: Kamil Rytarowski <n54@gmx.com>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: lib/54050: malloc_usable_size() is provided on recent
 NetBSD-current, however malloc.h has no prototype
Date: Tue, 12 Mar 2019 20:25:09 +0100

 On 12.03.2019 19:10, Christos Zoulas wrote:
 > The following reply was made to PR lib/54050; it has been noted by GNATS.
 > 
 > From: christos@zoulas.com (Christos Zoulas)
 > To: gnats-bugs@NetBSD.org, lib-bug-people@netbsd.org, 
 > 	gnats-admin@netbsd.org, netbsd-bugs@netbsd.org, ryoon@NetBSD.org
 > Cc: 
 > Subject: Re: lib/54050: malloc_usable_size() is provided on recent NetBSD-current, however malloc.h has no prototype
 > Date: Tue, 12 Mar 2019 14:06:33 -0400
 > 
 >  On Mar 12,  6:05pm, n54@gmx.com (Kamil Rytarowski) wrote:
 >  -- Subject: Re: lib/54050: malloc_usable_size() is provided on recent NetBSD-
 >  
 >  |  I will be happy to pick -ljemalloc for the additional functionality.
 >  |  Maintaining it partially externally has obvious benefits of jemalloc
 >  |  major library version bump without issues.
 >  |  
 >  |  On the other hand we will bind malloc.h with jemalloc.. should it be
 >  |  namespaced to jemalloc/malloc.h or jemalloc.h?
 >  
 >  I can put the functions in jemalloc.h. It is trivial.
 >  
 >  christos
 >  
 > 

 I don't have strong opinions. Probably we could restore K&R compat and
 keep malloc.h as an alias for stdlib.h, and push jemalloc specific API
 to jemalloc.h.

>Unformatted:

Home	PR Database Search