From owner-freebsd-current@FreeBSD.ORG Thu Jan 3 20:39:47 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3366416A417 for ; Thu, 3 Jan 2008 20:39:47 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay02.kiev.sovam.com (relay02.kiev.sovam.com [62.64.120.197]) by mx1.freebsd.org (Postfix) with ESMTP id BD98313C4CE for ; Thu, 3 Jan 2008 20:39:46 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.226] (helo=deviant.kiev.zoral.com.ua) by relay02.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1JAWqn-000Gaa-AP; Thu, 03 Jan 2008 22:39:45 +0200 Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m03Kda0s010747; Thu, 3 Jan 2008 22:39:36 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id m03Kda1h010746; Thu, 3 Jan 2008 22:39:36 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 3 Jan 2008 22:39:36 +0200 From: Kostik Belousov To: Jason Evans Message-ID: <20080103203936.GX57756@deviant.kiev.zoral.com.ua> References: <477C82F0.5060809@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7+SiJqgcYR1fH3/L" Content-Disposition: inline In-Reply-To: <477C82F0.5060809@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Scanner-Signature: 4fcf7b0c3bd3465242a83b332b797d78 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 1976 [Dec 29 2007] X-SpamTest-Info: helo_type=3 X-SpamTest-Info: {received from trusted relay: not dialup} X-SpamTest-Method: none X-SpamTest-Method: Local Lists X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release Cc: freebsd-current@freebsd.org Subject: Re: sbrk(2) broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2008 20:39:47 -0000 --7+SiJqgcYR1fH3/L Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 02, 2008 at 10:38:40PM -0800, Jason Evans wrote: > Poul-Henning noticed today that xchat fails to start if malloc uses sbrk= =20 > internally. This failure happens during the first call to malloc, with= =20 > the following message: >=20 > Fatal error 'Can't allocate initial thread' at line 335 in file=20 > /usr/src/lib/libthr/thread/thr_init.c (errno =3D 12) >=20 > This can be worked around with MALLOC_OPTIONS=3DdM . >=20 > The problem does not appear to be specific to jemalloc; I reverted=20 > src/lib/libc/stdlib/malloc.c to revision 1.92 (last phkmalloc revision),= =20 > which also uses sbrk, and the failure mode is the same. >=20 > The failure occurs on both i386 and amd64. It appears that sbrk(0)=20 > returns an address that is in the address range normally used by mmap.=20 > So, the first call to sbrk with a non-zero increment is fantastically=20 > wrong. On i386 (ktrace output): >=20 > 1013 xchat CALL break(0x28200000) > 1013 xchat RET break -1 errno 12 Cannot allocate memory >=20 > On amd64 (truss ouput): >=20 > break(0x800900000) ERR#12 'Cannot allocate memory' >=20 > sbrk is not a true system call, so it seems like the problem should have= =20 > something to do with the _end data symbol. I looked at it in gdb though= =20 > and never saw an unreasonable value, despite bogus sbrk(0) results. I=20 > do not know offhand how to get the addresses of .minbrk and .curbrk=20 > (register inspection within gdb while stepping through sbrk?), which are= =20 > what sbrk actually uses (see src/lib/libc/amd64/sys/sbrk.S). Perhaps=20 > the loader isn't initializing them correctly... >=20 > I am quite pressed for time at the moment, and cannot look into this in= =20 > any more detail for at least a couple of weeks. If anyone knows what=20 > the problem is, please let me know. I cannot say definitely what happen, but please note that the _end symbol is defined by linker script, and it shall be present in all executable and shared objects. The value you reported would be naturally the _end value for some shared object. I tried both the RELENG_7 and HEAD, and sbrk(0) correctly returns a seemingly valid value like 0x8049644. #include #include #include int main(int argc, char *argv) { void *p; p =3D sbrk(0); printf("%p\n", p); return (0); } --7+SiJqgcYR1fH3/L Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHfUgIC3+MBN1Mb4gRAt/AAJ40IuGUgbOVqW6H+DM9EqFC0AGfUQCgr1Rv 80AUbdS/QZ13Q/kR+GSqpwQ= =3IcV -----END PGP SIGNATURE----- --7+SiJqgcYR1fH3/L--