boost序列化binary_oarchive崩潰

首先，我正在填充一個相當大且具有相互關係的結構。然後我將它序列化爲一個二進制檔案。該結構的大小取決於我提供給程序的數據。我看到該程序需要2GB內存來構建預期和可接受的結構。boost序列化binary_oarchive崩潰

然後我開始序列化對象。我在序列化過程中看到程序正在吃RAM。 RAM使用量增長到接近100％。交換使用率仍然是0字節。

然後應用程序崩潰。除了bad_alloc對new

爲什麼序列化過程需要這麼多的RAM和時間？爲什麼當swap分配空時分配內存時會崩潰？回溯太長而無法完全粘貼。當一個較小的數據feeded它

#0 0xb7fe1424 in __kernel_vsyscall() 
#1 0xb7c6e941 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 
#2 0xb7c71e42 in abort() at abort.c:92 
#3 0xb7e92055 in __gnu_cxx::__verbose_terminate_handler()() from /usr/lib/libstdc++.so.6 
#4 0xb7e8ff35 in ??() from /usr/lib/libstdc++.so.6 
#5 0xb7e8ff72 in std::terminate()() from /usr/lib/libstdc++.so.6 
#6 0xb7e900e1 in __cxa_throw() from /usr/lib/libstdc++.so.6 
#7 0xb7e90677 in operator new(unsigned int)() from /usr/lib/libstdc++.so.6 
#8 0xb7f00a9f in boost::archive::detail::basic_oarchive_impl::save_pointer(boost::archive::detail::basic_oarchive&, void const*, boost::archive::detail::basic_pointer_oserializer const*)() from /usr/lib/libboost_serialization.so.1.42.0 
#9 0xb7effb42 in boost::archive::detail::basic_oarchive::save_pointer(void const*, boost::archive::detail::basic_pointer_oserializer const*)() from /usr/lib/libboost_serialization.so.1.42.0 
#10 0x082d052c in void boost::archive::detail::save_pointer_type<boost::archive::binary_oarchive>::non_polymorphic::save<gcl::NestedConnection<gcl::Section, gcl::NestedConnection<gcl::Paragraph, gcl::NestedConnection<gcl::Line, void> > > >(boost::archive::binary_oarchive&, gcl::NestedConnection<gcl::Section, gcl::NestedConnection<gcl::Paragraph, gcl::NestedConnection<gcl::Line, void> > >&)() 
#11 0x082d0472 in void boost::archive::detail::save_pointer_type<boost::archive::binary_oarchive>::save<gcl::NestedConnection<gcl::Section, gcl::NestedConnection<gcl::Paragraph, gcl::NestedConnection<gcl::Line, void> > > >(boost::archive::binary_oarchive&, gcl::NestedConnection<gcl::Section, gcl::NestedConnection<gcl::Paragraph, gcl::NestedConnection<gcl::Line, void> > > const&)() 

....... 

#172 0x082a91d8 in boost::archive::detail::interface_oarchive<boost::archive::binary_oarchive>::operator<< <gcl::Collation const> (this=0xbfffe500, t=...) at /usr/include/boost/archive/detail/interface_oarchive.hpp:64 
#173 0x082a6298 in boost::archive::detail::interface_oarchive<boost::archive::binary_oarchive>::operator&<gcl::Collation> (this=0xbfffe500, t=...) at /usr/include/boost/archive/detail/interface_oarchive.hpp:72 
#174 0x0829bd63 in main (argc=4, argv=0xbffff3f4) at /home/neel/projects/app/main.cpp:93

程序正常工作。
使用Linux 64bit與32位PAE內核提升1.42
程序運行時沒有崩潰幾次修訂前。我最近增加了一些字節到結構中。可能那時它並沒有達到RAM的末端，現在達到了。

但爲什麼新的故障時，有足夠的交換？爲什麼序列化過程需要這麼多的RAM？

來源

2012-09-01 Neel Basu

174條線不太長（雖然實際上跟蹤可能不是很有趣）。然而，沒有數據結構（最好是實際代碼）的意義，我們可以看到的並不多，我猜... – sehe

我實際上做的是在結構中解析幾個文本文件，然後在它們之間進行N：N比較。並獲得連接對象。我正在序列化兩者。而且它並不是單一的一行程序。應用程序非常龐大，無法在此處粘貼代碼。 –

您是否嘗試過其他存檔類型，即文本或XML？ – doublep

我意識到，序列化進程正在採取額外的內存，爲自己的看家作品。這是打3GB Barrier要停止序列化過程佔用額外的內存我禁用對象跟蹤BOOST_CLASS_TRACKING和固定額外的內存開銷。

來源

2013-05-11 15:52:07

問：爲什麼會崩潰，而分配內存時的交換是空的？

分配的對象是太大，不適合任何地方virtual address space：

分配的對象是堆積如山的
virtual address space過於分散
virtual address space被全部分配

如果您的應用程序被編譯爲32位，進程virtual address space僅限於4Gb。

問：爲什麼會序列化過程中承擔這麼大的內存？

我還沒有發現任何證據表明這是爲什麼。

來源

2012-09-02 04:43:48 DoogQc

boost序列化binary_oarchive崩潰

回答

相關問題