Can anyone help decipher this message? Is it really trying to allocate that size? Is gcc really using malloc under all these boost code? :) malloc: *** mmap(size=380554168512811008) failed (error code=12) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc [jacques-richards-mac-mini:00700] *** Process received signal *** [jacques-richards-mac-mini:00700] Signal: Abort trap (6) [jacques-richards-mac-mini:00700] Signal code: (0) [jacques-richards-mac-mini:00700] [ 0] 2 libSystem.B.dylib 0x00007fff8449b1ba _sigtramp + 26 [jacques-richards-mac-mini:00700] [ 1] 3 ??? 0x0030303700837a50 0x0 + 13563811672062544 [jacques-richards-mac-mini:00700] [ 2] 4 libstdc++.6.dylib 0x00007fff809c65d2 __tcf_0 + 0 [jacques-richards-mac-mini:00700] [ 3] 5 libobjc.A.dylib 0x00007fff84609b4d _objc_terminate + 120 [jacques-richards-mac-mini:00700] [ 4] 6 libstdc++.6.dylib 0x00007fff809c4ae1 _ZN10__cxxabiv111__terminateEPFvvE + 11 [jacques-richards-mac-mini:00700] [ 5] 7 libstdc++.6.dylib 0x00007fff809c4b16 _ZN10__cxxabiv112__unexpectedEPFvvE + 0 [jacques-richards-mac-mini:00700] [ 6] 8 libstdc++.6.dylib 0x00007fff809c4bfc _ZL23__gxx_exception_cleanup19_Unwind_Reason_CodeP17_Unwind_Exception + 0 [jacques-richards-mac-mini:00700] [ 7] 9 libstdc++.6.dylib 0x00007fff809c4efb _Znwm + 87 [jacques-richards-mac-mini:00700] [ 8] 10 Mg 0x0000000100113608 _ZN9__gnu_cxx13new_allocatorI12lattice_typeE8allocateEmPKv + 70 [jacques-richards-mac-mini:00700] [ 9] 11 Mg 0x000000010011362f _ZNSt12_Vector_baseI12lattice_typeSaIS0_EE11_M_allocateEm + 37 [jacques-richards-mac-mini:00700] [10] 12 Mg 0x0000000100113658 _ZNSt6vectorI12lattice_typeSaIS0_EE20_M_allocate_and_copyIPS0_EES4_mT_S5_ + 38 [jacques-richards-mac-mini:00700] [11] 13 Mg 0x000000010011376a _ZNSt6vectorI12lattice_typeSaIS0_EE7reserveEm + 114 [jacques-richards-mac-mini:00700] [12] 14 Mg 0x0000000100113881 _ZNK5boost13serialization3stl11reserve_impISt6vectorI12lattice_typeSaIS4_EEEclERS6_m + 33 [jacques-richards-mac-mini:00700] [13] 15 Mg 0x000000010011738b _ZN5boost13serialization3stl15load_collectionINS_3mpi15packed_iarchiveESt6vectorI12lattice_typeSaIS6_EENS1_17archive_input_seqIS4_S8_EENS1_11reserve_impIS8_EEEEvRT_RT0_ + 189 [jacques-richards-mac-mini:00700] [14] 16 Mg 0x000000010011740c _ZN5boost13serialization4loadINS_3mpi15packed_iarchiveE12lattice_typeSaIS4_EEEvRT_RSt6vectorIT0_T1_EjN4mpl_5bool_ILb0EEE + 32 [jacques-richards-mac-mini:00700] [15] 17 Mg 0x0000000100117438 _ZN5boost13serialization4loadINS_3mpi15packed_iarchiveE12lattice_typeSaIS4_EEEvRT_RSt6vectorIT0_T1_Ej + 42 [jacques-richards-mac-mini:00700] [16] 18 Mg 0x0000000100117471 _ZN5boost13serialization11free_loaderINS_3mpi15packed_iarchiveESt6vectorI12lattice_typeSaIS5_EEE6invokeERS3_RS7_j + 55 [jacques-richards-mac-mini:00700] [17] 19 Mg 0x0000000100117496 _ZN5boost13serialization10split_freeINS_3mpi15packed_iarchiveESt6vectorI12lattice_typeSaIS5_EEEEvRT_RT0_j + 35 [jacques-richards-mac-mini:00700] [18] 20 Mg 0x00000001001174bb _ZN5boost13serialization9serializeINS_3mpi15packed_iarchiveE12lattice_typeSaIS4_EEEvRT_RSt6vectorIT0_T1_Ej + 35 [jacques-richards-mac-mini:00700] [19] 21 Mg 0x00000001001174f4 _ZN5boost13serialization13serialize_adlINS_3mpi15packed_iarchiveESt6vectorI12lattice_typeSaIS5_EEEEvRT_RT0_j + 55 [jacques-richards-mac-mini:00700] [20] 22 Mg 0x0000000100117529 _ZNK5boost7archive6detail11iserializerINS_3mpi15packed_iarchiveESt6vectorI12lattice_typeSaIS6_EEE16load_object_dataERNS1_14basic_iarchiveEPvj + 51 [jacques-richards-mac-mini:00700] [21] 23 libboost_serialization.dylib 0x0000000100533eb9 _ZN5boost7archive6detail14basic_iarchive11load_objectEPvRKNS1_17basic_iserializerE + 473 [jacques-richards-mac-mini:00700] [22] 24 Mg 0x00000001001178e3 _ZN5boost7archive6detail21load_non_pointer_typeINS_3mpi15packed_iarchiveEE13load_standard6invokeISt6vectorI12lattice_typeSaIS9_EEEEvRS4_RKT_ + 45 [jacques-richards-mac-mini:00700] [23] 25 Mg 0x000000010011790c _ZN5boost7archive6detail21load_non_pointer_typeINS_3mpi15packed_iarchiveEE6invokeISt6vectorI12lattice_typeSaIS8_EEEEvRS4_RT_ + 39 [jacques-richards-mac-mini:00700] [24] 26 Mg 0x0000000100117930 _ZN5boost7archive4loadINS_3mpi15packed_iarchiveESt6vectorI12lattice_typeSaIS5_EEEEvRT_RT0_ + 34 [jacques-richards-mac-mini:00700] [25] 27 Mg 0x000000010011795a _ZN5boost7archive6detail15common_iarchiveINS_3mpi15packed_iarchiveEE13load_overrideISt6vectorI12lattice_typeSaIS8_EEEEvRT_i + 40 [jacques-richards-mac-mini:00700] [26] 28 Mg 0x000000010011797f _ZN5boost3mpi15packed_iarchive13load_overrideISt6vectorI12lattice_typeSaIS4_EEEEvRT_iN4mpl_5bool_ILb0EEE + 35 [jacques-richards-mac-mini:00700] [27] 29 Mg 0x00000001001179ac _ZN5boost3mpi15packed_iarchive13load_overrideISt6vectorI12lattice_typeSaIS4_EEEEvRT_i + 42 [jacques-richards-mac-mini:00700] [28] 30 Mg 0x00000001001179d8 _ZN5boost7archive6detail18interface_iarchiveINS_3mpi15packed_iarchiveEErsISt6vectorI12lattice_typeSaIS8_EEEERS4_RT_ + 42 [jacques-richards-mac-mini:00700] [29] 31 Mg 0x0000000100117a0c _ZN5boost3mpi6detail21serialized_irecv_dataISt6vectorI12lattice_typeSaIS4_EEE11deserializeERNS0_6statusE + 40 [jacques-richards-mac-mini:00700] *** End of error message *** mpirun noticed that job rank 0 with PID 699 on node jacques-richards-mac-mini.local exited on signal 15 (Terminated). 1 additional process aborted (not shown) jacques-richards-mac-mini:SBF_T jacques$ Suspected cause: reqs.push_back( world.isend( Sender , SendTag , &Neighbor2Proc ) ) ; where std::vector< T > Neighbor2Proc ; Thanks!
Can anyone help decipher this message?
The lines in this call stack have "mangled" names. For instance, _ZNSt6vectorI12lattice_typeSaIS0_EE7reserveEm + 114 designates something like vector<lattice_type>::reserve()
Is it really trying to allocate that size? Is gcc really using malloc under all these boost code? :)
Yes, the bottom line is that it throws bad_alloc due to an attmpt to allocate a very large block. In line [12] you can see a call to boost::serialization::stl::reserve_imp<std::vector<lattice_type> >() it's called when Boost.Serialization loads your vector from a stream. However, for some reason it read an incorrect vector size -- perhaps the file is corrupted or there's some version mismatch.
Igor R wrote:
Can anyone help decipher this message?
The lines in this call stack have "mangled" names. For instance, _ZNSt6vectorI12lattice_typeSaIS0_EE7reserveEm + 114 designates something like vector<lattice_type>::reserve()
Is it really trying to allocate that size? Is gcc really using malloc under all these boost code? :)
Yes, the bottom line is that it throws bad_alloc due to an attmpt to allocate a very large block. In line [12] you can see a call to boost::serialization::stl::reserve_imp<std::vector<lattice_type> >() it's called when Boost.Serialization loads your vector from a stream. However, for some reason it read an incorrect vector size -- perhaps the file is corrupted or there's some version mismatch.
Or loading from a binary_archive that was saved with a different endianess. Jeff
The lines in this call stack have "mangled" names. For instance, _ZNSt6vectorI12lattice_typeSaIS0_EE7reserveEm + 114 designates something like vector<lattice_type>::reserve()
Is it really trying to allocate that size? Is gcc really using malloc under all these boost code? :)
Yes, the bottom line is that it throws bad_alloc due to an attmpt to allocate a very large block. In line [12] you can see a call to boost::serialization::stl::reserve_imp<std::vector<lattice_type> >() it's called when Boost.Serialization loads your vector from a stream. However, for some reason it read an incorrect vector size -- perhaps the file is corrupted or there's some version mismatch.
Or loading from a binary_archive that was saved with a different endianess.
Well, according to the call stack, it was mpi::packed_archive. I never used it, but googled-around a bit, and it seems that MPI handles endianness issues automatically, unless BOOST_MPI_HOMOGENOUS is defined.
Thank you all! Could it be that a lot more is being passed then I intended? Should I change reqs.push_back( world.isend( Sender , SendTag , &Neighbor2Proc ) ) ; to reqs.push_back( world.isend( Sender , SendTag , &Neighbor2Proc[ Sender ] ) ) ; ? But that made it worse! On Dec 20, 2011, at 7:12 AM, Jeff Flinn wrote:
Igor R wrote:
Can anyone help decipher this message? The lines in this call stack have "mangled" names. For instance, _ZNSt6vectorI12lattice_typeSaIS0_EE7reserveEm + 114 designates something like vector<lattice_type>::reserve() Is it really trying to allocate that size? Is gcc really using malloc under all these boost code? :) Yes, the bottom line is that it throws bad_alloc due to an attmpt to allocate a very large block. In line [12] you can see a call to boost::serialization::stl::reserve_imp<std::vector<lattice_type> >() it's called when Boost.Serialization loads your vector from a stream. However, for some reason it read an incorrect vector size -- perhaps the file is corrupted or there's some version mismatch.
Or loading from a binary_archive that was saved with a different endianess.
Jeff
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Dr. Jacques C. Richard NSF Research Experiences for Undergraduates (REU) Sites Sr. Lecturer/Research Associate, Aerospace Engineering Dept. Texas A & M University, College Station, TX 77843-3141 richard@tamu.edu 979-845-3916 (fax 6051) http://aeweb.tamu.edu/Richard/
participants (3)
-
Igor R -
Jacques C. Richard -
Jeff Flinn