32 and 64bit app in use?

It's a BOINC "feature", not a bug. The BOINC manager will use the 32-bit application if it notices that it performs faster. This of course is quite bad for us as we have higher memory usages than those that 32-bit applications are able to do. We'll try to disable this when we upgrade the BOINC installation.

I've got an older 64 bit client that is insisting on running the 32 bit renderer (since 4.91?) and keeps segfaulting.

If I try to run manually with "./blender_ld ./blender ..." it crashes, but just "./blender -noaudio ..." works fine.

I tried "gdb --core=core" and only get the following (makes no sense to me)...

Core was generated by `./blender_ld ./blender -noaudio -b ../file1438187 -P clirender.py -- -F PNG -t'.
Program terminated with signal 11, Segmentation fault.
#0  0xa85848f6 in ?? ()

Any suggestions?

I'm pretty sure the 4.90 client was working fine, but I can't guarantee I wasn't running 64 bit at the time. (btw, 64bit client works fine for 4.91, 32bit running on 64bit is what's crashing).

EDIT: This seems to be the point where it switched from 64 to 32...

http://renderfarm.fi/result.php?resultid=3693051
http://renderfarm.fi/result.php?resultid=3697833

Difference between 4.90 and 4.91 is that I included even the most basic Linux system libraries with the client. This means that for the 32-bit client I included a 32-bit libc and the sort. This might have something to do with it. Also, the "blender_ld" is the ld-linux.so, the dynamic library linker/loader. The version included with the 32-bit client won't work on 64-bit systems. This BOINC feature is really kicking us to the nuts...

Could you try making a local test copy of the rendering client, but replace blender_ld with /lib64/ld-2.11.1.so (replace the 32-bit loader with the 64-bit one)? It might be named a bit differently. Then try running ./blender_ld ./blender ... ...

EDIT: Gave you the wrong path originally. Changed to /lib64/ld-2.11.1.so

I have ld-2.11.2.so (not 2.11.1).

The one in my /lib looks the same size as in /lib64, but the one in /lib32 is different.

-rwxr-xr-x 1 root root 118060 Jan 23  2011 /lib32/ld-2.11.2.so
-rwxr-xr-x 1 root root 128744 Jan 23  2011 /lib64/ld-2.11.2.so
-rwxr-xr-x 1 root root 128744 Jan 23  2011 /lib/ld-2.11.2.so

When I copy the 32 bit version from /lib32 everything works (./ld-2.11.2.so ./blender ...). But the /lib (and lib64) version fail with...

./blender: error while loading shared libraries: ./blender: wrong ELF class: ELFCLASS32

Here are my linkings to ld-linux.so.2

/lib/ld-linux.so.2 -> /lib32/ld-linux.so.2
/lib32/ld-linux.so.2 -> ld-2.11.2.so
/lib64/ld-linux.so.2 -> /lib32/ld-linux.so.2

(don't understand that last one)

EDIT: I'm using Debian Squeeze (Linux 2.6.32-5-amd64 #1 SMP Tue Jun 14 09:42:28 UTC 2011 x86_64 GNU/Linux).

Thanks for the help.

No idea why /lib64 would link to /lib32. Perhaps it's some distro thing. Anyway, the version I used for the client seems to be ld-2.13.so. Why that version (Ubuntu 11.04 using kernel 2.6.38-8-generic) of the library loader doesn't work is odd though. Maybe I used a too new system? Sounds possible, even if odd.

You are on Linux 2.6.32-5-amd64. Maybe updating the system (kernel) would help? As far as I know, these things are quite inter-distro and inter-version as long the difference isn't too large.

I've have the latest updates for my distro. Been wanting to upgrade the distro (all my other clients have been upgraded), but it's an important box (mail/file/web server), so I need to wait for the correct time.

It's still weird that 64 bit works ok (with ld-2.13? and kernel-2.6.32).

How is 32/64 determined by boinc? Is there any way to force boinc to use 64bit via the (boinc) xml files? Would resetting or detaching the project make any difference?

I'm not sure how BOINC makes the final decision. However, it's doing that by checking some sort of numbers and using those for figuring out of the 32-bit client is faster. This might be the CPU time or the quantity of credits gained. By default BOINC will always begin by downloading the client that matches the bitness of the BOINC manager, then seeing if the 32-bit client is faster.

If you feel like experimenting a bit you might want to try editing the XML files in the BOINC data folder. BOINC saves benchmark information to those, and you might be able to make BOINC think that the 32-bit client is slower. I took a quick look, and sched_request_www.renderfarm.fi.xml might be a good place to start. Maybe removing the <alt_platform> field or replacing the name i686-pc-linux-gnu with x86_64-pc-linux-gnu. Or, maybe some of the data more down in the file (FLOPS) could be changed. Although it would seem that those files are changed constantly, so tweaking them manually might not do the trick. One idea I got was editing Glue (the middleware program between BOINC and Blender) to check the architecture of the system and forcibly launch the correct Blender client. That would take some coding to do, and I haven't considered if that would bring forth any other issues.

After hours of searching. I found <no_alt_platform>. Added it to my cc_config.xml file, restarted the client, reset the project, and re-attached (not sure if all that was required). So far, my first task started up 64 bit. Hope it stays that way.

http://boinc.berkeley.edu/wiki/Client_configuration says no_alt_platform will "run applications only for its primary platform. For example, a Win64 machine will run only Win64 apps, and not Win32."

You should note, though, that no_alt_platform will cause your client to ONLY download clients for your exact system. If you participate in other BOINC projects that have no 64bit clients available but produce compatible 32bit clients you will NOT get work there anymore. Now you've been warned.

There's currently a conversation going on in the BOINC project email list about this. Seems like lots of users and project admins are lost about this, myself included before enlightened. There might probably be a "fix" for this "bug" at some point. There already exists functionality for doing this server side, but it isn't in the stable server release yet (I think)