[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Issue with mdb_cursor_put
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?
Kind regards, Stefan
--
Stefan Brüns / Bergstraße 21 / 52062 Aachen
home: +49 241 53809034 mobile: +49 151 50412019