[Fwd: [gfarm-discuss:03663] Re: 32bit application segmentation fault on 64bit]

[Somsak Sriprayoonsakul]

No, LD_PRELOAD is not specified by default. It'll be specified manually 
in the job script. Also, if I specify both, the 32bit application will 
refuse to load the 64bit lib (a error message "can not preload libxxx.so 
will appearred").

Jay Scherrer wrote:
> Somsak Sriprayoonsakul wrote:
>> Hello,
>>
>>     I'm trying to LD_PRELOAD an user-level file system library for 
>> 32bit application on x86_64 machine (CentOS 4.3/RHEL4). Somehow the 
>> application segfault everytime. I've install both 32bit and 64bit 
>> libraries, and the test application is just a simple "ls" command 
>> (the real one will be an proprietary animation rendering program so I 
>> can't recompile it to 64bit). Below and attach file are all logs.
>>
>>     My question is, is it possible to do this on x86_64? LD_PRELOAD 
>> either 32bit or 64bit application, while providing all necessary 
>> library for the applicaion. The answer from google seems to be yes, 
>> but what've I done wrong?
>>
>> -------- Original Message --------
>> Subject:     [gfarm-discuss:03663] Re: 32bit application segmentation 
>> fault on 64bit
>> Date:     Fri, 18 Aug 2006 16:33:44 +0700
>> From:     Somsak Sriprayoonsakul <somsak_sr at thaigrid.or.th>
>> Reply-To:     gfarm-discuss at apgrid.org
>> Organization:     Thai National Grid Center
>> To:     gfarm-discuss at apgrid.org
>> References:     
>> <452F37AE49199D49B1702D7D45038C4D6B0E13 at et.ad.sdsc.edu> 
>> <44E2A2A1.3030804 at thaigrid.or.th> 
>> <17635.2643.47481.577333 at srapc2586.sra.co.jp>
>>
>>
>>
>> The problem is less serious now since we successfully using 
>> gfarm-fuse with the application. Anyways I've done strace log and 
>> here it is
>>
>> 1. Normal case
>>
>> [somsak_sr at anatta ~]$ 
>> LD_PRELOAD="/usr/lib64/gfarm/libc-not-hidden.so" /bin/ls
>> bash           clusterscores-1.0b0         globus-4.0.2-1.src.rpm  
>> magi                src
>> benchmark      clusterscores-1.0b0.tar.gz  globus_povray_stub      
>> rocksmountdirty.sh  tmp
>> bin            clusterscores_result        log                     
>> rpm                 usr
>> clusterscores  gfarm-1.3.1-0.src.rpm       ls                      
>> software            work
>> [somsak_sr at anatta ~]$ LD_PRELOAD="/usr/lib/gfarm/libc-not-hidden.so" 
>> $PWD/ls                     Segmentation fault
>> [somsak_sr at anatta ~]$ file $PWD/ls
>> /home/somsak_sr/ls: ELF 32-bit LSB executable, Intel 80386, version 1 
>> (SYSV), for GNU/Linux 2.2.5, dynamically linked (uses shared libs), 
>> stripped
>> [somsak_sr at anatta ~]$
>>
>> 2. Invoke through 32bit bash
>>
>> [somsak_sr at anatta ~]$ file ./bash
>> ./bash: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for 
>> GNU/Linux 2.2.5, dynamically linked (uses shared libs), stripped
>> [somsak_sr at anatta ~]$ file ./ls
>> ./ls: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for 
>> GNU/Linux 2.2.5, dynamically linked (uses shared libs), stripped
>> [somsak_sr at anatta ~]$ export LD_PRELOAD=""
>> [somsak_sr at anatta ~]$ /bin/bash -c 
>> "LD_PRELOAD='/usr/lib64/gfarm/libc-not-hidden.so' /bin/ls"     
>> bash           clusterscores-1.0b0         globus-4.0.2-1.src.rpm  
>> magi                src
>> benchmark      clusterscores-1.0b0.tar.gz  globus_povray_stub      
>> rocksmountdirty.sh  tmp
>> bin            clusterscores_result        log                     
>> rpm                 usr
>> clusterscores  gfarm-1.3.1-0.src.rpm       ls                      
>> software            work
>> [somsak_sr at anatta ~]$ /bin/bash -c 
>> "LD_PRELOAD='/usr/lib/gfarm/libc-not-hidden.so' $PWD/ls"      
>> Segmentation fault
>> [somsak_sr at anatta ~]$
>>
>> 3. strace log - strace log is attached wit this e-mail (it's too 
>> long). Note that, I'm using 32bit strace.
>>
>> You'll see that I only set single file, libc-not-hidden, no 
>> gfarm-libs, and it still segfault. I think this is not problem 
>> regarding gfarm anymore.
>>
>>
>> SODA Noriyuki wrote:
>> >>>>>> On Wed, 16 Aug 2006 11:44:17 +0700,
>> >>>>>>             >       Somsak Sriprayoonsakul 
>> <somsak_sr at thaigrid.or.th> said:
>> >
>> >   >>> Maybe it's worthwhile to check out Gfarm-Fuse system. In our 
>> experience,
>> >>> the Gfarm-Fuse is much more stable in supporting preexisting
>> >>> applications.
>> >>>       >
>> >   >> Yes. Actually we already tested that and gfarm-fuse work great 
>> in term >> of performance. Somehow gfarm-fuse only accept single user 
>> per mounted >> file system, also it does not support lseek system 
>> call, which is >> required by some application. That's why we're 
>> trying to use user-level >> instead.
>> >>     >
>> > Hmm? What is the problem about lseek?
>> > As far as I know, lseek just does work with GfarmFS-FUSE.
>> > Thus, if you could allow your users to mount gfarm filesystem via
>> > GfarmFS-FUSE, certainly it could be an option as Wilfred said.
>> >
>> > If your problem with lseek was a data coherency problem, please try
>> > "-unbuf" option of GfarmFS-FUSE.
>> >  
>>
>> -- 
>> ----------------------------------------------------------------------------------- 
>>
>> Somsak Sriprayoonsakul
>>
>> Thai National Grid Center
>> Software Industry Promotion Agency
>> Ministry of ICT, Thailand
>> somsak_sr at thaigrid.or.th
>> ----------------------------------------------------------------------------------- 
>>
> The real question is: are you calling both libraries at the same time. 
> This used to be a problem with apt-get also. It would load both 
> libraries X_32 and X_64 to cause a clash.
> Have you tried specifying either the X_32 or the X_64 only while 
> compiling?
>
> Jay Scherrer
>


-- 
-----------------------------------------------------------------------------------
Somsak Sriprayoonsakul

Thai National Grid Center
Software Industry Promotion Agency
Ministry of ICT, Thailand
somsak_sr at thaigrid.or.th
-----------------------------------------------------------------------------------