64bit clients crash due to segmentation violation

Questions and Answers : Unix/Linux : 64bit clients crash due to segmentation violation
Message board moderation

To post messages, you must log in.


Send message
Joined: 2 Sep 18
Posts: 2
Credit: 1,072,071
RAC: 4,588
Message 1998478 - Posted: 16 Jun 2019, 23:14:11 UTC


Is it normal that setiathome_8.00_x86_64-pc-linux-gnu process fails each time with segmentation fault?

setiathome_8.05_i686-pc-linux-gnu works fine, but it doesn't seem right that 64b version doesn't work on 64b CPU.
setiathome_8.00_x86_64-pc-linux-gnu crashes each time. If that's expected (i.e. this binary is broken) then what's the point of sending tasks that use a broken binary?

$ ldd ./setiathome_8.05_i686-pc-linux-gnu 
	not a dynamic executable
$ file ./setiathome_8.05_i686-pc-linux-gnu 
./setiathome_8.05_i686-pc-linux-gnu: ELF 32-bit LSB executable, Intel 80386, version 1 (GNU/Linux), statically linked, for GNU/Linux 2.6.18, BuildID[sha1]=97fdf692216e3cf4357b37395e15ae70a28db86e, stripped
$ ldd ./setiathome_8.00_x86_64-pc-linux-gnu 
	not a dynamic executable
$ file ./setiathome_8.00_x86_64-pc-linux-gnu
./setiathome_8.00_x86_64-pc-linux-gnu: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, for GNU/Linux 2.6.18, BuildID[sha1]=4bd040ef6864f72e0cff04873128044337f1aca5, stripped

Binary itself seems to work:
$ ./setiathome_8.00_x86_64-pc-linux-gnu -version
SETI@home client.
Version: 8.00

SETI@home is sponsored by individual donors around the world.
(... a lot of text ...)
Tetsuji 'Maverick' Rai and Rom Walton

So it doesn't seem to miss any libraries etc. If I execute it without any options it will crash every time:
# ./setiathome_8.00_x86_64-pc-linux-gnu 
Segmentation fault (core dumped)

Execution in gdb doesn't explain much:
Reading symbols from ./setiathome_8.00_x86_64-pc-linux-gnu...
(No debugging symbols found in ./setiathome_8.00_x86_64-pc-linux-gnu)
(gdb) run
Starting program: /var/lib/boinc/projects/setiathome.berkeley.edu/setiathome_8.00_x86_64-pc-linux-gnu 

Program received signal SIGSEGV, Segmentation fault.
0xffffffffff600400 in ?? ()
(gdb) bt
#0  0xffffffffff600400 in ?? ()
#1  0x000000000074b3ad in ?? ()
#2  0x00000000004c17e3 in ?? ()
#3  0x00000000004c2996 in ?? ()
#4  0x00000000004007aa in ?? ()
#5  0x00000000006f716b in ?? ()
#6  0x0000000000400449 in ?? ()
#7  0x00007fffffffeb48 in ?? ()
#8  0x0000000000000000 in ?? ()
(gdb) info th
  Id   Target Id                      Frame 
* 1    process 5821 "setiathome_8.00" 0xffffffffff600400 in ?? ()

Stack looks kinda wierd due to that 0x00 at the very bottom.

When I run i686 version in the same way app just exits with code 251. Probably notices missing options and bails out.

I checked it with strace and it seems to try to actually do something, but fails fast:
$ strace -e file ./setiathome_8.00_x86_64-pc-linux-gnu
execve("./setiathome_8.00_x86_64-pc-linux-gnu", ["./setiathome_8.00_x86_64-pc-linu"...], 0x7ffcce07c420 /* 17 vars */) = 0
stat("stderr.txt", {st_mode=S_IFREG|0644, st_size=283, ...}) = 0
open("stderr.txt", O_WRONLY|O_CREAT|O_APPEND, 0666) = 2
open("init_data.xml", O_RDONLY)         = -1 ENOENT (No such file or directory)
stat("init_data.xml", 0x7ffdf7f09a90)   = -1 ENOENT (No such file or directory)
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0xffffffffff600400} ---
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0xffffffffff600400} ---
+++ killed by SIGSEGV (core dumped) +++
Segmentation fault (core dumped)

When I run it with -e all it also crashes right after that stat call. I have no idea if that's what happens when executed by boinc.

