Project

General

Profile

Bug #8446

sdbm fails to fetch existing key if many elements in it

Added by arton (Akio Tajima) over 6 years ago. Updated 4 months ago.

Status:
Open
Priority:
Normal
Assignee:
-
Target version:
-
ruby -v:
ruby 2.1.0dev (2013-05-24 trunk 40916) [x86_64-linux]
Backport:
[ruby-core:55154]

Description

=begin
When I store many keys in SDBM, it may fail to fetch the value and returns nil.
The maximum number of all readable keys is varied by the value size.
I believe it's best to be able to store and restore as many as disk size is not full, and it's better to raise an exception while storing time if it can't handle the key.

((|Below is the output of the attached test.|))

Run options:

# Running tests:

[1/1] TestManyValues#test_many = 0.08 s
1) Failure:
TestManyValues#test_many [test_sdbm_many.rb:38]:
<"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@1878"> expected but was
.

Finished tests in 0.089022s, 11.2332 tests/s, 21095.8954 assertions/s.
1 tests, 1878 assertions, 1 failures, 0 errors, 0 skips

=end


Files

test_sdbm_many.rb (873 Bytes) test_sdbm_many.rb arton (Akio Tajima), 05/24/2013 11:22 PM

History

Updated by hsbt (Hiroshi SHIBATA) almost 6 years ago

  • Target version changed from 2.1.0 to 2.2.0
#2

Updated by naruse (Yui NARUSE) almost 2 years ago

  • Target version deleted (2.2.0)

Updated by jeremyevans0 (Jeremy Evans) 4 months ago

  • Backport deleted (1.9.3: UNKNOWN, 2.0.0: UNKNOWN)

This bug still exists. With enough entries in the database, the retrieval error rate gets fairly high (almost 2% at 32k entries):

# missed keys, total entries, error rate
2, 4096, 0.00048828125
14, 8192, 0.00170898437
79, 16384, 0.00482177734375
610, 32768, 0.01861572265625
1043, 65536, 0.0159149169921875
1221, 131072, 0.00931549072265625
1291, 262144, 0.004924774169921875

From some debugging, this is due to makroom modifying the database, losing access to the key. Before key 4011 is added, a retrieval of key 1878 in getpage has:

dbit: 4915
pagb: 608
db->hmask: 4095

After key 4011 is added, a retrieval of key 1878 in getpage has:

dbit: 134300
pagb: 94816
db->hmask: 131071

The data is still in the database, even if it is not reachable. A read for key '1878' attempts to read at offset 97091584 in the pag file, when the correct offset in the pag file would be 29982720. Unfortunately, I don't have more time to look into this.

Also available in: Atom PDF