Crash on recovery attempt in HamsterDB 2.1.6

41 views
Skip to first unread message

Julian Graham

unread,
Mar 22, 2014, 4:52:45 PM3/22/14
to hamster...@googlegroups.com
Hi Christoph et al.,

I'm testing an integration between my application and the HamsterDB C API (2.1.6), and I'm seeing some puzzling behavior. When I do the following things...

1. Create a new environment and local database with the `HAM_ENABLE_TRANSACTIONS' flag set
2. Begin a transaction
3. Insert multiple keys with `ham_db_insert'
4. Commit the transaction
5. Exit without cleaning up the environment (e.g., via `SIGKILL')

...I wind up with an un-openable environment. That is to say, if I later attempt to open the environment via `ham_env_open' (and `HAM_ENABLE_TRANSACTIONS', I get `HAM_NEEDS_RECOVERY'. If I add the `HAM_AUTO_RECOVERY' flag, my process crashes with:

  ASSERT FAILED in file blob_manager_disk.cc, line 357:
  "old_blob_header.get_self() == old_blobid"

  Aborted (core dumped)

What am I doing wrong? It might be worth noting that this only happens when multiple keys are inserted as part of the transaction described above. I've attached a small C program that captures my use case and can be used to reproduce the behavior I'm seeing. (Run "a.out -i" followed by "a.out -r".)


Thanks,
Julian

test.c

Christoph Rupp

unread,
Mar 23, 2014, 3:53:27 AM3/23/14
to hamster...@googlegroups.com
Hi Julian,

thanks for the code. I think i know what's going on. 2.1.6 (and older versions) try to log as little as possible to reduce I/O, and it seems they were too aggressive and ignored  I'm going to look into it and send you a message till today evening (CET).

Best regards
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.

Christoph Rupp

unread,
Mar 23, 2014, 10:51:11 AM3/23/14
to hamster...@googlegroups.com
Hi Julian,

the bug was already fixed - you can pull the sources from github. The branch is "topic/next":
https://github.com/cruppstahl/hamsterdb/tree/topic/next

2.1.6 and older versions did log as little as possible in order to save I/O. 2.1.7 is logging more pessimistically. (It has other logging optimizations, and logging should be equally fast if not faster than in 2.1.6.)

Shame on me that i did not realize that this issue was so critical. I'm going to release a new version in a few days. "topic/next" is an unstable branch, but things should work well enough for integration testing.

Also, i'll create a unittest from your sample.

Best regards
Christoph

Julian Graham

unread,
Mar 23, 2014, 2:43:05 PM3/23/14
to hamster...@googlegroups.com
Hi Christoph,

Thanks for the quick response! 


On Sunday, March 23, 2014 10:51:11 AM UTC-4, Christoph Rupp wrote:
the bug was already fixed - you can pull the sources from github. The branch is "topic/next":
https://github.com/cruppstahl/hamsterdb/tree/topic/next
 
I've done some light testing with the code on "topic/next," and my application is working much better. I eagerly await the release of 2.1.7.  :)


Regards,
Julian
Reply all
Reply to author
Forward
0 new messages