SIGSEGV: segmentation violation

Author	Message
dhh Send message Joined: 5 Jul 18 Posts: 3 Credit: 1,474,700 RAC: 0	Message 1900 - Posted: 5 Jul 2018, 17:35:01 UTC I have just started running NFS@HOME WUs, and I am having problems with instant application crashes. This is on a debian linux 10 system, that is kernel 4.16.0-1. The system is a Ryzen 2700X with 32GB of RAM. In general this system processes all other BOINC-projects I have tried without problems, however this might be too new for NFS@HOME? So I'd be happy about some feedback, either from anyone having similar problems or even better from anyone knowing a fix for the problem. All showing the following message in the STDERR log for the task: <core_client_version>7.10.3</core_client_version> <![CDATA[ <message> process got signal 11</message> <stderr_txt> SIGSEGV: segmentation violation </stderr_txt> ]]> Since is a segmentation violation, i.e. the code performing illegal I/O access, I checked the syslog and all runs leave messages of the type lasievee_1.10_x[4301] vsyscall attempted with vsyscall=none ip:ffffffffff600000 cs:33 sp:7ffc569592d8 ax:ffffffffff600000 si:0 di:7ffc569592f0 ID: 1900 · Rating: 0 · rate: / Reply Quote

biodoc Send message Joined: 31 Oct 09 Posts: 2 Credit: 45,249,104 RAC: 18,416	Message 1901 - Posted: 5 Jul 2018, 19:56:58 UTC I had the same problem with my 2700X running on Antergos Linux [4.17.3-1-ARCH]. I solved the problem by installing Linux Mint 19 Tara [4.15.0-24-generic\|. I've completed 127 tasks with no errors so far but haven't released them to the server yet. Maybe there is an issue with kernels 4.16 and later? ID: 1901 · Rating: 0 · rate: / Reply Quote

dhh Send message Joined: 5 Jul 18 Posts: 3 Credit: 1,474,700 RAC: 0	Message 1903 - Posted: 6 Jul 2018, 5:14:38 UTC - in response to Message 1901. Maybe there is an issue with kernels 4.16 and later? Yes that might be! As an update: I can process NFS@Home WUs under Ubuntu 18.04 LTS on the same hardware without problems. Software-wise that is a system fairly equivalent to Debian 10. However the kernel is version 4.15.0-20. ID: 1903 · Rating: 0 · rate: / Reply Quote

biodoc Send message Joined: 31 Oct 09 Posts: 2 Credit: 45,249,104 RAC: 18,416	Message 1904 - Posted: 6 Jul 2018, 10:12:26 UTC On YAFU, the following solution to a similar issue seemed to work. Configure the bootloader to use the kernel parameter "vsyscall=emulate" ID: 1904 · Rating: 0 · rate: / Reply Quote

dhh Send message Joined: 5 Jul 18 Posts: 3 Credit: 1,474,700 RAC: 0	Message 1905 - Posted: 6 Jul 2018, 13:56:11 UTC - in response to Message 1904. Configure the bootloader to use the kernel parameter "vsyscall=emulate" Thank you very much!! That is solving my problem with NFS@Home too :-)! ID: 1905 · Rating: 0 · rate: / Reply Quote

[AF>Libristes]Maeda Send message Joined: 3 May 19 Posts: 2 Credit: 6,381,050 RAC: 59	Message 2024 - Posted: 5 May 2019, 7:20:41 UTC Last modified: 5 May 2019, 7:21:07 UTC Hello, it is the same for me. Adding this line is not a solution, just a workaround and doesn't have to be there (for security reason). The real solution is to rebuild the NFS application using a recent glibc. May the dev have a plan for this, as many Linux distribution will have this need in the near future ? ID: 2024 · Rating: 0 · rate: / Reply Quote

[AF>Libristes] Dudumomo Send message Joined: 30 Sep 09 Posts: 1 Credit: 12,810,570 RAC: 0	Message 2047 - Posted: 22 Aug 2019, 13:33:41 UTC - in response to Message 2024. Same here, it did the trick, but it is probably not a long term solution. Hope the dev will be able to fix this. Thanks ID: 2047 · Rating: 0 · rate: / Reply Quote