MDBX_CORRUPTED on APPENDDUP happened again in the same place

[AskAlexSharov]

This issue #126 - happened again on fresh devel: d9b95aa

It happened in the same place (probably old dataset can reproduce problem), but I will send you link to new one soon.

Now running test on master...

[erthink]

It doesn't reproduce by the old dataset (both on the master and devel).

[AskAlexSharov]

master - works well

[erthink]

master - works well

There are no differences between the master and the devel to justify the difference in behavior. Actually the changes are:

• .github/actions;
• __ty/__except for Windows;
• internal result code checking in extra-rare cases (process killed during reader registration, etc).

[erthink]

I will send you link to new one soon.

404: Tunnel xxxxxxxxxxxx.yyyyy.io not found

[erthink]

Unconfirmed at 62% (currently downloaded) of dataset.
The last key a36a78fc0d8042f611bbf9c3da63e882bdccdc05d11684ed0569059212e1989c.

$ lz4 -d < CST2.lz4 \
  | sed s/mapsize=2199023255552/geometry=l268435456,c268435456,u25769803776,s268435456,g268435456/ \
  | ./mdbx_load -an proba.db
mdbx_load v0.9.1-140-g9ef60571 (2020-11-26T04:28:01+03:00, T-706a0a22c45d7efc141c0e0588aad6efa6a404d8)
Running for proba.db...
Error 68 : Unfinished stream 

$ ./mdbx_chk -v proba.db 
mdbx_chk v0.9.1-140-g9ef60571 (2020-11-26T04:28:01+03:00, T-706a0a22c45d7efc141c0e0588aad6efa6a404d8)
Running for proba.db in 'read-only' mode...
 - monopolistic mode
 - current boot-id adb5ca01a583706f-9889ac2fba8442d9
 - pagesize 4096 (4096 system), max keysize 1300..1344, max readers 120
 - mapsize 25769803776 (24.00 Gb)
 - dynamic datafile: 268435456 (256.00 Mb) .. 25769803776 (24.00 Gb), +268431360 (256.00 Mb), -268431360 (256.00 Mb)
 - current datafile: 18253332480 (17.00 Gb), 4456380 pages
 - transactions: recent 31633, latter reader 31633, lag 0
 - meta-0: steady txn#31633, head
 - meta-1: weak-intact (same boot-id) txn#31631, tail
 - meta-2: weak-intact (same boot-id) txn#31632, stay
Traversal b-tree by txn#31633...
 - found 'CST2' area
 - pages: walked 4409910, left/unused 17
 - summary: average fill 96.4%, 0 problems
Processing '@MAIN'...
 - key-value kind: usual-key => single-value
 - summary: 1 records, 0 dups, 4 key's bytes, 48 data's bytes, 0 problems
Processing '@GC'...
 - key-value kind: ordinal-key => single-value
 - fixed key-size 8
 - summary: 2 records, 0 dups, 16 key's bytes, 76 data's bytes, 0 problems
 - space: 6291456 total pages, backed 4456380 (70.8%), allocated 4409927 (70.1%), available 1881536 (29.9%)
Processing 'CST2'...
 - key-value kind: usual-key => multi-value
 - last modification txn#31633
 - summary: 316299763 records, 238125186 dups, 12092482896 key's bytes, 11301987966 data's bytes, 0 problems
No error is detected, elapsed 179.030 seconds

$ ./mdbx_dump -a proba.db | tail
mdbx_dump v0.9.1-140-g9ef60571 (2020-11-26T04:28:01+03:00, T-706a0a22c45d7efc141c0e0588aad6efa6a404d8)
Running for proba.db...
 030101070536b1ff117a00
 a36a78b221d48de19d9b18528b19e8b281d089f948c1fefe65388f7c0e8d8d1c
 010103
 a36a78b955d39203395f6c0ca0d643121fb5cc300bab4827065a1d470a6dee5a
 010102
 a36a78c78122ea1c0cf865c8ab06508c0a2ada141bf7ca8b2898679817a97197
 030104071c6bf526340000
 a36a78fc0d8042f611bbf9c3da63e882bdccdc05d11684ed0569059212e1989c
 0d01010101209e64d1033b70d677da4e9a8ee8656162ba6921e70cd8f1f22d3a27b50d6556db
DATA=END

[erthink]

Tested with the full data set (~35 GB) on three different machines with different compilers.
The problem is not reproducible.

[erthink]

На всякий случай, для информации:

• было проверено совпадение исходных данных дампа и после его загрузки.
• sha256 дайджест дампа (без заголовка, начиная со строки HEADER=END, включительно) равен
  d8702c5e1fe1024f71376af12bff84ada34f5f92bee27cc7b768cf45cd558393.

[AskAlexSharov]

I think need load this dump same way as we did before: in 1 transaction.
mdbx_load does commit periodically.

I still didn't well reproduced it - tomorrow will try to make it reproducible, because I just faced it on v0.9.2 in another place of application in big transaction (on AppendDup).

[erthink]

I disabled intermediate commits by commenting out the code fragment.
Then build library and tools with -DMDBX_FORCE_ASSERTIONS=1 for more checking and run mdbx_load.

The data was loaded successfully and the mdbx_chk output shows that all ~26Gb was loaded in a single transaction.
Moreover, after that, I checked that the sha256 digest of the database dump remained the same (i.e. d8702c5e1fe1024f71376af12bff84ada34f5f92bee27cc7b768cf45cd558393).

So sure no such bug.

[erthink]

It is worth noting that such large transactions (without MDBX_WRITEMAP) are at the limit of my laptop's capabilities :(