[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: (ITS#8898) mdb_get on corrupted LMDB file crash the process
- To: openldap-its@OpenLDAP.org
- Subject: Re: (ITS#8898) mdb_get on corrupted LMDB file crash the process
- From: hyc@symas.com
- Date: Mon, 10 Sep 2018 17:44:49 +0000
- Auto-submitted: auto-generated (OpenLDAP-ITS)
iradization@gmail.com wrote:
> Full_Name: Irad.k
> Version: recent from GitHub.
> OS: macOS
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (82.81.84.130)
>
>
> Hi,
>
> I'm working with LMDB with the following flags : MDB_NOMETASYNC | MDB_NOSUBDIR
> | MDB_NOTLS.
>
> Somehow, even though the DB should be ACI(without the D), it got corrupted
> after recovering from kernel panic, and It crashes my process when trying to
> access one of the records (see crash log below).
>
> Here's a link to the file :
>
> https://drive.google.com/file/d/12Q3KYYrapiJOgiaccnDL3tQACkqrM3C5/view?usp=sharing
This file is only 6 pages long, but the latest meta page claims that it's using 11 pages.
Looking at the previous meta page, it claims that 9 pages were used.
Clearly your OS failed to write the complete contents out before it panicked. At the
very least the file should have been 9 pages long. Sounds like you have an OS bug.
> According to the crash log from the process, It can clearly be seen that the
> invalid address reside inside the mapped file region which is the lmdb mapped
> file, but still I get KERN_MEMORY_ERROR on that address.
>
>>From what I know, an attempt to access address within the mapped range can
> either retrieve the page contents directly from memory (if it's already there),
> or trigger page fault trap that eventually lead to reading the missing data from
> disk and return it to process as well.
>
> One thing that raise some concerns is that the file size is only 24k and the
> mapping spans over 256M. However, the file's meta data seems to be coherent to
> file contents.
>
> Any idea how did it happen, and what exactly in the file cause this corruption ?
>
>
> CRASH LOG :
> ----------------------------------------------------------------------
> Exception Type: EXC_BAD_ACCESS (SIGBUS)
> Exception Codes: KERN_MEMORY_ERROR at 0x000000010648800a
> Exception Note: EXC_CORPSE_NOTIFY
>
> Termination Signal: Bus error: 10
> Termination Reason: Namespace SIGNAL, Code 0xa
> Terminating Process: exc handler [0]
>
> VM Regions Near 0x10648800a:
>
> __LINKEDIT 0000000106464000-000000010647f000 [ 108K] r--/rwx SM=COW
> ^Z^C [/usr/lib/dyld]
> --> mapped file 000000010647f000-000000011647f000 [256.0M] r--/rwx
> SM=PRV Object_id=9034edd9
> STACK GUARD 000070000f2b3000-000070000f2b4000 [ 4K] ---/rwx SM=NUL
> stack guard for thread 1
>
> Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
> 0 myprog 0x0000000101666756 mdb_page_search_root + 39
> 1 myprog 0x00000001016660f7 mdb_page_search + 182
> 2 myprog 0x00000001016614de mdb_cursor_set + 88
> 3 myprog 0x0000000101661476 mdb_get + 134
>
>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/