+- +-
Say hello if visiting :) by Gecko
11 Jan 2023, 07:43:05 pm

Seti is down again by Mike
09 Aug 2017, 10:02:44 am

Some considerations regarding OpenCL MultiBeam app tuning from algorithm view by Raistmer
11 Dec 2016, 06:30:56 am

Loading APU to the limit: performance considerations by Mike
05 Nov 2016, 06:49:26 am

Better sleep on Windows - new round by Raistmer
26 Aug 2016, 02:02:31 pm

Author Topic: Linux 64 bit AK_v8 SSSE3 problem from boinc_opt  (Read 5026 times)

Offline Josef W. Segur

  • Janitor o' the Board
  • Knight who says 'Ni!'
  • *****
  • Posts: 3112
Linux 64 bit AK_v8 SSSE3 problem from boinc_opt
« on: 28 Apr 2009, 01:15:10 pm »
Copying this message here in hopes someone can help the user.

Quote
   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

Offline Jason G

  • Construction Fraggle
  • Knight who says 'Ni!'
  • *****
  • Posts: 8980
Re: Linux 64 bit AK_v8 SSSE3 problem from boinc_opt
« Reply #1 on: 28 Apr 2009, 03:45:23 pm »
...
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.

 

Welcome, Guest.
Please login or register.
 
 
 
Forgot your password?
Members
Total Members: 97
Latest: ToeBee
New This Month: 0
New This Week: 0
New Today: 0
Stats
Total Posts: 59559
Total Topics: 1672
Most Online Today: 26
Most Online Ever: 983
(20 Jan 2020, 03:17:55 pm)
Users Online
Members: 0
Guests: 27
Total: 27
Powered by EzPortal