Date: Wed, 13 Jun 2007 15:32:42 -0700 From: Jin Guojun <jin@george.lbl.gov> To: John Baldwin <jhb@freebsd.org> Cc: questions@freebsd.org, freebsd-hardware@freebsd.org Subject: Re: what causes error -- ELF interpreter /libexec/ld-elf.so.1 not found Message-ID: <4670708A.5030805@george.lbl.gov> In-Reply-To: <200706131001.25840.jhb@freebsd.org> References: <466B2B9F.5010308@lbl.gov> <200706121527.04274.jhb@freebsd.org> <466F4642.8070001@george.lbl.gov> <200706131001.25840.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
John Baldwin wrote:
On Tuesday 12 June 2007 09:20:02 pm Jin Guojun wrote:
John Baldwin wrote:
On Saturday 09 June 2007 08:53:18 pm Jin Guojun [VFFS] wrote:
I believe that this is a memory sub-system bug somewhere because
anything equal to or below 1G
options MAXDSIZ="(1024*1024*1024)"
will work regardless how many memory is installed in the system.
I doubt this could be a hardware related issue although is memory size
related.
Finally find cause but no idea why -- in kernel configuration,
following line causes the problem:
options MAXDSIZ="(2097152U*1024)"
Can anyone explain why this can cause /libexec/ld-elf.so.1 not seen
for some program?
This is setting aside 2GB for malloc which leaves only 1GB for all of mmap and
stack. You probably don't have enough address space to map your binary.
This does not quite explain the problem.
First of all, the MAXDSIZ is the maximum size for users to set their own datas
ize limit by 'limit'
utility. If user do not set a high limit for datasize, it should not be a pro
blem.
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 = 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 t
han or equal to
1 GB memory, and setting the MAXDISZ = the maximum memory size will not cause
such problem.
For example, if the physical memory size is 512 MB, and setting MAXDSIZ=(512*1
024*1024)
will not cause this problem. Or if the physical memory is 1GB, setting MAXDSIZ
=(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().
No quite clear on this. Does this mean that the MAXDSIZ cannot exceeed
1GB regardless
how many physical memory (say 16 GB) is installed? Then, this is
definitiely a software bug.
Then, somewhere the following checking is needed:
#if (MAXDSIZ > 1024 * 1024 * 1024)
#undef MAXDSIZ
#define MAXDSIZ (1024 * 1024 * 1024)
#endif
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4670708A.5030805>