Re: gdb help: debugging a segfault in boost::shared_ptr

What exactly do you mean? I do own both source and target pointers, and
DatabaseAdapterPool::GetAdapter() is protected by a mutex.
IDatabaseAdapter.GetAdapter() is not though. I will try locking this as
well.

I might also try rewriting the code to use normal pointers instead,
just to see what happens then. I am afraid this will just hide the bug
though.

On Dec 6, 3:24 am, Joe Seigh <jseigh...@xxxxxxxxxx> wrote:
phear.d...@xxxxxxxxx wrote:
I am working on a multithreaded application that contains a database
connection pool which is using shared_ptr to pass connections around.

After recent changes I've been getting random segfaults in the
shared_ptr code handling ref counting. The gdb session below help
explain the context.

I acknowledge that this is most likely my own screwup, but since I am
unable to get much meaningful information from gdb, I'm starting to run
out of ideas.

The following is what I have discovered by research:
- shared_ptr is thread safe (from boost docs)
- sp_counted_base uses lock-free algorithms for refcounting (from
header)

The questions I currently have are:
- How can I get more details about the segfault? Ie. Which instruction
or memory address is involved?
- Why can't I access *pw?
- How can atomic_increment segfault? Is it possible that gdb's stack
trace is wrong?

An answer to any of these questions would be greatly appreciated.In this case lock-free doesn't mean what you think it means. shared_ptr's
are only safe to copy if you own the source ptr (and the target ptr obviously).
There are experimental smart pointers that are atomically thread-safe.
shared_ptr isn't one of them as you found out. You'll need a mutex
to safely pass those shared_ptr's around.

--
Joe Seigh

When you get lemons, you make lemonade.
When you get hardware, you make software.

.

Relevant Pages

  • Re: Question about STL containers in multithreaded environment
    ... you never use by value,NEVER,only pointers or shared ... inserts in the vector would invalidate at least the end ... Updates don't do anything ... the container and a mutex per object or a mutex for each n objects (a ...
    (comp.programming.threads)
  • Re: Getting a ThreadList without locking (TIdTCPServer)
    ... mutex) can I call a lock to a select number of the threads only? ... I can maintain my own TList of pointers for reference, ... >> active on TIdTCPServer without actually calling the mutex and locking ...
    (borland.public.delphi.language.objectpascal)
  • Re: Is this kosher...
    ... The static initializer macro can only legally be used for statically allocated storage. ... what I don't see pointed out is that COPYING a mutex is always illegal. ... a pthread_mutex_t may contain pointers to other storage; and that storage might even have links back to the pthread_mutex_t. ...
    (comp.programming.threads)
  • Re: Emulating PTHREAD_MUTEX_RECURSIVE - recursive mutex implementation...
    ... ten new threads can read the value with no synchronization. ... Similarly, if a thread sets a value while a mutex is held, any ... Any pointers, or am ...
    (comp.programming.threads)