-
Notifications
You must be signed in to change notification settings - Fork 7.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
reappearing "ghost" key after 17 steps #50
Comments
Comment #1 originally posted by sanjay.ghemawat on 2011-10-03T18:30:02.000Z: Do you have a C++ program that demonstrates the bug? PS. Your erlang test ends with: I tried emulating your program as a new test case in TEST(DBTest, ReopenMultipleTimes) { |
Comment #2 originally posted by josephwnorton on 2011-10-03T23:14:21.000Z: Yes, I used key1 to make the test pass. I created a C++ program by hand to repeat the issue but unfortunately I was unable to repeat the problem. I need to spend more time to see how I can repeat the issue using only the c and/or c++ leveldb API. Is there any debug or verbose mode that I can enable to trace the low level behavior of leveldb? |
Comment #3 originally posted by josephwnorton on 2011-10-26T15:02:42.000Z: As a follow-up, the test used to find this bug has been uploaded to GitHub. There is also a simpler version that can repeat the behavior using leveldb's c bindings. https://github.com/norton/lets/blob/master/test/qc/qc_statem_lets.erl |
Comment #4 originally posted by josephwnorton on 2011-10-26T15:39:04.000Z: The problem hasn't been fixed. I'm testing against the following version of leveldb. It is dated Oct 5 and not Oct 15. I was (mistakenly) waiting for the next release. https://github.com/norton/leveldb/commits/master commit 299cced |
Comment #5 originally posted by josephwnorton on 2011-10-29T12:02:28.000Z: Sanjay - I constructed a failing C test case to mimic the original QuickCheck Erlang counterexample. Please see the Makefile for details on how to build and to run. https://github.com/norton/lets/blob/leveldb-issue44/priv/test/qc_leveldb_issue44.c [(leveldb-issue44)]$ pwd [(leveldb-issue44)]$ make clean all; ./qc_leveldb_issue44 !!! NO - reappearing ghost key 'g' !!! KEY POINT => sleep for background compaction to finish it's work !!! YES - reappearing ghost key 'g' !!! qc_leveldb_issue44: qc_leveldb_issue44.c:115: main: Assertion `buglen == nillen' failed. |
Comment #6 originally posted by josephwnorton on 2011-10-30T12:31:49.000Z: Sanjay - The previous patch did fix the previous issue. However, a new counterexample in 31 steps was found (and is repeatable). The failing post condition is same as previous issue - a reappearing ghost key. [{init,{state,qc_statemc_lets,{state,false,false,undefined,[]}}}, COMMANDS: HISTORY: # 2: # 3: # 4: # 5: # 6: # 7: # 8: # 9: # 10: # 11: # 12: # 13: # 14: # 15: # 16: # 17: # 18: # 19: # 20: # 21: # 22: # 23: # 24: # 25: # 26: # 27: # 28: # 29: # 30: # 31: RESULT: STATE: STATE IS SANE: |
Comment #7 originally posted by josephwnorton on 2011-11-01T17:31:20.000Z: Please close this issue - thanks! |
Comment #8 originally posted by dgrogan@chromium.org on 2011-11-07T21:24:38.000Z: <empty> |
Fix google#50 by using nullptr and adding stricter warning.
Original issue 44 created by josephwnorton on 2011-10-03T16:13:29.000Z:
I'm testing an Erlang-based API for leveldb via an Erlang NIF written in C++. The test model is written in Erlang with the help of the test tool QuickCheck. The test model and test tool have found a failing minimal test case of 17 steps that appears (but not proven yet) to be an issue with leveldb.
I tried to manually create a minimal failing example that in pure C++. Unfortunately, I am unable to reproduce the issue with a pure C++ test case.
I attached the failing counterexample case and leveldb data directory after closing of the database. I'm hoping the leveldb authors might be able to pinpoint the issue or provide some instructions on how to troubleshoot this issue.
What steps will reproduce the problem?
What is the expected output? key3 at step 17
What do you see instead? key1 at step 17
> foobar:test().
<<10,0,0,0,12>>/'$end_of_table': [{obj,6,0}]
'$end_of_table'/'$end_of_table': []
'$end_of_table'/'$end_of_table': []
<<18,193,216,96,0,8>>/'$end_of_table': [{obj,6,0}]
<<18,193,216,96,0,8>>/'$end_of_table': [{obj,6,0}]
<<10,0,0,0,12>>/<<18,193,216,96,0,8>>: [{obj,6,0},{obj,6,0}]
ok
What version of the product are you using? On what operating system?
commit 26db4d9
Author: Hans Wennborg <hans@chromium.org>
Date: Mon Sep 26 17:37:09 2011 +0100
The issue repeats on MacOS X Lion and Fedora 15.
Please provide any additional information below.
The following shutdown sequence is performed at the time of closing the database:
The text was updated successfully, but these errors were encountered: