Hello Tim -
I've had many, many problems keeping cisTEM running. We have an SBGrid installation on a data server, and source it from our workstations. This is relevant because 2D classification can run on one workstation, but dies very frequently on the other. Often we switch workstations just for that step, even though both are using the exact same pre-compiled binaries.
I've spent a good amount of time troubleshooting this, and I think I have found something that may be useful to you guys:
dmesg reports lines like this after it crashes:
[1032090.216520] merge2d: segfault at 5400000053 ip 0000005400000053 sp 00007ffe776a68f8 error 14 in UTF-32.so[7fb74d9ca000+2000]
[1120935.158934] merge2d: segfault at 5400000053 ip 0000005400000053 sp 00007ffcd1d70578 error 14 in UTF-32.so[7f3a565ea000+2000]
[1464120.322251] merge2d: segfault at 5400000053 ip 0000005400000053 sp 00007ffe2d3687f8 error 14 in UTF-32.so[7fe4e0859000+2000]
Segfautls aren't always in UTF-32.so, often we have observed errors in glibc as well. Crashes in 3D occur but much, much less frequently.
Both workstations give identical output for:
$ ldd --version
ldd (GNU libc) 2.17
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.
BUT - I found that I had 32-bit libraries on one system and not the other.
[STABLE System]$ yum list glibc
glibc.x86_64 2.17-292.el7 @base
glibc.i686 2.17-292.el7 base
[UNSTABLE System]$ yum list glibc
glibc.i686 2.17-292.el7 @base
I uninstalled the 32-bit libraries on the unstable system, and it seems to be running 2D classification without problems now. I'll report back if anything changes.
Does cisTEM use the system-level glibc/UTF-32? Does it check for x86 vs 64-bit presence?
Thank you for your time and efforts. Just sharing what I've observed, hopefully it's useful to you all as you wrap up cisTEM2.
D. John Lee