what causes error -- ELF interpreter /libexec/ld-elf.so.1 not found

I have multiple FreeBSD 6.2 machines with different
hardware, but one of 
them encountered
this strange error when running program "wine".
I could not figure out what causes such error since
/libexec/ld-elf.so.1 
absolutely exists, otherwise
no program will run.

It does not matter if the wine is pre-compiled in packages
or I built it 
from ports.
All other machine do NOT have such problem.

I reinstalled this machine a few times, and it always does
the same 
thing. However other programs
run well.
Would this is related to some particular hardware issue?
This one is ECS 848P-A7 motherboard with Intel P4 506+ CPU,
plus 2 GB 
memory.
Other machines are HP AMD64 laptop, DELL Dual XEON, DELL
Intel Laptop, 
and AMD XP 2100+,
and none of them ever had such problem.

129 /data: ldd `which wine`
/usr/local/bin/wine:
ELF interpreter /libexec/ld-elf.so.1 not found
/usr/local/bin/wine: signal 6

130 /data: ll /libexec/ld-elf.so.1
-r-xr-xr-x  1 root  wheel  158712 Jan 11 23:39
/libexec/ld-elf.so.1*

131 /data: wine
ELF interpreter /libexec/ld-elf.so.1 not found
Abort

132 /data: which wine
/usr/local/bin/wine

Does someone have an idea what is happening here?

-Jin

_______________________________________________
freebsd-hardwarefreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hard
ware
To unsubscribe, send any mail to
"freebsd-hardware-unsubscribefreebsd.org"

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?

Jin Guojun [VFFS] wrote:

> I have multiple FreeBSD 6.2 machines with different
hardware, but one 
> of them encountered
> this strange error when running program
"wine".
> I could not figure out what causes such error since 
> /libexec/ld-elf.so.1 absolutely exists, otherwise
> no program will run.
>
> It does not matter if the wine is pre-compiled in
packages or I built 
> it from ports.
> All other machine do NOT have such problem.
>
> I reinstalled this machine a few times, and it always
does the same 
> thing. However other programs
> run well.
> Would this is related to some particular hardware
issue?
> This one is ECS 848P-A7 motherboard with Intel P4 506+
CPU, plus 2 GB 
> memory.
> Other machines are HP AMD64 laptop, DELL Dual XEON,
DELL Intel Laptop, 
> and AMD XP 2100+,
> and none of them ever had such problem.
>
> 129 /data: ldd `which wine`
> /usr/local/bin/wine:
> ELF interpreter /libexec/ld-elf.so.1 not found
> /usr/local/bin/wine: signal 6
>
> 130 /data: ll /libexec/ld-elf.so.1
> -r-xr-xr-x  1 root  wheel  158712 Jan 11 23:39
/libexec/ld-elf.so.1*
>
> 131 /data: wine
> ELF interpreter /libexec/ld-elf.so.1 not found
> Abort
>
> 132 /data: which wine
> /usr/local/bin/wine
>
> Does someone have an idea what is happening here?
>
> -Jin
>

_______________________________________________
freebsd-hardwarefreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hard
ware
To unsubscribe, send any mail to
"freebsd-hardware-unsubscribefreebsd.org"

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?
>
> Jin Guojun [VFFS] wrote:
>
>> I have multiple FreeBSD 6.2 machines with different
hardware, but one 
>> of them encountered
>> this strange error when running program
"wine".
>> I could not figure out what causes such error since

