dumb question on a trap inside hamsterdb

[Joel Jacobson]

im sure that im doing something wrong, but could use a little help figuring out how to track it down.  specifically, im seeing a segfault in ham_txn_commit():

==1569== Process terminating with default action of signal 11 (SIGSEGV): dumping core

==1569==  Access not within mapped region at address 0x8

==1569==    at 0x4CCCC76: hamsterdb::BtreeIndexTraitsImpl<hamsterdb::PaxNodeImpl<hamsterdb::PaxLayout::BinaryKeyList, hamsterdb::PaxLayout::DefaultRecordList>, hamsterdb::FixedSizeCompare>::compare_keys(hamsterdb::LocalDatabase*, ham_key_t*, ham_key_t*) const (btree_node_proxy.h:305)

==1569==    by 0x4D222A3: hamsterdb::TransactionIndex::remove(hamsterdb::TransactionNode*) (txn_local.cc:57)

==1569==    by 0x4D22AC2: hamsterdb::TransactionOperation::destroy() (txn_local.cc:102)

==1569==    by 0x4D22B73: hamsterdb::LocalTransaction::free_operations() (txn_factory.h:57)

==1569==    by 0x4D22C0B: hamsterdb::LocalTransaction::~LocalTransaction() (txn_local.cc:242)

==1569==    by 0x4D22CE8: hamsterdb::LocalTransaction::~LocalTransaction() (txn_local.cc:243)

==1569==    by 0x4D23295: hamsterdb::LocalTransactionManager::flush_committed_txns() (txn_local.cc:590)

==1569==    by 0x4D26E56: ham_txn_commit (hamsterdb.cc:140)

its not the first transaction i commit, its probably somewhere around the 10-20th.  i've tried turning on HAM_ENABLE_FSYNC to see if that makes it happen on the first txn commit, and it seems to make no difference.

if anyone has some suggestions on what i might investigate, i am all ears.  thanks in advance...

- j

[Christoph Rupp]

Hi Joel,

is it possible that you commit the same transaction twice, i.e. call ham_txn_commit with the same "txn" parameter several times?

Bye
Christoph

--
You received this message because you are subscribed to the Google Groups "hamsterdb User" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hamsterdb-use...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Joel Jacobson]

strategically located printfs say "txn was created and committed 1 time", and im crashing on that 1 commit.

- j

[Christoph Rupp]

Can you send a reproducible sample? Then I will have a look.

Best regards
Christoph

[Joel Jacobson]

i'll see what i can do to trim it into something generic enough.

- j

[Joel Jacobson]

ok, i have a c++ source file i can send, but its a little under 512k.  would you like me to send it to the list, stick it on pastebin, or do you have some other preferred mode?

rough summary: there are 35 txns, totaling 136 inserts and 23 deletes (some of the records contain up to 8k of data, which is why the file is so big).

- j

[Christoph Rupp]

You can send it to my email address (ch...@crupp.de).

Thanks
Christoph

[Christoph Rupp]

OK, I fixed the bug.

I use a red-black tree from the freebsd project to manage the transactions. When a transaction is flushed, its node in the rb-tree is removed. In your test case it seems there was a bug in the rb-tree and the tree was not properly rebalanced when a specific node was removed. This caused the segmentation fault.

I have pushed a fix to the master branch: https://github.com/cruppstahl/hamsterdb. I have added a unittest based on your test case.

Thanks again for your help tracking this down!
Christoph

[Joel Jacobson]

ok, so all this time i assumed i was doing something wrong.  i guess its comforting to know im not as dumb as i thought.  if i find anything else, i'll let you know (i exercise the KV backend pretty heavily).

thanks for the quick turnaround on the fix.

- j