openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

(ITS#8917) OpenLDAP
by nanmor＠126.com 21 Sep '18

21 Sep '18

Full_Name: Nancy Mo Version: openldap-clients-2.4.44-15.el7_5.x86_64 OS: Redhat 7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (106.38.0.87) Hi team, Linux server is redhat7, and installed Openssl-1.1.1 which is support for TLS1.3。 I tried to connect a LDAP server which is used TLS1.3, the openldap client connection failed, if the server setting change to TLS 1.2, it can connected successfully。 By the way, use the openssl s_client -connect HOSTNAME.com:636, it will use TLS 1.3, and connect successfully. In the ldap.conf, I have set two parameters： TLS_CACERTDIR /etc/openldap/certs TLS_REQCERT never Why the openldap client can not use TLS1.3? Thanks a lot. beat regards nancy

1 0

Re: (ITS#8916) MDB_VL32 in readonly causes MDB_CORRUPTED
by pierre.chambart＠ocamlpro.com 19 Sep '18

19 Sep '18

On 19/09/2018 17:35, Howard Chu wrote: > pierre.chambart(a)ocamlpro.com wrote: >> Full_Name: Pierre Chambart >> Version:=20 >> OS:=20 >> URL:=20 >> Submission from: (NULL) (185.194.234.133) >> >> >> We have been trying LMDB compiled with the MDB_VL32 flag and encounter= ed some >> MDB_CORRUPTED error that didn't occur without MDB_VL32. >> We could produce a minimal reproduction case: >> https://raw.githubusercontent.com/chambart/lmdb/vl32_readonly_fix/libr= aries/liblmdb/vl32_failure.c >> This is basically writing a key, reading it, writing something else th= en reading >> it again. >> >> After some investigation, this is how I understand what is happening: >> >> * The chunk being mapped for the first read contains 3 pages instead o= f the 16 >> pages that would be mapped without readonly. >> * The second write extend the size of the base to 5 pages >> * Finally the last read retrieve the mapped chunk from the first read,= which has >> size 3, but assumes that it has size 5, hence reading some random valu= e in >> memory past the end of the pages. >> >> It can be verified by asserting that id3.mcnt is larger than rem at th= e end of >> mdb_rpage_get, around this line: >> >> ok: >> p =3D (MDB_page *)((char *)id3.mptr + rem * env->me_psize); >> >> This does not seem to be the case. >> >> I made a dirty fix that seems to work. It's simply to remove those lin= es: >> >> /* don't map past last written page in read-only envs */ >> if ((env->me_flags & MDB_RDONLY) && pgno + MDB_RPAGE_CHUNK-1 >= >> txn->mt_last_pgno) >> id3.mcnt =3D txn->mt_last_pgno + 1 - pgno; >> else >> >> This seems to be some optimization that avoids mapping the 16 pages of= the >> chunk. But given that those pages are >> initialized, there doesn't seem to be much harm in mapping a few more = pages in >> that relatively rare situation. > Please check git history before assuming the code is an optimization. > > These lines prevent a crash on Windows. > Sorry, about that. Also I'm not suggesting that this is a proper fix, rather that this is so= me clue to understand the problem. I'm happy producing a patch if you indicate what kind of fix you would like. --=20 Pierre

1 0

Re: (ITS#8916) MDB_VL32 in readonly causes MDB_CORRUPTED
by hyc＠symas.com 19 Sep '18

19 Sep '18

pierre.chambart(a)ocamlpro.com wrote: > Full_Name: Pierre Chambart > Version: > OS: > URL: > Submission from: (NULL) (185.194.234.133) > > > We have been trying LMDB compiled with the MDB_VL32 flag and encountered some > MDB_CORRUPTED error that didn't occur without MDB_VL32. > We could produce a minimal reproduction case: > https://raw.githubusercontent.com/chambart/lmdb/vl32_readonly_fix/libraries… > This is basically writing a key, reading it, writing something else then reading > it again. > > After some investigation, this is how I understand what is happening: > > * The chunk being mapped for the first read contains 3 pages instead of the 16 > pages that would be mapped without readonly. > * The second write extend the size of the base to 5 pages > * Finally the last read retrieve the mapped chunk from the first read, which has > size 3, but assumes that it has size 5, hence reading some random value in > memory past the end of the pages. > > It can be verified by asserting that id3.mcnt is larger than rem at the end of > mdb_rpage_get, around this line: > > ok: > p = (MDB_page *)((char *)id3.mptr + rem * env->me_psize); > > This does not seem to be the case. > > I made a dirty fix that seems to work. It's simply to remove those lines: > > /* don't map past last written page in read-only envs */ > if ((env->me_flags & MDB_RDONLY) && pgno + MDB_RPAGE_CHUNK-1 > > txn->mt_last_pgno) > id3.mcnt = txn->mt_last_pgno + 1 - pgno; > else > > This seems to be some optimization that avoids mapping the 16 pages of the > chunk. But given that those pages are > initialized, there doesn't seem to be much harm in mapping a few more pages in > that relatively rare situation. Please check git history before assuming the code is an optimization. These lines prevent a crash on Windows. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#8916) MDB_VL32 in readonly causes MDB_CORRUPTED
by pierre.chambart＠ocamlpro.com 19 Sep '18

19 Sep '18

Full_Name: Pierre Chambart Version: OS: URL: Submission from: (NULL) (185.194.234.133) We have been trying LMDB compiled with the MDB_VL32 flag and encountered some MDB_CORRUPTED error that didn't occur without MDB_VL32. We could produce a minimal reproduction case: https://raw.githubusercontent.com/chambart/lmdb/vl32_readonly_fix/libraries… This is basically writing a key, reading it, writing something else then reading it again. After some investigation, this is how I understand what is happening: * The chunk being mapped for the first read contains 3 pages instead of the 16 pages that would be mapped without readonly. * The second write extend the size of the base to 5 pages * Finally the last read retrieve the mapped chunk from the first read, which has size 3, but assumes that it has size 5, hence reading some random value in memory past the end of the pages. It can be verified by asserting that id3.mcnt is larger than rem at the end of mdb_rpage_get, around this line: ok: p = (MDB_page *)((char *)id3.mptr + rem * env->me_psize); This does not seem to be the case. I made a dirty fix that seems to work. It's simply to remove those lines: /* don't map past last written page in read-only envs */ if ((env->me_flags & MDB_RDONLY) && pgno + MDB_RPAGE_CHUNK-1 > txn->mt_last_pgno) id3.mcnt = txn->mt_last_pgno + 1 - pgno; else This seems to be some optimization that avoids mapping the 16 pages of the chunk. But given that those pages are initialized, there doesn't seem to be much harm in mapping a few more pages in that relatively rare situation. The patch is provided in https://github.com/chambart/lmdb/commit/52e57a392e91935efe6d57337da09f23e40… If you want to reproduce the bug you can use the https://github.com/chambart/lmdb/tree/vl32_readonly_fix which also contains the patch to the makefile to build in 32bits with MDB_VL32. Thanks a lot, hoping that this can be of some help.

1 0

Re: (ITS#8650) EAGAIN from gnutls_handshake not respected
by ryan＠nardis.ca 18 Sep '18

18 Sep '18

Made some good progress on this one this evening. The original issue this ITS is about is that gnutls_handshake() can, in some versions of GnuTLS, return GNUTLS_E_AGAIN even when the socket is blocking. Specifically, this happens in the case I described with a large CA list sent by the server. For slapd, the patch I committed is unfortunately completely wrong. It has been using non-blocking sockets forever, EAGAIN is expected and handled robustly -- or it was, until I introduced the busy-loop. For clients I'm still working on figuring out the right path forward. There is some EAGAIN handling conditional on LDAP_USE_NON_BLOCKING_TLS which itself is behind LDAP_DEVEL. However this code is meant for non-blocking sockets, and in my case it ends up stuck in poll() waiting for a notification that never arrives. In 2.4, ret == 1 simply falls into the success case and proceeds to send data without completing the handshake first. It's possible that what I actually want here is a (ret > 0) case in ldap_int_tls_start for when LDAP_USE_NON_BLOCKING_TLS is absent and ldap_int_tls_connect returns 1. (I'd also need to adapt the non-blocking path to be able to handle a blocking socket as well.) But it's also possible that gnutls_handshake() returning GNUTLS_E_AGAIN with a blocking socket is simply a GnuTLS bug that was introduced at some point. I still need to determine exactly when and why its behaviour changed. (It is still happening with 3.5.19.) In any case, my patch has to be reverted, as its impact (making slapd busy-loop) is obviously worse than the status quo (misbehaving clients in a specific case). I have pushed that revert now and will continue digging as time permits.

1 0

(ITS#8915) OpenLDAP and OpenSSL v1.1.1
by neal.brown＠threesl.com 13 Sep '18

13 Sep '18

Full_Name: Neal Brown Version: 2.4.46 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (88.98.37.245) OpenLDAP will not configure for building against OpenSSL v1.1.1 due to SSLv3 being disabled.

1 0

(ITS#8914) OpenLDAP and OpenSSL v1.1.1
by nea.brown＠threesl.com 13 Sep '18

13 Sep '18

1 0

Re: (ITS#8898) mdb_get on corrupted LMDB file crash the process
by hyc＠symas.com 12 Sep '18

12 Sep '18

Irad K wrote: > Hi Howard and thanks for the info.=C2=A0 >=20 > I've read your insights about the corruption nature and I'd like to see= if I can write some sort of integrity check before I try to open the fil= e.=C2=A0 > Perhaps you could guide me where to look for the file format, where can= I find all the meta-pages and in which offset can I find the used pages = ? Read the source yourself if you want to know the underlying format. Other= wise, just use mdb_env_info(). =C2=A0 > Basically, I wish to check the latest meta-page and see if the number o= f pages correspond with the file actual size.=C2=A0 >=20 > Second, as I've stated, my target operating system is macOS.. are you f= amiliar of any known issues with file atomicity in this particular OS ?=C2= =A0 > Perhaps you could tell me how it's implemented under the hood to achiev= e data consistency if I'm using the database using MDB_NOMETASYNC, so I f= urther > investigate this issue and address it to Apple if necessary.=20 I've seen other reports of corruptions on MacOSX. Since they're in SQLite= I haven't investigated further. http://sqlite.1065341.n5.nabble.com/SQLITE-vs-OSX-mmap-inevitable-catalog= -corruption-td85620.html http://sqlite.1065341.n5.nabble.com/Re-Database-corruption-and-PRAGMA-ful= lfsync-on-macOS-td95366i20.html >=20 > Irad >=20 > On Mon, Sep 10, 2018 at 8:44 PM Howard Chu <hyc(a)symas.com <mailto:hyc@s= ymas.com>> wrote: >=20 > iradization(a)gmail.com <mailto: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 :=C2=A0 MDB_NOMETA= SYNC | MDB_NOSUBDIR > > | MDB_NOTLS. > > > > Somehow, even though the DB should be ACI(without the D),=C2=A0 i= t got corrupted > > after recovering from kernel panic, and It crashes my process whe= n 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=3Dsharing >=20 > This file is only 6 pages long, but the latest meta page claims tha= t it's using 11 pages. > Looking at the previous meta page, it claims that 9 pages were used= . >=20 > 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. >=20 > > According to the crash log from the process, It can clearly be se= en 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 a= lready there), > > or trigger page fault trap that eventually lead to reading the mi= ssing 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 b= e coherent to > > file contents. > > > > Any idea how did it happen, and what exactly in the file cause th= is corruption ? > > > > > > CRASH LOG : > > -----------------------------------------------------------------= ----- > > Exception Type:=C2=A0 =C2=A0 =C2=A0 =C2=A0 EXC_BAD_ACCESS (SIGBUS= ) > > Exception Codes:=C2=A0 =C2=A0 =C2=A0 =C2=A0KERN_MEMORY_ERROR at 0= x000000010648800a > > Exception Note:=C2=A0 =C2=A0 =C2=A0 =C2=A0 EXC_CORPSE_NOTIFY > > > > Termination Signal:=C2=A0 =C2=A0 Bus error: 10 > > Termination Reason:=C2=A0 =C2=A0 Namespace SIGNAL, Code 0xa > > Terminating Process:=C2=A0 =C2=A0exc handler [0] > > > > VM Regions Near 0x10648800a: > > > > __LINKEDIT=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00000000= 106464000-000000010647f000 [=C2=A0 108K] r--/rwx SM=3DCOW > >=C2=A0 ^Z^C [/usr/lib/dyld] > > --> mapped file=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 00000001= 0647f000-000000011647f000 [256.0M] r--/rwx > > SM=3DPRV=C2=A0 Object_id=3D9034edd9 > > STACK GUARD=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 000070000f2b= 3000-000070000f2b4000 [=C2=A0 =C2=A0 4K] ---/rwx SM=3DNUL > >=C2=A0 stack guard for thread 1 > > > > Thread 0 Crashed:: Dispatch queue: com.apple.main-thread > > 0=C2=A0 =C2=A0myprog=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x0000000101666756 mdb_page_search_root + = 39 > > 1=C2=A0 =C2=A0myprog=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x00000001016660f7 mdb_page_search + 182 > > 2=C2=A0 =C2=A0myprog=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x00000001016614de mdb_cursor_set + 88 > > 3=C2=A0 =C2=A0myprog=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x0000000101661476 mdb_get + 134 > > > > > > >=20 >=20 > --=20 > =C2=A0 -- Howard Chu > =C2=A0 CTO, Symas Corp.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0htt= p://www.symas.com > =C2=A0 Director, Highland Sun=C2=A0 =C2=A0 =C2=A0http://highlandsun= .com/hyc/ > =C2=A0 Chief Architect, OpenLDAP=C2=A0 http://www.openldap.org/proj= ect/ >=20 --=20 -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#8898) mdb_get on corrupted LMDB file crash the process
by iradization＠gmail.com 11 Sep '18

11 Sep '18

--000000000000d405310575a6de5e Content-Type: text/plain; charset="UTF-8" Hi Howard and thanks for the info. I've read your insights about the corruption nature and I'd like to see if I can write some sort of integrity check before I try to open the file. Perhaps you could guide me where to look for the file format, where can I find all the meta-pages and in which offset can I find the used pages ? Basically, I wish to check the latest meta-page and see if the number of pages correspond with the file actual size. Second, as I've stated, my target operating system is macOS.. are you familiar of any known issues with file atomicity in this particular OS ? Perhaps you could tell me how it's implemented under the hood to achieve data consistency if I'm using the database using MDB_NOMETASYNC, so I further investigate this issue and address it to Apple if necessary. Irad On Mon, Sep 10, 2018 at 8:44 PM Howard Chu <hyc(a)symas.com> wrote: > iradization(a)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=… > > 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/ > --000000000000d405310575a6de5e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr">Hi Howard and thanks for= the info.=C2=A0<div><br><div>I've read your insights about the corrupt= ion nature and I'd like to see if I can write some sort of integrity ch= eck before I try to open the file.=C2=A0</div><div>Perhaps you could guide = me where to look for the file format, where can I find all the meta-pages a= nd in which offset can I find the used pages ?=C2=A0</div><div>Basically, I= wish to check the latest meta-page and see if the number of pages correspo= nd with the file actual size.=C2=A0<br></div><div><br></div><div>Second, as= I've stated, my target operating system is macOS.. are you familiar of= any known issues with file atomicity in this particular OS ?=C2=A0</div></= div><div><div>Perhaps you could tell me how it's implemented under the = hood to achieve data consistency if I'm using the database using MDB_NO= METASYNC, so I further investigate this issue and address it to Apple if ne= cessary.=C2=A0</div></div><div><br></div><div>Irad</div></div></div></div><= br><div class=3D"gmail_quote"><div dir=3D"ltr">On Mon, Sep 10, 2018 at 8:44= PM Howard Chu <<a href=3D"mailto:hyc@symas.com">hyc(a)symas.com</a>> w= rote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex= ;border-left:1px #ccc solid;padding-left:1ex"><a href=3D"mailto:iradization= @gmail.com" target=3D"_blank">iradization(a)gmail.com</a> wrote:<br> > Full_Name: Irad.k<br> > Version: recent from GitHub.<br> > OS: macOS<br> > URL: <a href=3D"ftp://ftp.openldap.org/incoming/" rel=3D"noreferrer" t= arget=3D"_blank">ftp://ftp.openldap.org/incoming/</a><br> > Submission from: (NULL) (82.81.84.130)<br> > <br> > <br> > Hi, <br> > <br> > I'm working with LMDB with the following flags :=C2=A0 MDB_NOMETAS= YNC | MDB_NOSUBDIR<br> > | MDB_NOTLS.<br> > <br> > Somehow, even though the DB should be ACI(without the D),=C2=A0 it got= corrupted<br> > after recovering from kernel panic, and It crashes my process when try= ing to<br> > access one of the records (see crash log below). <br> > <br> > Here's a link to the file : <br> > <br> > <a href=3D"https://drive.google.com/file/d/12Q3KYYrapiJOgiaccnDL3tQACk= qrM3C5/view?usp=3Dsharing" rel=3D"noreferrer" target=3D"_blank">https://dri= ve.google.com/file/d/12Q3KYYrapiJOgiaccnDL3tQACkqrM3C5/view?usp=3Dsharing</= a><br> <br> This file is only 6 pages long, but the latest meta page claims that it&#39= ;s using 11 pages.<br> Looking at the previous meta page, it claims that 9 pages were used.<br> <br> Clearly your OS failed to write the complete contents out before it panicke= d. At the<br> very least the file should have been 9 pages long. Sounds like you have an = OS bug.<br> <br> > According to the crash log from the process, It can clearly be seen th= at the<br> > invalid address reside inside the mapped file region which is the lmdb= mapped<br> > file, but still I get KERN_MEMORY_ERROR on that address.<br> > <br> >>From what I know, an attempt to access address within the mapped ra= nge can<br> > either retrieve the page contents directly from memory (if it's al= ready there),<br> > or trigger page fault trap that eventually lead to reading the missing= data from<br> > disk and return it to process as well.<br> > <br> > One thing that raise some concerns is that the file size is only 24k a= nd the<br> > mapping spans over 256M. However, the file's meta data seems to be= coherent to<br> > file contents.<br> > <br> > Any idea how did it happen, and what exactly in the file cause this co= rruption ?<br> > <br> > <br> > CRASH LOG :<br> > ----------------------------------------------------------------------= <br> > Exception Type:=C2=A0 =C2=A0 =C2=A0 =C2=A0 EXC_BAD_ACCESS (SIGBUS)<br> > Exception Codes:=C2=A0 =C2=A0 =C2=A0 =C2=A0KERN_MEMORY_ERROR at 0x0000= 00010648800a<br> > Exception Note:=C2=A0 =C2=A0 =C2=A0 =C2=A0 EXC_CORPSE_NOTIFY<br> > <br> > Termination Signal:=C2=A0 =C2=A0 Bus error: 10<br> > Termination Reason:=C2=A0 =C2=A0 Namespace SIGNAL, Code 0xa<br> > Terminating Process:=C2=A0 =C2=A0exc handler [0]<br> > <br> > VM Regions Near 0x10648800a:<br> > <br> > __LINKEDIT=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0000000010646= 4000-000000010647f000 [=C2=A0 108K] r--/rwx SM=3DCOW<br> >=C2=A0 ^Z^C [/usr/lib/dyld]<br> > --> mapped file=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0000000106= 47f000-000000011647f000 [256.0M] r--/rwx<br> > SM=3DPRV=C2=A0 Object_id=3D9034edd9<br> > STACK GUARD=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 000070000f2b3000-= 000070000f2b4000 [=C2=A0 =C2=A0 4K] ---/rwx SM=3DNUL<br> >=C2=A0 stack guard for thread 1<br> > <br> > Thread 0 Crashed:: Dispatch queue: com.apple.main-thread<br> > 0=C2=A0 =C2=A0myprog=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A00x0000000101666756 mdb_page_search_root + 39<br> > 1=C2=A0 =C2=A0myprog=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A00x00000001016660f7 mdb_page_search + 182<br> > 2=C2=A0 =C2=A0myprog=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A00x00000001016614de mdb_cursor_set + 88<br> > 3=C2=A0 =C2=A0myprog=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A00x0000000101661476 mdb_get + 134<br> > <br> > <br> > <br> <br> <br> -- <br> =C2=A0 -- Howard Chu<br> =C2=A0 CTO, Symas Corp.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<a href=3D"= http://www.symas.com" rel=3D"noreferrer" target=3D"_blank">http://www.symas= .com</a><br> =C2=A0 Director, Highland Sun=C2=A0 =C2=A0 =C2=A0<a href=3D"http://highland= sun.com/hyc/" rel=3D"noreferrer" target=3D"_blank">http://highlandsun.com/h= yc/</a><br> =C2=A0 Chief Architect, OpenLDAP=C2=A0 <a href=3D"http://www.openldap.org/p= roject/" rel=3D"noreferrer" target=3D"_blank">http://www.openldap.org/proje= ct/</a><br> </blockquote></div> --000000000000d405310575a6de5e--

1 0

Re: (ITS#8898) mdb_get on corrupted LMDB file crash the process
by hyc＠symas.com 10 Sep '18

10 Sep '18

iradization(a)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=… 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/

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs