Hello,

I have this on my clear linux 4.14.9

https://setiathome.berkeley.edu/result.php?resultid=6264400750

<core_client_version>7.2.42</core_client_version>
<![CDATA[
<message>
process got signal 11
</message>
<stderr_txt>
SIGSEGV: segmentation violation

</stderr_txt>
]]>

What i could do ?
I try to add vsyscall emulation, may be i fail :s

Other ideas ?

Thx guy

May be of use.
https://github.com/BOINC/boinc/issues/2120
https://stackoverflow.com/questions/29377245/how-to-check-the-vsyscall-mode
"Your analysis is correct. For kernel 4.11 and newer you need to set the kernel option vsyscall=emulate in order to run applications compiled with older glibc."

---

Grant
Darwin NT

Hello,
I have this on my clear linux 4.14.9
https://setiathome.berkeley.edu/result.php?resultid=6264400750

<core_client_version>7.2.42</core_client_version>
<![CDATA[
<message>
process got signal 11
</message>
<stderr_txt>
SIGSEGV: segmentation violation
</stderr_txt>
]]>

What i could do ?

The Stock Apps are built with an older OS to ensure compatibility. Since you are running a New OS, with a New Processor, you should try a New CPU App built with a Newer OS. There are a few around, some here, http://lunatics.kwsn.info/index.php?action=downloads;cat=48 If you are able to manually configure an app_info.xml you can even try the Latest AVX2 CPU App from here, TEST for Linux AVX2 CPU. I suppose I should change that post at some point, the 'Test' is over, the Apps work very well on the machines running them. Here's one machine running the Intel version, AVX2jf Linux64 Build 3712

I dont fix my "SIGSEGV: segmentation violation" .
I rebuilt the kerne with intel clear linux dev aids :s but it dont work

I going to try this TBar

This working thank with AVX,
Next step try AVX2 or SE4.2

Great news. I've done some benchmark testing for TBar with the AVX2 app and compared it to the AVX and SSE4.1 app. Marginally faster on AMD hardware. Probably much faster on Intel hardware since Intel kinda has driven all the SSE improvements over the years. I also believe, may be mistaken, that Intel engineers specific hardware paths for AVX2 which should prove faster.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

The Problem with AVX2 on AMD is only ONE AMD Processor supports AVX2, that being Ryzen. To compile an Optimized App for Ryzen you Must use GCC 6.3 or higher, otherwise you have to compile for Bulldozer with doesn't have AVX2. The current SETI Software/Code doesn't work with any GCC version higher than 4.9.2, meaning the AMD AVX2 App is compiled for Bulldozer, which doesn't have AVX2...the compiler knows this BTW. I'm surprised AVX2 even works in that AMD App, by all rights it shouldn't. Maybe once the SETI Code works with GCC 6.3 it will be possible to compile a True AMD AVX2 App. The Intel App is different, AVX2 has been around for quite a while in Intel Processors and there isn't any problem compiling an Intel App for AVX2. That is the difference.

The Problem with AVX2 on AMD is only ONE AMD Processor supports AVX2, that being Ryzen. To compile an Optimized App for Ryzen you Must use GCC 6.3 or higher, otherwise you have to compile for Bulldozer with doesn't have AVX2. The current SETI Software/Code doesn't work with any GCC version higher than 4.9.2, meaning the AMD AVX2 App is compiled for Bulldozer, which doesn't have AVX2...the compiler knows this BTW. I'm surprised AVX2 even works in that AMD App, by all rights it shouldn't. Maybe once the SETI Code works with GCC 6.3 it will be possible to compile a True AMD AVX2 App. The Intel App is different, AVX2 has been around for quite a while in Intel Processors and there isn't any problem compiling an Intel App for AVX2. That is the difference.

I remember you mentioning this before. Granted, I only did about 8 hours of benchmark testing between the 3 choices, but the AVX2 app came out a few percent faster than the AVX app which which works on Bulldozer and Piledriver. I realize the sample population was way too low, it could have been just a lucky mix of work units. But at least I don't see a PENALTY for running the AVX2 compiled app.

Will just cross my fingers and toes for a BOINC that works with GCC 6.3 in the future and bide my time.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

If they updated the Seti apps to use GCC 6 then the OP wouldn’t need the the vsyscall=emulate, at least for Seti.

The Einstein developers recently rebuilt one of their apps using libc 2.15 (from around 2012) to work around the issue. I would have thought they would update to a later version rather than going to even older code, but maybe it’s too hard.

---

BOINC blog

I have been trying to run seti on my NAS computer that runs based on Centos/Fedora.

I am able to run e.g. World Community grid and Rosetta, but with Seti, after some time, the crunching starts to fail.

In the results for the WU's I get this:

terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc
SIGABRT: abort called
Stack trace (12 frames)

Is this the same problem as described in this thread?

---

I don't think so. I think your error is a different type of memory allocation error. I'd like others to comment with any insight they might have.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)