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

Putting a lock on IDatabaseAdapter.GetAdapter() did not help. Locking
Instance::GetEntry fixed it, but this ofcourse defies the purpose of
multi-threading.

I have tried using normal pointers instead, and although a lot more
rare, it still segfaults occasionally.

I am currently following a lead from valgrind, but I'm not going to
hold my breath just yet.

==4101== Invalid read of size 8
==4101== at 0x541EC58: (within
/u01/app/oracle/product/localhost/db_1/lib/libnnz10.so)
==4101== Address 0x4372BC8 is 128 bytes inside a block of size 133
alloc'd
==4101== at 0x401CC6B: operator new[](unsigned)
(vg_replace_malloc.c:197)
==4101== by 0x440672D: SAString::AllocBuffer(int) (SQLAPI.cpp:282)
==4101== by 0x4407106: SAString::SAString(char const*)
(SQLAPI.cpp:603)
==4101== by 0x43E9899: SqlApiDatabaseAdapter::Execute(std::string
const&) (SqlApiDatabaseAdapter.cc:67)
==4101== by 0x4404A4D: OracleDatabaseAdapter::GetFieldInfo()
(OracleDatabaseAdapter.cc:35)
==4101== by 0x43F3BE7: Instance::GetFields(std::string const&,
ARFieldMappingList*, ARFieldLimitList*, ARUnsignedIntList*)
(Instance.cc:211)
==4101== by 0x43E3FE8: ARDBCGetMultipleFields (syscomardbc.cc:622)
==4101== by 0x804D802: ardbctest::testGetFields(ARCompoundSchema&)
(ardbctest.h:303)
==4101== by 0x804DFDE: ardbctest::testGetSchemasAndFields()
(ardbctest.h:280)
==4101== by 0x804E162: ardbctest::run() (ardbctest.h:179)
==4101== by 0x8049CAA: run() (main.cc:47)
==4101== by 0x8049EBB: main (main.cc:68)

NOTE: SQLAPI is a third-party library between my app and oracle (and
other db apis).


On Dec 6, 11:04 am, "phear" <phear.d...@xxxxxxxxx> wrote:
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.

.