i686 version seems to do same thing:
# strace -e file ./setiathome_8.05_i686-pc-linux-gnu
execve("./setiathome_8.05_i686-pc-linux-gnu", ["./setiathome_8.05_i686-pc-linux-"...], 0x7ffefce1d460 /* 17 vars */) = 0
strace: [ Process PID=6018 runs in 32 bit mode. ]
stat64("stderr.txt", {st_mode=S_IFREG|0644, st_size=726, ...}) = 0
open("stderr.txt", O_WRONLY|O_CREAT|O_APPEND|O_LARGEFILE, 0666) = 2
open("init_data.xml", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
stat64("init_data.xml", 0xff914370)     = -1 ENOENT (No such file or directory)
open("/etc/localtime", O_RDONLY)        = 3
open("boinc_setiathome_0", O_RDWR|O_CREAT|O_LARGEFILE, 0666) = 3
chmod("boinc_setiathome_0", 0660)       = 0
open("boinc_lockfile", O_WRONLY|O_CREAT|O_LARGEFILE, 0664) = 3
stat64("init_data.xml", 0xff913c30)     = -1 ENOENT (No such file or directory)
lstat64("work_unit.sah", 0xff913d50)    = -1 ENOENT (No such file or directory)
stat64("work_unit.sah", 0xff913d10)     = -1 ENOENT (No such file or directory)
stat64("work_unit.sah", 0xff913f50)     = -1 ENOENT (No such file or directory)
+++ exited with 251 +++

But it continues and just exits gracefully.

Environment information:
up-to-date Arch Linux (fresh install),
CPU: Intel(R) Atom(TM) x5-Z8350 CPU @ 1.44GHz (multiple machines, same issue on every one)
uname: Linux 5.1.9-arch1-1-ARCH #1 SMP PREEMPT Tue Jun 11 16:18:09 UTC 2019 x86_64 GNU/Linux

However this happens also on my desktop machine:
same OS, also up-to-date.
CPU: Intel(R) Core(TM) i5-3350P CPU @ 3.10GHz

Are there binaries that contain debug symbols so I can dig deeper or maybe I should just ignore it and wait for x86_64 queue to be failed and replaced by i686 one (which happens eventually)?
ID: 1998478 · Report as offensive
Profile Keith Myers Project Donor
Volunteer tester

Send message
Joined: 29 Apr 01
Posts: 11421
Credit: 1,155,091,829
RAC: 1,047,136
United States
Message 2000159 - Posted: 28 Jun 2019, 20:00:14 UTC

Not sure where you got those executables. They don't appear to be valid Seti cpu applications that are shown on the applications page.
The official Linux x86_64 is version 8.00. I believe the binary is named MBv8_8.0r3305_sse3_x86_64-pc-linux-gnu.
Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)
ID: 2000159 · Report as offensive

Send message
Joined: 2 Sep 18
Posts: 2
Credit: 1,072,071
RAC: 4,588
Message 2003078 - Posted: 17 Jul 2019, 23:12:01 UTC

Executables were downloaded automatically by BOINC client when I attached SETI project using --project_attach in boinccmd.

x86_64 version is marked as 8.00: setiathome_8.00_x86_64-pc-linux-gnu
i686 version is marked as 8.05: setiathome_8.05_i686-pc-linux-gnu

Both match versions listed on page you provided. Too bad that there isn't any easy way to validate the files by checking signatures or at least checksums. I can only assume that automatically downloaded are valid.

SHA-256 of both files:
d184f1bd05998711bfeac747366d19446c0e59c2e57e8a8cc2cb88b2e3724c97 setiathome_8.00_x86_64-pc-linux-gnu
9d93a96df6b32f0cff4eb943892a0f8cf33eeff3e0d7ab326906fa384140849f setiathome_8.05_i686-pc-linux-gnu

Both compiled with GCC 4.4.7:
setiathome_v8 8.00 Revision: 3290 g++ (GCC) 4.4.7 20120313 (Red Hat 4.4.7-4)
setiathome_v8 8.00 Revision: 3335 g++ (GCC) 4.4.7 20120313 (Red Hat 4.4.7-4)
for x86_64 and i686 version respectively.
ID: 2003078 · Report as offensive

Questions and Answers : Unix/Linux : 64bit clients crash due to segmentation violation

©2020 University of California
SETI@home and Astropulse are funded by grants from the National Science Foundation, NASA, and donations from SETI@home volunteers. AstroPulse is funded in part by the NSF through grant AST-0307956.