Date: Wed, 13 Jun 2007 10:01:25 -0400 From: John Baldwin <jhb@freebsd.org> To: Jin Guojun <jin@george.lbl.gov> Cc: questions@freebsd.org, freebsd-hardware@freebsd.org Subject: Re: what causes error -- ELF interpreter /libexec/ld-elf.so.1 not found Message-ID: <200706131001.25840.jhb@freebsd.org> In-Reply-To: <466F4642.8070001@george.lbl.gov> References: <466B2B9F.5010308@lbl.gov> <200706121527.04274.jhb@freebsd.org> <466F4642.8070001@george.lbl.gov>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday 12 June 2007 09:20:02 pm Jin Guojun wrote:
> John Baldwin wrote:=20
> On Saturday 09 June 2007 08:53:18 pm Jin Guojun [VFFS] wrote:
> =20
> I believe that this is a memory sub-system bug somewhere because=20
> anything equal to or below 1G
>=20
> options MAXDSIZ=3D"(1024*1024*1024)"
>=20
> will work regardless how many memory is installed in the system.
> I doubt this could be a hardware related issue although is memory size=20
> related.
>=20
> =20
> Finally find cause but no idea why -- in kernel configuration,=20
> following line causes the problem:
>=20
> options MAXDSIZ=3D"(2097152U*1024)"
>=20
> Can anyone explain why this can cause /libexec/ld-elf.so.1 not seen=20
> for some program?
> =20
>=20
> This is setting aside 2GB for malloc which leaves only 1GB for all of mma=
p and=20
> stack. You probably don't have enough address space to map your binary.
> =20
> This does not quite explain the problem.=20
> First of all, the MAXDSIZ is the maximum size for users to set their own=
datasize limit by 'limit'
> utility.=A0 If user do not set a high limit for datasize, it should not =
be a problem.
UTSL. By default proc0 gets a hard limit (lim_max vs lim_cur) of MAXDSIZ,
and the max limit is what the ELF image activator in the kernel uses when
figuring out where to mmap the runtime linker:
/*
* We load the dynamic linker where a userland call
* to mmap(0, ...) would put it. The rationale behind this
* calculation is that it leaves room for the heap to grow to
* its maximum allowed size.
*/
addr =3D round_page((vm_offset_t)imgp->proc->p_vmspace->vm_daddr +
lim_max(imgp->proc, RLIMIT_DATA));
> The second aspect also counters this assumption, for machines that have =
less than or equal to
> 1 GB memory, and setting the MAXDISZ =3D the maximum memory size will no=
t cause such problem.
> For example, if the physical memory size is 512 MB, and setting MAXDSIZ=
=3D(512*1024*1024)
> will not cause this problem. Or if the physical memory is 1GB, setting M=
AXDSIZ=3D(1024*1024*1024)
> will not cause the problem either.
Umm, the amount of physical memory has no bearing on how the virtual
address space for userland is laid out. Do you know what virtual memory
is and how it works? Your first e-mail seems to contradict this paragraph
as in your first e-mail you noted that the physical memory doesn't matter,
the solution was to not raise MAXDSIZ higher than 1GB and that is consistent
with running out of virtual address space due to MAXDSIZ reserving too much
address space for malloc().
=2D-=20
John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200706131001.25840.jhb>