I haven't tried this yet on Linux but so far on Gcc for Wndows my test application segfaults on an allocation routine. Here is the backtrace: #0 0x00415ace in boost::simple_segregated_storage<unsigned int>::try_malloc_n (start=@0x22fc00, n=16, partition_size=4) at simple_segregated_storage.hpp:234 #1 0x00415bc7 in boost::simple_segregated_storage<unsigned int>::malloc_n (this=0x463010, n=17, partition_size=4) at simple_segregated_storage.hpp:256 #2 0x0041c7f2 in boost::pool<boost::default_user_allocator_new_delete>::ordered_malloc (this=0x463010, n=68) at pool.hpp:511 #3 0x0041fb25 in boost::detail::sh::pool::allocate (this=0x463010, s=68) at sh_owned_base_nt.hpp:103 #4 0x00426669 in boost::detail::sh::shifted<std::_List_node<boost::detail::sh::shifted_ptr<vector>, boost::detail::sh::shifted_allocator<boost::detail::sh::shifted_ptr<vector>
::operator new (s=68) at sh_owned_base_nt.hpp:213 #5 0x0041f420 in boost::detail::sh::shifted_allocator<std::_List_node<boost::detail::sh::shifted_ptr<vector>, boost::detail::sh::shifted_allocator<boost::detail::sh::shifted_ptr<vector> ::allocate (this=0x3e5094, s=1) at shifted_allocator.hpp:83 #6 0x0044aa5d in std::_List_base<boost::detail::sh::shifted_ptr<vector>, boost::detail::sh::shifted_allocator<boost::detail::sh::shifted_ptr<vector> ::_M_get_node (this=0x3e5094) at stl_list.h:333 #7 0x00453ff2 in std::list<boost::detail::sh::shifted_ptr<vector>, boost::detail::sh::shifted_allocator<boost::detail::sh::shifted_ptr<vector> ::_M_create_node (this=0x3e5094, __x=@0x22ff50) at stl_list.h:457 #8 0x0045414c in std::list<boost::detail::sh::shifted_ptr<vector>, boost::detail::sh::shifted_allocator<boost::detail::sh::shifted_ptr<vector> ::_M_insert (this=0x3e5094, __position={_M_node = 0x3e50c8}, __x=@0x22ff50) at stl_list.h:1185 #9 0x0045418d in std::list<boost::detail::sh::shifted_ptr<vector>, boost::detail::sh::shifted_allocator<boost::detail::sh::shifted_ptr<vector> ::push_back (this=0x3e5094, __x=@0x22ff50) at stl_list.h:807 #10 0x00401708 in main () at shifted_ptr_test2.cpp:102
-Phil
From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Phil Bouchard Sent: Monday, September 29, 2008 5:56 AM
I haven't tried this yet on Linux but so far on Gcc for Wndows my test application segfaults on an allocation routine. Here is the backtrace:
#0 0x00415ace in boost::simple_segregated_storage<unsigned int>::try_malloc_n (start=@0x22fc00, n=16, partition_size=4) at simple_segregated_storage.hpp:234
#10 0x00401708 in main () at shifted_ptr_test2.cpp:102
Phil-- I created a ticket based on your previous report of this problem; see http://svn.boost.org/trac/boost/ticket/2360 . So far, however, I have been unable to reproduce the problem with the version of shifted_ptr_test2 in boost/sandbox. Any additional information you can provide would be appreciated. Your test case also revealed a crash on exit related to a problem with static initialization ordering in Boost.Pool. I'm currently testing a fix for that problem; see http://svn.boost.org/trac/boost/ticket/2359 -Chris
"Chris Newbold" <Chris.Newbold@mathworks.com> wrote in message news:6F6A2FC198A0F943ACC2259C38A2E30B6B6FB4BD89@EXCHANGE-AH.ad.mathworks.com... [...]
Phil--
I created a ticket based on your previous report of this problem; see http://svn.boost.org/trac/boost/ticket/2360 . So far, however, I have been unable to reproduce the problem with the version of shifted_ptr_test2 in boost/sandbox. Any additional information you can provide would be appreciated.
Your test case also revealed a crash on exit related to a problem with static initialization ordering in Boost.Pool. I'm currently testing a fix for that problem; see http://svn.boost.org/trac/boost/ticket/2359
I just tried the same problem today on Linux but using the latest Boost 1.36 and I had the exact same crash. So I decided rounding the allocated chunk size up to sizeof(int) instead of sizeof(char), I ran the test again and I end up with a different crash. Here is the new backtrace: #0 0x0042e77d in boost::details::PODptr<unsigned int>::next (this=0x22fdb8) at pool.hpp:121 #1 0x0042e1c1 in boost::pool<boost::default_user_allocator_new_delete>::find_POD (this=0x463010, chunk=0x3e4808) at pool.hpp:576 #2 0x0042e138 in boost::pool<boost::default_user_allocator_new_delete>::is_from (this=0x463010, chunk=0x3e4808) at pool.hpp:276 #3 0x0041d575 in boost::detail::sh::shifted_ptr<node>::operator=<node> (this=0x22ff58, p=0x3e5028) at shifted_ptr.hpp:217 #4 0x0041190e in list::insert (this=0x22ff50) at shifted_ptr_test2.cpp:49 #5 0x00401492 in main () at shifted_ptr_test2.cpp:85 I simply added & used "detail::sh::pool::chunk_size_" of file "boost/detail/sh_owned_base_nt.hpp". -Phil
From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Phil Bouchard Sent: Tuesday, September 30, 2008 4:04 AM
I just tried the same problem today on Linux but using the latest Boost 1.36 and I had the exact same crash.
Hmm. What version of GCC are you using? One thing I found is that your shifted_ptr_test2 would not compile with the version of GCC I'm using (4.1.2) unless I moved the patches to list.tcc and stl_list.h out of the way. Are those patches "required"? -Chris
"Chris Newbold" <Chris.Newbold@mathworks.com> wrote in message news:6F6A2FC198A0F943ACC2259C38A2E30B6B6FB4BD92@EXCHANGE-AH.ad.mathworks.com...
From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Phil Bouchard Sent: Tuesday, September 30, 2008 4:04 AM
I just tried the same problem today on Linux but using the latest Boost 1.36 and I had the exact same crash.
Hmm. What version of GCC are you using?
One thing I found is that your shifted_ptr_test2 would not compile with the version of GCC I'm using (4.1.2) unless I moved the patches to list.tcc and stl_list.h out of the way.
Are those patches "required"?
I'm using version 3.4.5. The patches are required to make the pool crash, yes. All allocations end up using order_malloc() so this function causes problems. I will try out GCC 4... -Phil
"Chris Newbold" <Chris.Newbold@mathworks.com> wrote in message news:6F6A2FC198A0F943ACC2259C38A2E30B6B6FB4BD92@EXCHANGE-AH.ad.mathworks.com...
From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Phil Bouchard Sent: Tuesday, September 30, 2008 4:04 AM
I just tried the same problem today on Linux but using the latest Boost 1.36 and I had the exact same crash.
Hmm. What version of GCC are you using?
One thing I found is that your shifted_ptr_test2 would not compile with the version of GCC I'm using (4.1.2) unless I moved the patches to list.tcc and stl_list.h out of the way.
Are those patches "required"?
I have compiled the application using GCC 4.3.0 with Boost 1.35 and I got a similar crash: #0 0x0041ca66 in boost::simple_segregated_storage<unsigned int>::try_malloc_n (start=@0x22fd9c, n=15, partition_size=4) at simple_segregated_storage.hpp:234 #1 0x0041cb58 in boost::simple_segregated_storage<unsigned int>::malloc_n (this=0x48d030, n=16, partition_size=4) at simple_segregated_storage.hpp:256 #2 0x00420a4d in boost::pool<boost::default_user_allocator_new_delete>::ordered_malloc (this=0x48d030, n=16) at pool.hpp:511 #3 0x004238ce in boost::detail::sh::pool::allocate (this=0x48d030, s=60) at sh_owned_base_nt.hpp:105 #4 0x00423d92 in boost::detail::sh::shifted<node>::operator new (s=60) at sh_owned_base_nt.hpp:215 #5 0x004192ff in list::insert (this=0x22ff34) at shifted_ptr_test2.cpp:49 #6 0x0040154b in main () at shifted_ptr_test2.cpp:85 -Phil
From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Phil Bouchard Sent: Wednesday, October 01, 2008 2:53 AM
I have compiled the application using GCC 4.3.0 with Boost 1.35 and I got a similar crash:
With your latest updates to the shifted_ptr code I've been able to compile w/ GCC 4.1.2 and reproduce a crash; it looks a little different than the one you posted, but at least now I've got something to dig into. Stay tuned. #0 0x000000000040378a in boost::details::PODptr<unsigned long>::next (this=0x7fff6e0ff760) at /mathworks/devel/sandbox/cnewbold/boost-trunk/boost/pool/pool.hpp:121 #1 0x0000000000404194 in boost::pool<boost::default_user_allocator_new_delete>::find_POD (this=0x52fe60, chunk=0x531470) at /mathworks/devel/sandbox/cnewbold/boost-trunk/boost/pool/pool.hpp:576 #2 0x00000000004041f5 in boost::pool<boost::default_user_allocator_new_delete>::is_from (this=0x52fe60, chunk=0x531470) at /mathworks/devel/sandbox/cnewbold/boost-trunk/boost/pool/pool.hpp:276 #3 0x000000000040ee85 in boost::detail::sh::shifted_ptr<node>::operator=<node> (this=0x7fff6e0ff8b0, p=0x533490) at ../../../boost/shifted_ptr.hpp:217 #4 0x00000000004108fc in list::insert (this=0x7fff6e0ff8a0) at shifted_ptr_test2.cpp:49 #5 0x00000000004017c0 in main () at shifted_ptr_test2.cpp:85 -Chris
From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Chris Newbold Sent: Wednesday, October 01, 2008 7:58 AM
With your latest updates to the shifted_ptr code I've been able to compile w/ GCC 4.1.2 and reproduce a crash; it looks a little different than the one you posted, but at least now I've got something to dig into. Stay tuned.
Phil-- I believe that this crash is actually a bug in your code. In boost::detail::sh::pool::allocate you are dividing the specified size by the pool's chunk size. However, in deallocate, you are just passing the size directly to the underlying pool. The result is that you are trying to free twice as many chunks as you allocated. Take a look and let me know what you think. -Chris
"Chris Newbold" <Chris.Newbold@mathworks.com> wrote in message news:6F6A2FC198A0F943ACC2259C38A2E30B6B6FB4BD9E@EXCHANGE-AH.ad.mathworks.com...
From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Chris Newbold Sent: Wednesday, October 01, 2008 7:58 AM
With your latest updates to the shifted_ptr code I've been able to compile w/ GCC 4.1.2 and reproduce a crash; it looks a little different than the one you posted, but at least now I've got something to dig into. Stay tuned.
Phil--
I believe that this crash is actually a bug in your code. In boost::detail::sh::pool::allocate you are dividing the specified size by the pool's chunk size. However, in deallocate, you are just passing the size directly to the underlying pool. The result is that you are trying to free twice as many chunks as you allocated.
Take a look and let me know what you think.
My mistake. I forgot taking the chunk_size_ away and relying on array of chars. Now here is the crash I got: #0 0x0041ca66 in boost::simple_segregated_storage<unsigned int>::try_malloc_n (start=@0x22fcdc, n=16, partition_size=4) at simple_segregated_storage.hpp:234 #1 0x0041cb58 in boost::simple_segregated_storage<unsigned int>::malloc_n (this=0x48d030, n=17, partition_size=4) at simple_segregated_storage.hpp:256 #2 0x00420a4d in boost::pool<boost::default_user_allocator_new_delete>::ordered_malloc (this=0x48d030, n=68) at pool.hpp:511 #3 0x004238c9 in boost::detail::sh::pool::allocate (this=0x48d030, s=68) at sh_owned_base_nt.hpp:103 #4 0x0042a3fa in boost::detail::sh::shifted<std::_List_node<boost::detail::sh::shifted_ptr<vector>, boost::detail::sh::shifted_allocator<boost::detail::sh::shifted_ptr<vector>
::operator new (s=68) at sh_owned_base_nt.hpp:213 #5 0x00423202 in boost::detail::sh::shifted_allocator<std::_List_node<boost::detail::sh::shifted_ptr<vector>, boost::detail::sh::shifted_allocator<boost::detail::sh::shifted_ptr<vector> ::allocate (this=0x3e2d6c, s=1) at shifted_allocator.hpp:83 #6 0x00452436 in std::_List_base<boost::detail::sh::shifted_ptr<vector>, boost::detail::sh::shifted_allocator<boost::detail::sh::shifted_ptr<vector> ::_M_get_node (this=0x3e2d6c) at stl_list.h:333 #7 0x00463124 in std::list<boost::detail::sh::shifted_ptr<vector>, boost::detail::sh::shifted_allocator<boost::detail::sh::shifted_ptr<vector> ::_M_create_node (this=0x3e2d6c, __x=@0x22ff24) at stl_list.h:457 #8 0x004631e0 in std::list<boost::detail::sh::shifted_ptr<vector>, boost::detail::sh::shifted_allocator<boost::detail::sh::shifted_ptr<vector> ::_M_insert (this=0x3e2d6c, __position={_M_node = 0x3e2da0}, __x=@0x22ff24) at stl_list.h:1187 #9 0x00463218 in std::list<boost::detail::sh::shifted_ptr<vector>, boost::detail::sh::shifted_allocator<boost::detail::sh::shifted_ptr<vector> ::push_back (this=0x3e2d6c, __x=@0x22ff24) at stl_list.h:808 #10 0x004016e6 in main () at shifted_ptr_test2.cpp:102
-Phil
From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Phil Bouchard Sent: Wednesday, October 01, 2008 12:06 PM
My mistake. I forgot taking the chunk_size_ away and relying on array of chars. Now here is the crash I got:
I've reproduced and debugged this crash and I think this one it another bug in the shifted_ptr code, though I have not yet been able to pin it down. Something is corrupting the free list in the unallocated chunks held by the pool. It's very deterministic, so I managed to set a watchpoint on the chunk that gets clobbered; here's what I see: Hardware watchpoint 2: *137317164 Old value = 137317168 New value = 137317167 0x080498c5 in boost::detail::sp_counted_base::release (this=0x82f4b28) at /usr/include/boost/detail/sp_counted_base_nt.hpp:77 77 if( --use_count_ == 0 ) (gdb) where #0 0x080498c5 in boost::detail::sp_counted_base::release (this=0x82f4b28) at /usr/include/boost/detail/sp_counted_base_nt.hpp:77 #1 0x0804bf60 in ~shifted_ptr_base (this=0x82eceb0) at ../../../boost/detail/shifted_ptr_base.hpp:64 #2 0x08055f64 in ~shifted_ptr (this=0x82eceb0) at ../../../boost/shifted_ptr.hpp:255 #3 0x08055ff8 in ~_List_node_base (this=0x82ecea8) at ../../../bits/stl_list.h:76 #4 0x080569f5 in ~_List_node (this=0x82ecea8) at ../../../bits/stl_list.h:108 #5 0x08056a50 in ~shifted (this=0x82ece7c) at ../../../boost/detail/sh_owned_base_nt.hpp:197 #6 0x08049862 in boost::detail::sp_counted_base::destroy (this=0x82ece7c) at /usr/include/boost/detail/sp_counted_base_nt.hpp:58 #7 0x080498ae in boost::detail::sp_counted_base::weak_release (this=0x82ece7c) at /usr/include/boost/detail/sp_counted_base_nt.hpp:93 #8 0x080498f1 in boost::detail::sp_counted_base::release (this=0x82ece7c) at /usr/include/boost/detail/sp_counted_base_nt.hpp:80 #9 0x0804b9ca in ~shifted_ptr_base (this=0x82ece74) at ../../../boost/detail/shifted_ptr_base.hpp:64 #10 0x080565ce in ~shifted_ptr (this=0x82ece74) at ../../../boost/shifted_ptr.hpp:255 #11 0x08056611 in ~_List_impl (this=0x82ece74) at ../../../bits/stl_list.h:318 #12 0x0805670e in ~_List_base (this=0x82ece74) at ../../../bits/stl_list.h:352 #13 0x0805674f in ~list (this=0x82ece74) at ../../../bits/stl_list.h:412 #14 0x08056770 in ~vector (this=0x82ece74) at shifted_ptr_test2.cpp:66 #15 0x0805679c in ~shifted (this=0x82ece48) at ../../../boost/detail/sh_owned_base_nt.hpp:197 #16 0x0805571f in boost::detail::sh::set::release (this=0x82ec228) at ../../../boost/shifted_ptr.hpp:86 #17 0x080568af in boost::detail::sh::shifted_ptr<vector>::release (this=0xbfb9389c, d=true) at ../../../boost/shifted_ptr.hpp:263 #18 0x0805698d in ~shifted_ptr (this=0xbfb9389c) at ../../../boost/shifted_ptr.hpp:255 #19 0x080492b8 in main () at shifted_ptr_test2.cpp:95 (gdb) print sizeof(*this) $3 = 12 (gdb) print *this $4 = {_vptr.sp_counted_base = 0x82f4b2c, use_count_ = 137317167, weak_count_ = 137317172} (gdb) print this $5 = (class boost::detail::sp_counted_base * const) 0x82f4b28 The sp_counted_base at 0x82f4b28 at frame #0 is completely bogus. Some further instrumentation of the pool reveals that the address 0x82f4b28 is owned by the pool, but has never been handed out to the application. -Chris
"Chris Newbold" <Chris.Newbold@mathworks.com> wrote in message news:6F6A2FC198A0F943ACC2259C38A2E30B6B6FB4BDA5@EXCHANGE-AH.ad.mathworks.com... [...]
The sp_counted_base at 0x82f4b28 at frame #0 is completely bogus. Some further instrumentation of the pool reveals that the address 0x82f4b28 is owned by the pool, but has never been handed out to the application.
I will verify this but what I personaly get is a ordered_malloc() failure on the 2005th attempt. 3 blocks of memory get allocated / deallocated over and over until the allocation routine fails. -Phil
From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Phil Bouchard Sent: Thursday, October 02, 2008 12:34 PM
I will verify this but what I personaly get is a ordered_malloc() failure on the 2005th attempt. 3 blocks of memory get allocated / deallocated over and over until the allocation routine fails.
If unchecked, it eventually crashes for me inside of simple_segregated_storage::try_malloc_n(), which I believe is what you're seeing. The stack trace I quoted in my previous e-mail is the trace of the errant write that corrupts the pool. -Chris
"Chris Newbold" <Chris.Newbold@mathworks.com> wrote in message news:6F6A2FC198A0F943ACC2259C38A2E30B6B6FB4BDB1@EXCHANGE-AH.ad.mathworks.com...
From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org]
[...]
If unchecked, it eventually crashes for me inside of simple_segregated_storage::try_malloc_n(), which I believe is what you're seeing.
The stack trace I quoted in my previous e-mail is the trace of the errant write that corrupts the pool.
I had a chance to run some tests quickly this morning; it turns out all deallocations with corresponding size are valid. -Phil
"Phil Bouchard" <philippe@fornux.com> wrote in message news:gc6kaq$qep$1@ger.gmane.org... [...]
I had a chance to run some tests quickly this morning; it turns out all deallocations with corresponding size are valid.
I meant: all pointers passed to the pool::free() function are valid. -Phil
participants (2)
-
Chris Newbold -
Phil Bouchard