>> /libexec/ld-elf.so.1 absolutely exists, otherwise
>> no program will run.
>>
>> It does not matter if the wine is pre-compiled in
packages or I built 
>> it from ports.
>> All other machine do NOT have such problem.
>>
>> I reinstalled this machine a few times, and it
always does the same 
>> thing. However other programs
>> run well.
>> Would this is related to some particular hardware
issue?
>> This one is ECS 848P-A7 motherboard with Intel P4
506+ CPU, plus 2 GB 
>> memory.
>> Other machines are HP AMD64 laptop, DELL Dual XEON,
DELL Intel 
>> Laptop, and AMD XP 2100+,
>> and none of them ever had such problem.
>>
>> 129 /data: ldd `which wine`
>> /usr/local/bin/wine:
>> ELF interpreter /libexec/ld-elf.so.1 not found
>> /usr/local/bin/wine: signal 6
>>
>> 130 /data: ll /libexec/ld-elf.so.1
>> -r-xr-xr-x  1 root  wheel  158712 Jan 11 23:39
/libexec/ld-elf.so.1*
>>
>> 131 /data: wine
>> ELF interpreter /libexec/ld-elf.so.1 not found
>> Abort
>>
>> 132 /data: which wine
>> /usr/local/bin/wine
>>
>> Does someone have an idea what is happening here?
>>
>> -Jin
>>


-- 
------------ Jin Guojun ----------- v --- jingeorge.lbl.gov ---
Distributed Systems Department		http://www.dsd.lbl.gov/~j
in
Lawrence Berkeley National Laboratory,	Berkeley, CA 94720

_______________________________________________
freebsd-hardwarefreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hard
ware
To unsubscribe, send any mail to
"freebsd-hardware-unsubscribefreebsd.org"

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.

-- 
John Baldwin
_______________________________________________
freebsd-hardwarefreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hard
ware
To unsubscribe, send any mail to
"freebsd-hardware-unsubscribefreebsd.org"

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.

-- 
John Baldwin
_______________________________________________
freebsd-hardwarefreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hard
ware
To unsubscribe, send any mail to
"freebsd-hardware-unsubscribefreebsd.org"

   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 datasize limit by 'limit'
   utility.  If user do not set a high limit for datasize,
it should not
   be a problem.
   The second aspect also counters this assumption, for
machines that
   have less than 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*1024*1024)
   will not cause this problem. Or if the physical memory is
1GB, setting
   MAXDSIZ=(1024*1024*1024)
   will not cause the problem either.
   I will try to build a similar system on an AMD box with
2GB and more
   memory to see if this
   will be a problem.
   -Jin
_______________________________________________
freebsd-hardwarefreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hard
ware
To unsubscribe, send any mail to
"freebsd-hardware-unsubscribefreebsd.org"

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 datasize limit by 'limit'
>  utility.  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 =
round_page((vm_offset_t)imgp->proc->p_vmspace->vm_d
addr +
            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 = the maximum
memory size will not cause such problem.
>  For example, if the physical memory size is 512 MB,
and setting MAXDSIZ=(512*1024*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().

-- 
John Baldwin
_______________________________________________
freebsd-hardwarefreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hard
ware
To unsubscribe, send any mail to
"freebsd-hardware-unsubscribefreebsd.org"

   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_d
addr +
            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
_______________________________________________
freebsd-hardwarefreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hard
ware
To unsubscribe, send any mail to
"freebsd-hardware-unsubscribefreebsd.org"

On Wednesday 13 June 2007 06:32:42 pm Jin Guojun wrote:
> 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

It depends on the app.  Some apps you can crank the malloc
space up a whole 
lot.  Also, if you are running FreeBSD/amd64 and running a
32-bit binary 
under freebsd32 emulation, then it has 4GB of VA space
rather than 3GB, so 
you can give it more MAXDSIZ.  It's really up to the user to
only use a 
maxdsiz that works.  You can also adjust the hard limit
before exec'ing a 
process that needs a smaller dsize and leave MAXDSIZ larger
for other 
processes.  Since it is dependent on things the compiler
can't know about at 
the build time of the kernel, we just let the user set it to
whatever and if 
they set it too high things break until they lower it.  You
can even set this 
at boot time via 'kern.maxdsiz' tunable in the loader w/o
needing to 
recompile.

-- 
John Baldwin
_______________________________________________
freebsd-hardwarefreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hard
ware
To unsubscribe, send any mail to
"freebsd-hardware-unsubscribefreebsd.org"