[Boost-users] shared_ptr segfaults on 64bit AMD

From: Paul Davis (pjdavis_at_[hidden])
Date: 2006-08-26 18:27:00

Howdy,

I've come across an odd segfault that originates in some of the boost 
code. (By originate, meaning thats where the stack trace points, I'm not 
sure if its me or boost thats wrong)

Anyway, the weird part is that its only on my 64 bit machine.

I took a look at where its segfaulting in 
boost::detail::atomic_exchange_and_add(). Its scary inline assembly 
stuff.  Well, mostly I just don't know assembly so I haven't the 
slightest idea if its right or wrong.  And obviously, its a platform 
specific header and what not so I imagine its limited to this area.  I 
have had other weird segfaults that come and go from the atomic_* set of 
methods.  I can't pin down exactly whats causing it.  They mostly seem 
to be coming from storing shared_ptr's in STL containers.  I've never 
had any problems with it before so I'm assuming its just a relatively 
untested section of code.

And if its relevant, I also tried downloading CVS and running the 
shared_ptr_test. It ran without segfaulting just fine.

Some relevant info:

Segfaults on:
2.6.15-25-amd64-generic #1 SMP PREEMPT Wed Jun 14 11:28:03 UTC 2006 
x86_64 GNU/Linux
g++ (GCC) 4.0.3 (Ubuntu 4.0.3-1ubuntu5)
boost/version.hpp #define BOOST_VERSION 103301

Does NOT segfault on:
2.6.15-1.1831_FC4smp #1 SMP Tue Feb 7 13:48:31 EST 2006 i686 i686 i386 
GNU/Linux
g++ (GCC) 4.0.2 20051125 (Red Hat 4.0.2-8)
boost/version.hpp : #define BOOST_VERSION 103200

Stack trace:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 46912529528592 (LWP 27560)]
0x000000000040a2f8 in boost::detail::atomic_exchange_and_add (pw=0x98, 
dv=-1) at sp_counted_base_gcc_x86.hpp:50
50          );
(gdb) bt
#0  0x000000000040a2f8 in boost::detail::atomic_exchange_and_add 
(pw=0x98, dv=-1) at sp_counted_base_gcc_x86.hpp:50
#1  0x000000000040a46c in boost::detail::sp_counted_base::release 
(this=0x90) at sp_counted_base_gcc_x86.hpp:143
#2  0x000000000040a4d0 in ~shared_count (this=0x2514218) at 
shared_count.hpp:159
#3  0x00002aaaaccb849b in ~shared_ptr (this=0x2514210) at shared_ptr.hpp:106
#4  0x00002aaaaccb88e1 in 
__gnu_cxx::new_allocator<boost::shared_ptr<min_heap> >::destroy 
(this=0x7fffffc2b410, __p=0x2514210)
    at new_allocator.h:107
#5  0x00002aaaaccb9f66 in std::vector<boost::shared_ptr<min_heap>, 
std::allocator<boost::shared_ptr<min_heap> > >::erase (
    this=0x7fffffc2b410, __position={_M_current = 0x2514220}) at 
vector.tcc:115
#6  0x00002aaaaccb7add in label_map::CloseToAlive (this=0x7fffffc2b3e0, 
p=@0x7fffffc2b1a0) at build/Modules/Marching/label_map.cc:273
#7  0x00002aaaaccb326f in fast_march::march (this=0x7fffffc2b3c0, 
mask=@0x527d30, gradient=@0x527d10, labeled=@0x527d40)
    at build/Modules/Marching/fast_march.cc:76
#8  0x00002aaaaccbec64 in marching::run (this=0x527c50, 
cli=@0x7fffffc2b5e0, options=@0x7fffffc2b5d0, args=@0x7fffffc2b5c0)
    at build/Modules/Marching/marching.cc:110
#9  0x00000000004074bd in process (args=@0x7fffffc2c460) at 
build/DDS/dds.cc:259
#10 0x0000000000408ffd in main (argc=2, argv=0x7fffffc2c5a8) at 
build/DDS/dds.cc:531

Paul Davis