| Index | Recent Threads | Unanswered Threads | Who's Active | Guidelines | Search |
 |
World Community Grid Forums
Category: Completed Research
Forum: FightAIDS@Home
Thread: Linux FAAH workunits crash as soon as they start |
| No member browsing this thread |
|
Thread Status: Active Total posts in this thread: 8
|
|
| Author |
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
For the past few weeks any new FAAH workunits on my Linux pc crash immediately after starting. FAAH previously worked OK. Has anything changed ? I tried reseeting the project, still no good.
|
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Hello rcbutcher,
What other projects run well on your system? Lawrence |
|||
|
||||
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
This Linux AMD_64 cpu is running BBC CPDN, Rosetta, LHC, QMC, Malaria with no problems. Is there something about the FAAH workunits that requires 32-bit shared modules ? Where do I find the actual error messages ?
|
||
|
|
Sekerob
Ace Cruncher Joined: Jul 24, 2005 Post Count: 20043 Status: Offline |
Error messages are either to be found in the Message tab or in a log(txt) file u can find in the BOINC dir and finally the a log that sits in the Result Status pages under the Status column.
----------------------------------------System Requirements are specified here: http://www.worldcommunitygrid.org/help/viewTopic.do?shortName=minimumreq and show for Linux, Mac and Windows and detailed by project. Not familiar with '32-bit Shared Module' and why u think this could interfere with the operations. Certainly, the science is not configured to run in 64-bit.
WCG
----------------------------------------Please help to make the Forums an enjoyable experience for All! [Edit 1 times, last edit by Sekerob at Jan 2, 2007 10:17:41 AM] |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
I was referring to shared libraries (libabcxyz.so.0 etc). If the faah program tries to use any shared libraries on my machine it will likely fail because they are all 64-bit and boinc programs are 32-bit. But the other boinc programs I referred to work OK.
The error message on the results status page is <core_client_version>5.4.11</core_client_version> <message> process got signal 11 </message> <stderr_txt> INFO: wcg_faah_autodock_5.28_i686-pc-linux-gnu Start AutoGrid... About to call graphics init </stderr_txt> Looks like it's trying to use my graphics system. ? But I don't use any of the visualization stuff, so it really doesn't need to. |
||
|
|
Alther
Former World Community Grid Tech United States of America Joined: Sep 30, 2004 Post Count: 414 Status: Offline Project Badges: 
|
I was referring to shared libraries (libabcxyz.so.0 etc). If the faah program tries to use any shared libraries on my machine it will likely fail because they are all 64-bit and boinc programs are 32-bit. But the other boinc programs I referred to work OK. The error message on the results status page is <core_client_version>5.4.11</core_client_version> <message> process got signal 11 </message> <stderr_txt> INFO: wcg_faah_autodock_5.28_i686-pc-linux-gnu Start AutoGrid... About to call graphics init </stderr_txt> Looks like it's trying to use my graphics system. ? But I don't use any of the visualization stuff, so it really doesn't need to. The graphics code is contained in a shared object, which is linked to OpenGL and other shared objects. This library is loaded and initialized on application startup. Graphics aren't actually shown unless you display them, but the library is initialized to inform BOINC that graphics are available, thus enabling the "Show Graphics" button....or not depending on whether the library was successfully loaded or not. If you are running in strict 64-bit mode and don't have any 32-bit shared objs on your system, this library will obviously fail to load. However, even if it fails to load, it's not supposed to crash. The code is supposed to handle loading failure gracefully (i.e. continue on without graphics). It's also possible that it actually crashes due to a bug in Linux when run on a strictly 64-bit system (e.g. the dlopen() call crashes instead of returning NULL...though this is unlikely). That is a scenario I believe we haven't tested on yet. The problem with this scenario is that would mean ALL of our WCG apps with graphics would crash on your system. Those without graphics would run fine. Have you noticed this ONLY with FAAH or have you noticed this recently with HDC or GC projects?
Rick Alther
Former World Community Grid Developer |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
I was referring to shared libraries (libabcxyz.so.0 etc). If the faah program tries to use any shared libraries on my machine it will likely fail because they are all 64-bit and boinc programs are 32-bit. But the other boinc programs I referred to work OK. The error message on the results status page is <core_client_version>5.4.11</core_client_version> <message> process got signal 11 </message> <stderr_txt> INFO: wcg_faah_autodock_5.28_i686-pc-linux-gnu Start AutoGrid... About to call graphics init </stderr_txt> Looks like it's trying to use my graphics system. ? But I don't use any of the visualization stuff, so it really doesn't need to. The graphics code is contained in a shared object, which is linked to OpenGL and other shared objects. This library is loaded and initialized on application startup. Graphics aren't actually shown unless you display them, but the library is initialized to inform BOINC that graphics are available, thus enabling the "Show Graphics" button....or not depending on whether the library was successfully loaded or not. If you are running in strict 64-bit mode and don't have any 32-bit shared objs on your system, this library will obviously fail to load. However, even if it fails to load, it's not supposed to crash. The code is supposed to handle loading failure gracefully (i.e. continue on without graphics). It's also possible that it actually crashes due to a bug in Linux when run on a strictly 64-bit system (e.g. the dlopen() call crashes instead of returning NULL...though this is unlikely). That is a scenario I believe we haven't tested on yet. The problem with this scenario is that would mean ALL of our WCG apps with graphics would crash on your system. Those without graphics would run fine. Have you noticed this ONLY with FAAH or have you noticed this recently with HDC or GC projects? I can't tell you what my box does with other WCG projects as they all come back with "Message from server: No work is available for ... (GC, HDC..)" |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
I get what looks like the same error for HDC.
<core_client_version>5.4.11</core_client_version> <message> process got signal 11 </message> <stderr_txt> About to call graphics init </stderr_txt> |
||
|
|
|