Date: Thu, 3 Jan 2008 22:39:36 +0200 From: Kostik Belousov <kostikbel@gmail.com> To: Jason Evans <jasone@freebsd.org> Cc: freebsd-current@freebsd.org Subject: Re: sbrk(2) broken Message-ID: <20080103203936.GX57756@deviant.kiev.zoral.com.ua> In-Reply-To: <477C82F0.5060809@freebsd.org> References: <477C82F0.5060809@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--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 <sys/types.h>
#include <unistd.h>
#include <stdio.h>
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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080103203936.GX57756>