Brüns, Stefan wrote:

Hi,

I see a similar problem as reported in October 2017 for mdb_cursor_del, i.e. pages ending up twice on the dirty list.

Backtrace: #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 #1 0x00007ffff61c8da1 in __GI_abort () at abort.c:79 #2 0x00007ffff5a31052 in mdb_assert_fail (env=0x55555579d6e0, expr_txt=expr_txt@entry=0x7ffff5a3294f "rc == 0", func=func@entry=0x7ffff5a33268 <__func__.7016> "mdb_page_dirty", line=line@entry=2127, file=0x7ffff5a32930 "mdb.c") at mdb.c:1542 #3 0x00007ffff5a25fe5 in mdb_page_dirty (txn=0x55555579eaa0, mp=<optimized out>) at mdb.c:2127 #4 0x00007ffff5a2720b in mdb_page_alloc (num=num@entry=1, mp=mp@entry=0x7fffffffd110, mc=<optimized out>) at mdb.c:2308 #5 0x00007ffff5a29114 in mdb_page_new (mc=mc@entry=0x7fffffffd2f0, flags=flags@entry=4, num=1, mp=mp@entry=0x7fffffffd170) at mdb.c:7147 #6 0x00007ffff5a29519 in mdb_node_add (mc=mc@entry=0x7fffffffd2f0, indx=<optimized out>, key=key@entry=0x7fffffffd6c0, data=0x7fffffffd6d0, pgno=pgno@entry=0, flags=0) at mdb.c:7289 #7 0x00007ffff5a2ca59 in mdb_cursor_put (mc=0x7fffffffd2f0, key=0x7fffffffd6c0, data=0x7fffffffd6d0, flags=<optimized out>) at mdb.c:6916 #8 0x00007ffff5a2ee4b in mdb_put (txn=0x55555579eaa0, dbi=3, key=key@entry=0x7fffffffd6c0, data=data@entry=0x7fffffffd6d0, flags=flags@entry=0) at mdb.c:8991

---

I have tracked down the moment where the duplicate pgno is added to the list:

#0 mdb_page_alloc (num=num@entry=6, mp=mp@entry=0x7fffffffd110, mc=<optimized out>) at mdb.c:2277 #1 0x00007ffff5a29114 in mdb_page_new (mc=mc@entry=0x7fffffffd2f0, flags=flags@entry=4, num=6, mp=mp@entry=0x7fffffffd170) at mdb.c:7147 #2 0x00007ffff5a29519 in mdb_node_add (mc=mc@entry=0x7fffffffd2f0, indx=<optimized out>, key=key@entry=0x7fffffffd6c0, data=0x7fffffffd6d0, pgno=pgno@entry=0, flags=0) at mdb.c:7289 #3 0x00007ffff5a2ca59 in mdb_cursor_put (mc=0x7fffffffd2f0, key=0x7fffffffd6c0, data=0x7fffffffd6d0, flags=<optimized out>) at mdb.c:6916 #4 0x00007ffff5a2ee4b in mdb_put (txn=0x55555579eaa0, dbi=3, key=key@entry=0x7fffffffd6c0, data=data@entry=0x7fffffffd6d0, flags=flags@entry=0) at mdb.c:8991

---

(gdb) p idl[0] $22 = 47

(gdb) x/18g &idl[ 30 ] 0x7fbff2d1ef20: 20234 20230 0x7fbff2d1ef30: 20229 20228 0x7fbff2d1ef40: 19230 19228 0x7fbff2d1ef50: 17181 17180 0x7fbff2d1ef60: 15736 15736 <- double entry 0x7fbff2d1ef70: 15274 8470 0x7fbff2d1ef80: 8438 7176 0x7fbff2d1ef90: 7174 4758 0x7fbff2d1efa0: 4719 1213

So the double page number is already stored in the freelist in the database, i.e. the database itself is corrupt.

The database was initially created with lmdb 0.9.17, currently I am using 0.9.22.

Any idea how to deal with this issue?

Can you list the steps to reproduce the issue?