Problem with stock AP 5.06 apps

[Cosmic_Ocean]

First off, I would love to try the beta, but my post count isn't as built-up here as it is on the SETI forum (probably should fix that..)

Secondly, I think I have a different AP problem using the stock apps.  For both 32 and 64-bit, both of them immediately fail with 'Floating point exception' in stand-alone testing.

Stock 5.03 32/64 operates in stand-alone just fine, as well as r112 [edit: typed 168 initially] (32/64).

Kernel is 2.6.16.21-0.8-default

CPU: AMD Sempron64 3400+ (can do SSE3)

I haven't been able to find if this is a common problem, or not, as AP has been scarce for the past few weeks until we ran out of MB over the weekend.

Any suggestions or input would be appreciated, and I will provide more details upon request.

[sunu]

Checking your hosts I've only seen one workunit with errors: http://setiathome.berkeley.edu/result.php?resultid=1352571512. Copying it here in case it disappears:

<core_client_version>6.2.15</core_client_version>
<![CDATA[
<message>
process exited with code 22 (0x16, -234)
</message>
<stderr_txt>
execv: Permission denied

</stderr_txt>


Please see http://boincfaq.mundayweb.com/index.php?language=1&view=280 . Also check to see if boinc and seti clients have proper permissions and are set as executables. That boinc version is quite old, you could use a newer one.

Is there any particular reason that you run such an old kernel?

[Cosmic_Ocean]

When I added the stock 5.06 to the app_info, I copied the section for 503 and changed the app name to 'astropulse_v505', the version to 505, and the file name accordingly.  Also made sure to do a chown and chmod to match everything else that has always worked.

Second, the kernel is old, as is the client, but they get the job done.  The kernel is so old because that's what came with the vanilla release of SLES10 and I have not updated it, because the last time I tried a kernel update, I bricked the system.  That box used to be a 64-bit test bed for a theoretical physics system I was involved in, but the project fell apart, so I threw BOINC on it.

6.2.15 is old, but realistically, there is not a good enough reason to upgrade it.  I do not need CUDA support, and it does not have any problems.

Also, as I said, after that one failed task, I decided to try a stand-alone test (make a new directory somewhere, copy a WU and the executable to there, rename the WU to 'in.dat', and run the application).  That ends up going like this:

Code: [Select]

altair:~/boinctest # ./astropulse_5.06_x86_64-pc-linux-gnu
Floating point exception
altair:~/boinctest # ./astropulse_5.06_i686-pc-linux-gnu
Floating point exception
altair:~/boinctest #
Both of those were grabbed from fanout where the WUs are.

Stock 5.03 32/64 work properly, as does r112 32/64.

[Cosmic_Ocean]

Also as a side-note, I noticed r168 showed up on the downloads page, so I grabbed it and ran ldd on it.  I need GLIBCXX_3.4.9, and my current libstdc++ provides all the way up to 3.4.8..

Found a newer RPM for libstdc++, but half the system depends on the current version that isn't quite up to par, and therefore cannot be installed or upgraded.

I would rather not have to reinstall the system with some other distro just because of one package.  Also the uptime is closing in on a full year.

[Urs Echternacht]

Also as a side-note, I noticed r168 showed up on the downloads page, so I grabbed it and ran ldd on it.  I need GLIBCXX_3.4.9, and my current libstdc++ provides all the way up to 3.4.8..

Found a newer RPM for libstdc++, but half the system depends on the current version that isn't quite up to par, and therefore cannot be installed or upgraded.

I would rather not have to reinstall the system with some other distro just because of one package.  Also the uptime is closing in on a full year.

Sorry, Cosmic_Ocean, but if you had read the README_APP.txt that came in the released package you could have known that before the failures. kernel versions below 2.6.22 are NOT supported. Therefor please update if you want to run this application.

p.s. Otherwise you could wait for official release of Linux opt. 64bit and 32bit applications and try to rebuild the application yourself from source. Maybe that is easier than updating your SLES-host.

[Cosmic_Ocean]

Sorry, Cosmic_Ocean, but if you had read the README_APP.txt that came in the released package you could have known that before the failures. kernel versions below 2.6.22 are NOT supported. Therefor please update if you want to run this application.

README's?  Who reads those? 

At any rate, seems like too much work to rebuild the app from source.  I wouldn't want my build to end up being incompatible somehow.

I'll probably just reinstall the OSes on the two Linux boxes with something newer.  I'm in the process of acquiring SLES11.  I'll give that a try in VMware and see if that solves the problem.

[Urs Echternacht]

Sorry, Cosmic_Ocean, but if you had read the README_APP.txt that came in the released package you could have known that before the failures. kernel versions below 2.6.22 are NOT supported. Therefor please update if you want to run this application.

README's?  Who reads those? 

At any rate, seems like too much work to rebuild the app from source.  I wouldn't want my build to end up being incompatible somehow.

I'll probably just reinstall the OSes on the two Linux boxes with something newer.  I'm in the process of acquiring SLES11.  I'll give that a try in VMware and see if that solves the problem.

That should do it, of course. SLES11 is using a new enough kernel version.

[Raistmer]

Sorry, Cosmic_Ocean, but if you had read the README_APP.txt that came in the released package you could have known that before the failures. kernel versions below 2.6.22 are NOT supported. Therefor please update if you want to run this application.

README's?  Who reads those? 

Hehe, but after time spent for readme composing and cleaning author may have big temptation just to write RTFM ! Keep this in mind

[Cosmic_Ocean]

I should note that I could not find a 'readme' for the stock apps in the fanout directory.  I tried stock first before posting here to see if there was any insight, and then found that r168 showed up on the download page.  That's when I ran into the GLIBCXX_3.4.9 problem, posted that observation here, then read the readme after I was told I should have read it.

That is all well and good, but all of that pertains to the opti app.  Am I to assume the stock app has the  same requirements?

[Cosmic_Ocean]

Alright, VMware testing seems hopeful.  Stock 32-bit app actually runs.  I was not able to test a 64-bit installation, but it should work.

Kernel in SLES11 is 2.6.27.19

Has two libstdc++'s installed.  One is 3.3.3, the other is 4.3.3

Code: [Select]

rpm -q --provides libstdc++43
...
libstdc++.so.6(GLIBCXX_3.4.9)
libstdc++43 = 4.3.3_20081022-11.18
So I think upgrading to SLES11 will do the trick.  Now to schedule some downtime..

[edit: upgrade installed.  tarballed the BOINC directory before formatting, and unpacked when done.  Installed the init.d boinc script, did a groupadd and useradd, unpacked the tarball, and fired it up.  Seems to be working fine, though it only does MB right now.

Loaded up the boinctest directory and the stock apps now work properly, as well as r168-64.  Just waiting for confirmation of r168's official release into main before adding it to app_info.]