Linux 64 bit AK_v8 SSSE3 problem from boinc_opt

[Josef W. Segur]

Copying this message here in hopes someone can help the user.

   From:   erbenton <erbenton@comcast.net>
   To:   List for discussing optimization of BOINC apps <boinc_opt@ssl.berkeley.edu>
   Subject:   [Boinc_opt] Seti WU Computation errors
   Date sent:   Sun, 26 Apr 2009 12:52:02 -0700

I have been noticing that about 1 in 20-30 or so WU's i process result in
computation errors Below is some data i extracted from client_state.xml
which i suspect is representative, although i cant say for sure that all
the errors are like this. My system is an Intel DG33TL, 4Gig DDR2-800 ram,
Q6600 cpu running Mandriva 2008.1 in 64 bit mode and i have 15 Gig of free
disk space. The seti client is the optimized version, see details of that
in the data below. Any ideas as to whats going wrong here? Thanks Eric


<result>
    <name>26dc08aa.15208.7963.7.8.20_0</name>
    <final_cpu_time>2155.239468</final_cpu_time>
    <exit_status>131</exit_status>
    <state>3</state>
    <platform>x86_64-pc-linux-gnu</platform>
    <version_num>528</version_num>
    <fpops_cumulative>27019323134582.394531</fpops_cumulative>
<stderr_out>
<![CDATA[
<message>
process exited with code 131 (0x83, -125)
</message>
<stderr_txt>
Linux optimized S@H Enhanced application by Alex Kan
Version info: SSSE3x (Intel, Core 2-optimized v8-nographics) V5.13 by Alex
Kan SSSE3x Linux64 Build 46 PGO, Ported by : Jason G, Raistmer, JDWhale

Processor Information:
  Model: Intel Core 2 Quad Q6600, 2.39 GHz
  Package: 4 Cores

Processor Caches:
  L1 code cache, 32 KB
  L1 data cache, 32 KB
  L2 combined cache, 4 MB

Processor Features:   64bit   simd   [x86]   cmov   mmx   sse   sse2 
sse3   ssse3   vmx   lm   lahf_lm   tm   tm2   eist   nx

Work Unit Info:
...............
Credit multiplier is :  2.85
WU true angle range is :  0.007256
terminate called after throwing an instance of 'std::bad_alloc'
  what():  St9bad_alloc
SIGABRT: abort calledStack trace (18 frames):
AK_V8_linux64_ssse3(boinc_catch_signal+0x17d)[0x43b70d]
/lib64/libpthread.so.0[0x7f469f391350]
/lib64/libc.so.6(gsignal+0x35)[0x7f469f05fa55]
/lib64/libc.so.6(abort+0x110)[0x7f469f0611e0]
AK_V8_linux64_ssse3[0x576234]
AK_V8_linux64_ssse3[0x56a706]
AK_V8_linux64_ssse3[0x56a733]
AK_V8_linux64_ssse3[0x56cafa]
AK_V8_linux64_ssse3[0x56c539]
AK_V8_linux64_ssse3[0x5cf0df]
AK_V8_linux64_ssse3[0x5bd1c5]
AK_V8_linux64_ssse3[0x419d0a]
AK_V8_linux64_ssse3[0x415950]
AK_V8_linux64_ssse3[0x4149a2]
AK_V8_linux64_ssse3[0x405f7a]
AK_V8_linux64_ssse3[0x405612]
/lib64/libc.so.6(__libc_start_main+0xf4)[0x7f469f04d074]
AK_V8_linux64_ssse3(realloc+0x181)[0x405379]

Exiting...

</stderr_txt>
]]>

                                                                                        Joe

[Jason G]

...
WU true angle range is :  0.007256
terminate called after throwing an instance of 'std::bad_alloc'
...

If it does not reproduce on similar setups, then I would expect some kernel issue, perhaps requiring update.

If this is reproducible with similar hosts/OS with such VLAR tasks, then I would suspect something like insufficient stack space assigned at build time perhaps. 

Is there a way to get better symbol information into that dump on Linux?  Assuming not physically out of memory, There are other possible causes of throwing  std:bad_alloc, related to the use of STL vector classes, and accidentally passing large vectors copied onto the stack, rather than by reference, or somehow providing huge numbers to 'new'.  A better call-stack representation would be helpful in pinpointing such an issue, if something like that is the cause.