My understanding of the error is that it's an error code being returned by the WCG code, not by the BOINC code. For some reason the WGC code stops running and spits out that 0x83 error when it does.

This is based on the entry at http://boinc-doc.net/boinc-wiki/index.php?tit...de-number-hex%29%27%29%29

Error 131 may very well be a BOINC error. If a BOINC function returns an error to us and we determine we need to exit, we exit with the error code BOINC gave us. Due to the way Linux deals with process exit codes (they can only be in the range of 0 - 255 - 'man 3 exit' for detailed info), we return the absolute value of a BOINC return code, so it may very well be that 131 is really a -131 BOINC return code, meaning a file was too large. We did this simply for ease of seeing the exit codes rather than having to bitmask them to find the real error code. I'm not sure what to make of that though. Also, the Rosetta code itself doesn't have a 131 return code in it.

Has anyone else seen a 131 exit code?

As for the segment violation, we've seen a few of these and it's not tied to any particular workunit, CPU architecture or OS. All of the stack traces I've looked at point to this being a problem in the BOINC code, but we don't know exactly what's going on. I suspect a race condition in the BOINC thread spawned by the application, but it's just a guess.

Yup, that's exactly what I said in my first paragraph.

The return code is originating from a BOINC function we call, then we just propagate it through the exit() call (we exit because BOINC returned an error to us).