openldap-bugs

openldap-bugs@openldap.org

1 participants
21003 discussions

(ITS#8109) SEGFAULT mdb_cursor_del mdb_cursor_get(MDB_PREV)
by rouzier＠gmail.com 19 Apr '15

19 Apr '15

Full_Name: James Rouzier Version: LMDB mdb.master OS: linux URL: https://gist.github.com/rouzier/2d268a2f24e82e00f498 Submission from: (NULL) (70.81.32.80) When iterating with a cursor using MDB_PREV and deleting entries using mdb_cursor_del. It will crash when calling mdb_cursor_get after the last entry was deleted. I am using the latest version of LMDB in git.

1 0

(ITS#8108) possible bug in slapcat(8)
by igor.shmukler＠gmail.com 19 Apr '15

19 Apr '15

Full_Name: Igor Shmukler Version: 2.4 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.146.103.114) I make a use of olcHidden. When set to true, olcHidden breaks slapcat. $ sudo slapcat -n 0 5530b282 olcRootPW: value #0: <olcRootPW> can only be set when rootdn is under suffix 5530b282 config error processing olcDatabase={2}hdb,cn=config: <olcRootPW> can only be set when rootdn is under suffix slapcat: bad configuration file!

1 0

Re: (ITS#8107) olcMemberOfDangling: error doesn't prevent adding nonexistent member to group
by ryan＠nardis.ca 18 Apr '15

18 Apr '15

Adding a new group containing a nonexistent member, or or a nonexistent member to an existing group, triggers the following AddressSanitizer splat. No error when adding a valid member, or with memberof disabled. (Line numbers from git master) 5532dc8c connection_get(11): got connid=1000 5532dc8c connection_read(11): checking for input on id=1000 ber_get_next ber_get_next: tag 0x30 len 66 contents: 5532dc8c op tag 0x66, time 1429396620 ber_get_next 5532dc8c conn=1000 op=2 do_modify ber_scanf fmt ({m) ber: ber_scanf fmt ({e{m[W]}}) ber: 5532dc8c >>> dnPrettyNormal: <cn=testgroup,dc=example,dc=com> 5532dc8c <<< dnPrettyNormal: <cn=testgroup,dc=example,dc=com>, <cn=testgroup,dc=example,dc=com> 5532dc8c >>> dnPretty: <cn=dummy> 5532dc8c <<< dnPretty: <cn=dummy> 5532dc8c >>> dnNormalize: <cn=dummy> 5532dc8c <<< dnNormalize: <cn=dummy> 5532dc8c => mdb_search 5532dc8c mdb_dn2entry("cn=testgroup,dc=example,dc=com") 5532dc8c => mdb_dn2id("cn=testgroup,dc=example,dc=com") 5532dc8c <= mdb_dn2id: got id=0x3 5532dc8c => mdb_entry_decode: 5532dc8c <= mdb_entry_decode 5532dc8c send_ldap_result: conn=1000 op=2 p=3 5532dc8c mdb_dn2entry("cn=dummy") 5532dc8c => mdb_dn2id("cn=dummy") ================================================================= ==1998==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000024967 at pc 0x000000ebdb1f bp 0x7f91f2773650 sp 0x7f91f2773648 READ of size 1 at 0x602000024967 thread T2 #0 0xebdb1e in lutil_strncopy /home/ryan/pkg/openldap/openldap/libraries/liblutil/utils.c:317:2 #1 0xd10adb in mdb_dn2id /home/ryan/pkg/openldap/openldap/servers/slapd/back-mdb/dn2id.c:360:9 #2 0xd0798e in mdb_dn2entry /home/ryan/pkg/openldap/openldap/servers/slapd/back-mdb/dn2entry.c:51:7 #3 0xd4afb5 in mdb_entry_get /home/ryan/pkg/openldap/openldap/servers/slapd/back-mdb/id2entry.c:336:7 #4 0xa8feb5 in overlay_entry_get_ov /home/ryan/pkg/openldap/openldap/servers/slapd/backover.c:376:9 #5 0xaa6dd2 in over_entry_get_rw /home/ryan/pkg/openldap/openldap/servers/slapd/backover.c:408:9 #6 0x6a4d9c in be_entry_get_rw /home/ryan/pkg/openldap/openldap/servers/slapd/backend.c:1436:10 #7 0xdb6298 in memberof_op_modify /home/ryan/pkg/openldap/openldap/servers/slapd/overlays/memberof.c:892:12 #8 0xa931bb in overlay_op_walk /home/ryan/pkg/openldap/openldap/servers/slapd/backover.c:681:9 #9 0xaadbea in over_op_func /home/ryan/pkg/openldap/openldap/servers/slapd/backover.c:749:7 #10 0xaa5493 in over_op_modify /home/ryan/pkg/openldap/openldap/servers/slapd/backover.c:788:9 #11 0x7144f2 in fe_op_modify /home/ryan/pkg/openldap/openldap/servers/slapd/modify.c:303:4 #12 0x70b08e in do_modify /home/ryan/pkg/openldap/openldap/servers/slapd/modify.c:177:15 #13 0x609ccc in connection_operation /home/ryan/pkg/openldap/openldap/servers/slapd/connection.c:1134:7 #14 0x602ec3 in connection_read_thread /home/ryan/pkg/openldap/openldap/servers/slapd/connection.c:1280:14 #15 0xf094de in ldap_int_thread_pool_wrapper /home/ryan/pkg/openldap/openldap/libraries/libldap_r/tpool.c:958:3 #16 0x7f91fc2f40a3 in start_thread /build/glibc-Ir_s5K/glibc-2.19/nptl/pthread_create.c:309 #17 0x7f91fb70604c in clone /build/glibc-Ir_s5K/glibc-2.19/misc/../sysdeps/unix/sysv/linux/x86_64/clone.S:111 0x602000024967 is located 9 bytes to the left of 10-byte region [0x602000024970,0x60200002497a) allocated by thread T2 here: #0 0x4bb46b in malloc (/usr/local/libexec/slapd+0x4bb46b) #1 0x10e4d7f in ber_memalloc_x /home/ryan/pkg/openldap/openldap/libraries/liblber/memory.c:228:9 #2 0xfc01e1 in ldap_dn2bv_x /home/ryan/pkg/openldap/openldap/libraries/libldap_r/getdn.c:3015:23 #3 0x6e7a37 in dnNormalize /home/ryan/pkg/openldap/openldap/servers/slapd/dn.c:454:8 #4 0x744d1d in ordered_value_normalize /home/ryan/pkg/openldap/openldap/servers/slapd/value.c:587:7 #5 0x7106cd in slap_mods_check /home/ryan/pkg/openldap/openldap/servers/slapd/modify.c:627:11 #6 0x70aca3 in do_modify /home/ryan/pkg/openldap/openldap/servers/slapd/modify.c:168:15 #7 0x609ccc in connection_operation /home/ryan/pkg/openldap/openldap/servers/slapd/connection.c:1134:7 #8 0x602ec3 in connection_read_thread /home/ryan/pkg/openldap/openldap/servers/slapd/connection.c:1280:14 #9 0xf094de in ldap_int_thread_pool_wrapper /home/ryan/pkg/openldap/openldap/libraries/libldap_r/tpool.c:958:3 #10 0x7f91fc2f40a3 in start_thread /build/glibc-Ir_s5K/glibc-2.19/nptl/pthread_create.c:309 Thread T2 created by T1 here: #0 0x4a309f in __interceptor_pthread_create (/usr/local/libexec/slapd+0x4a309f) #1 0xf1d269 in ldap_pvt_thread_create /home/ryan/pkg/openldap/openldap/libraries/libldap_r/thr_posix.c:165:8 #2 0xf05f35 in ldap_pvt_thread_pool_submit /home/ryan/pkg/openldap/openldap/libraries/libldap_r/tpool.c:420:12 #3 0x5e92a5 in slap_listener_activate /home/ryan/pkg/openldap/openldap/servers/slapd/daemon.c:2097:7 #4 0x5e17a4 in slapd_daemon_task /home/ryan/pkg/openldap/openldap/servers/slapd/daemon.c:2728:10 #5 0x7f91fc2f40a3 in start_thread /build/glibc-Ir_s5K/glibc-2.19/nptl/pthread_create.c:309 Thread T1 created by T0 here: #0 0x4a309f in __interceptor_pthread_create (/usr/local/libexec/slapd+0x4a309f) #1 0xf1d269 in ldap_pvt_thread_create /home/ryan/pkg/openldap/openldap/libraries/libldap_r/thr_posix.c:165:8 #2 0x5d2539 in slapd_daemon /home/ryan/pkg/openldap/openldap/servers/slapd/daemon.c:2898:8 #3 0x4e2e3e in main /home/ryan/pkg/openldap/openldap/servers/slapd/main.c:1018:7 #4 0x7f91fb641b44 in __libc_start_main /build/glibc-Ir_s5K/glibc-2.19/csu/libc-start.c:287 SUMMARY: AddressSanitizer: heap-buffer-overflow /home/ryan/pkg/openldap/openldap/libraries/liblutil/utils.c:317 lutil_strncopy Shadow bytes around the buggy address: 0x0c047fffc8d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fffc8e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fffc8f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fffc900: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fffc910: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa =>0x0c047fffc920: fa fa fa fa fa fa fa fa fa fa fa fa[fa]fa 00 02 0x0c047fffc930: fa fa fd fd fa fa fd fd fa fa fd fa fa fa 00 02 0x0c047fffc940: fa fa fd fd fa fa fd fa fa fa fd fd fa fa fd fd 0x0c047fffc950: fa fa fd fa fa fa fd fd fa fa fd fa fa fa fd fa 0x0c047fffc960: fa fa fd fd fa fa fd fa fa fa fd fa fa fa fd fa 0x0c047fffc970: fa fa fd fa fa fa fd fa fa fa fd fd fa fa fd fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap right redzone: fb Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc ASan internal: fe ==1998==ABORTING

1 0

Re: (ITS#8106) Retry pwrite operations in case of EINTR
by hyc＠symas.com 17 Apr '15

17 Apr '15

Dmytro Milinevskyy wrote: > Hello, > we've encountered this problem mainly on Android device. The kernel > sends a fake signal and the baking storage(flash) is not so fast. > I've noticed a typo in my patch for the macro DO_PWRITE in > mdb_env_init_meta. The test should be done for EINTR, not EINVAL. > Do you want me to resend the patch? Yes I already noticed that, so I wrote the patch myself instead of applying yours. Thank you for the context, that's good information. > > Thanks, > Dmytro > > On Fri, Apr 17, 2015 at 7:34 PM, Howard Chu <hyc(a)symas.com > <mailto:hyc@symas.com>> wrote: > > milinevskyy(a)gmail.com <mailto:milinevskyy@gmail.com> wrote: > > Full_Name: Dmytro Milinevskyy > Version: > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (92.132.131.166) > > > On linux systems it's common to have system calls interrupted > and restarted. > LMDB should retry pwrites to avoid "false" failures. > > > In practice, writes to a file are "fast" and will always write at > least one byte. But we've patched this as suggested, thanks. > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > > -- -- 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#8106) Retry pwrite operations in case of EINTR
by milinevskyy＠gmail.com 17 Apr '15

17 Apr '15

--047d7bd910b0d34afe0513f14c84 Content-Type: text/plain; charset=UTF-8 Hello, we've encountered this problem mainly on Android device. The kernel sends a fake signal and the baking storage(flash) is not so fast. I've noticed a typo in my patch for the macro DO_PWRITE in mdb_env_init_meta. The test should be done for EINTR, not EINVAL. Do you want me to resend the patch? Thanks, Dmytro On Fri, Apr 17, 2015 at 7:34 PM, Howard Chu <hyc(a)symas.com> wrote: > milinevskyy(a)gmail.com wrote: > >> Full_Name: Dmytro Milinevskyy >> Version: >> OS: Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (92.132.131.166) >> >> >> On linux systems it's common to have system calls interrupted and >> restarted. >> LMDB should retry pwrites to avoid "false" failures. >> > > In practice, writes to a file are "fast" and will always write at least > one byte. But we've patched this as suggested, thanks. > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > --047d7bd910b0d34afe0513f14c84 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div><div><div>Hello,<br>we've encountered this proble= m mainly on Android device. The kernel sends a fake signal and the baking s= torage(flash) is not so fast.<br>I've noticed a typo in my patch for th= e macro DO_PWRITE in mdb_env_init_meta. The test should be done for EINTR, = not EINVAL.<br></div>Do you want me to resend the patch?<br><br></div>Thank= s,<br></div>Dmytro<br></div><div class=3D"gmail_extra"><br><div class=3D"gm= ail_quote">On Fri, Apr 17, 2015 at 7:34 PM, Howard Chu <span dir=3D"ltr">&l= t;<a href=3D"mailto:hyc@symas.com" target=3D"_blank">hyc(a)symas.com</a>><= /span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8= ex;border-left:1px #ccc solid;padding-left:1ex"><a href=3D"mailto:milinevsk= yy(a)gmail.com" target=3D"_blank">milinevskyy(a)gmail.com</a> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Full_Name: Dmytro Milinevskyy<br> Version:<br> OS: Linux<br> URL: <a href=3D"ftp://ftp.openldap.org/incoming/" target=3D"_blank">ftp://f= tp.openldap.org/incoming/</a><br> Submission from: (NULL) (92.132.131.166)<br> <br> <br> On linux systems it's common to have system calls interrupted and resta= rted.<br> LMDB should retry pwrites to avoid "false" failures.<br> </blockquote> <br> In practice, writes to a file are "fast" and will always write at= least one byte. But we've patched this as suggested, thanks.<span clas= s=3D"HOEnZb"><font color=3D"#888888"><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" 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/" target=3D"_blank">http://highlandsun.com/hyc/</a><br> =C2=A0 Chief Architect, OpenLDAP=C2=A0 <a href=3D"http://www.openldap.org/p= roject/" target=3D"_blank">http://www.openldap.org/project/</a><br> </font></span></blockquote></div><br></div> --047d7bd910b0d34afe0513f14c84--

1 0

(ITS#8107) olcMemberOfDangling: error doesn't prevent adding nonexistent member to group
by rtandy＠sd63.bc.ca 17 Apr '15

17 Apr '15

Full_Name: Ryan Tandy Version: RE24 OS: Ubuntu URL: Submission from: (NULL) (142.31.146.2) $ git describe OPENLDAP_REL_ENG_2_4_40-208-gfd03ec0 $ ./configure --disable-bdb --disable-hdb --enable-memberof && make -j8 && sudo make STRIP= install [...] $ slapadd -Fconfig.d -n0 dn: cn=config objectClass%3ololcGlobal dn: cn=schema,cn=config objectClass: olcSchemaConfig include: file:///usr/local/etc/openldap/schema/core.ldif include: file:///usr/local/etc/openldap/schema/cosine.ldif dn: olcDatabase={1}mdb,cn=config objectClass: olcMdbConfig olcDbDirectory: data.d olcSuffix: dc=example,dc=com olcDbIndex: objectClass eq olcAccess: to * by dn="cn=admin,dc=example,dc=com" write by * read dn: olcOverlay=memberof,olcDatabase={1}mdb,cn=config objectClass: olcMemberOf olcMemberOfDangling: error $ slapadd -Fconfig.d dn: dc=example,dc=com objectClass: domain dn: cn=admin,dc=example,dc=com objectClass: organizationalRole objectClass: simpleSecurityObject userPassword: secret $ /usr/local/libexec/slapd -h ldap://:9000 -Fnfigig.d $ ldapadd -H ldap://:9000 -x -D cn=admin,dc=example,dc=com -w secret dn: cn=testgroup,dc=example,dc=com objectClass: groupOfNames member: cn=nonexistent adding new entry "cn=testgroup,dc=example,dc=com" ldap_add: Constraint violation (19) additional info: adding non-existing object as group member $ ldapsearch -H ldap://:9000 -x -b cn=testgroup,dc=example,dc=com # extended LDIF # # LDAPv3 # base <cn=testgroup,dc=example,dc=com> with scope subtree # filter: (objectclass=*) # requesting: ALL%%2# # search result search: 2 result: 32 No such object matchedDN: dc=example,dc=com # numResponses: 1 OK, that's fine. The new entry was rejected. $ ldapadd -H ldap://:9000 -x -D cn=admin,dc=example,dc=com -w secret dn: cn=testgroup,dc=example,dc=com objectClass: groupOfNames member: cn=admin,dc=example,dc=com adding new entry "cn=testgroup,dc=example,dc=com" dn: cn=testgroup,dc=example,dc=com changetype: modify add: member member: cn=nonexistent modifying entry "cn=testgroup,dc=example,dc=com" ldap_modify: Constraint violation (19) additional info: adding non-existing object as group member $ ldapsearch -H ldap://:9000 -x -b cn=testgroup,dc=example,dc=com # extended LDIF # # LDAPv3 # base <cn=testgroup,dc=example,dc=com> with scope subtree # filter: (objectclass=*) # requesting: ALL # # testgroup, example.com dn: cn=testgroup,dc=example,dc=com objectClass: groupOfNames member: cn=admin,dc=example,dc=com member: cn=nonexistent cn: testgroup # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 This is unexpected. The member addition was rejected, but somehow the modification went through anyway? Seems like something spooky is going on here... 903 9%9 send_ldap_result( op, rs ); (gdb) p rc $4 = 19 (gdb) n 55315ce0 send_ldap_result: conn=1001 op=2 p=3 55315ce0 send_ldap_response: msgid=3 tag=103 err=19 ber_flush2: 56 bytes to sd 12 1214 op->o_dn = save_dn; (gdb) p rc $5 = 32768 (gdb) p rs->sr_err $6 = 19D%D Am I reading that right, send_ldap_result is somehow overwriting rc in the caller? Happens at -O0 as well as -O2.

1 0

Re: (ITS#8106) Retry pwrite operations in case of EINTR
by hyc＠symas.com 17 Apr '15

17 Apr '15

milinevskyy(a)gmail.com wrote: > Full_Name: Dmytro Milinevskyy > Version: > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (92.132.131.166) > > > On linux systems it's common to have system calls interrupted and restarted. > LMDB should retry pwrites to avoid "false" failures. In practice, writes to a file are "fast" and will always write at least one byte. But we've patched this as suggested, thanks. -- -- 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#8106) Retry pwrite operations in case of EINTR
by milinevskyy＠gmail.com 17 Apr '15

17 Apr '15

--f46d04426b642829070513e7a46a Content-Type: text/plain; charset=UTF-8 Proposed patch in message body as issue tracker doesn't recognizes attachments: commit c9857a7c0df4448a14a2aa9f55850df5e830069e Author: Dmytro Milinevskyy <milinevskyy(a)gmail.com> Date: Fri Apr 17 10:41:26 2015 +0200 libmdb: retry write operation in case of interrupted system diff --git a/libraries/liblmdb/mdb.c b/libraries/liblmdb/mdb.c index a95c7cd..ed7f370 100644 --- a/libraries/liblmdb/mdb.c +++ b/libraries/liblmdb/mdb.c @@ -3236,6 +3236,7 @@ mdb_page_flush(MDB_txn *txn, int keep) /* Write up to MDB_COMMIT_PAGES dirty pages at a time. */ if (pos!=next_pos || n==MDB_COMMIT_PAGES || wsize+size>MAX_WRITE) { if (n) { + retry_write: /* Write previous page(s) */ #ifdef MDB_USE_PWRITEV wres = pwritev(env->me_fd, iov, n, wpos); @@ -3243,8 +3244,10 @@ mdb_page_flush(MDB_txn *txn, int keep) if (n == 1) { wres = pwrite(env->me_fd, iov[0].iov_base, wsize, wpos); } else { + retry_seek: if (lseek(env->me_fd, wpos, SEEK_SET) == -1) { rc = ErrCode(); + if (EINTR == rc) goto retry_seek; DPRINTF(("lseek: %s", strerror(rc))); return rc; } @@ -3254,6 +3257,7 @@ mdb_page_flush(MDB_txn *txn, int keep) if (wres != wsize) { if (wres < 0) { rc = ErrCode(); + if (EINTR == rc) goto retry_write; DPRINTF(("Write error: %s", strerror(rc))); } else { rc = EIO; /* TODO: Use which error code? */ @@ -3627,7 +3631,8 @@ mdb_env_init_meta(MDB_env *env, MDB_meta *meta) int len; #define DO_PWRITE(rc, fd, ptr, size, len, pos) do { \ len = pwrite(fd, ptr, size, pos); \ - rc = (len >= 0); } while(0) + if (len == -1 && EINVAL == ErrCode()) continue; \ + rc = (len >= 0); break; } while(1) #endif DPUTS("writing new meta page"); @@ -3735,6 +3740,7 @@ mdb_env_write_meta(MDB_txn *txn) /* Write to the SYNC fd */ mfd = (flags & (MDB_NOSYNC|MDB_NOMETASYNC)) ? env->me_fd : env->me_mfd; +retry_write: #ifdef _WIN32 { memset(&ov, 0, sizeof(ov)); @@ -3747,6 +3753,7 @@ mdb_env_write_meta(MDB_txn *txn) #endif if (rc != len) { rc = rc < 0 ? ErrCode() : EIO; + if (EINTR == rc) goto retry_write; DPUTS("write failed, disk error?"); /* On a failure, the pagecache still contains the new data. * Write some old data back, to prevent it from being used. On Fri, Apr 17, 2015 at 10:46 AM, Dmytro Milinevskyy <milinevskyy(a)gmail.com> wrote: > Proposed patch in attachment. > > On Fri, Apr 17, 2015 at 10:43 AM, <openldap-its(a)openldap.org> wrote: > >> >> *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** >> >> Thanks for your report to the OpenLDAP Issue Tracking System. Your >> report has been assigned the tracking number ITS#8106. >> >> One of our support engineers will look at your report in due course. >> Note that this may take some time because our support engineers >> are volunteers. They only work on OpenLDAP when they have spare >> time. >> >> If you need to provide additional information in regards to your >> issue report, you may do so by replying to this message. Note that >> any mail sent to openldap-its(a)openldap.org with (ITS#8106) >> in the subject will automatically be attached to the issue report. >> >> mailto:openldap-its@openldap.org?subject=(ITS#8106) >> >> You may follow the progress of this report by loading the following >> URL in a web browser: >> http://www.OpenLDAP.org/its/index.cgi?findid=8106 >> >> Please remember to retain your issue tracking number (ITS#8106) >> on any further messages you send to us regarding this report. If >> you don't then you'll just waste our time and yours because we >> won't be able to properly track the report. >> >> Please note that the Issue Tracking System is not intended to >> be used to seek help in the proper use of OpenLDAP Software. >> Such requests will be closed. >> >> OpenLDAP Software is user supported. >> http://www.OpenLDAP.org/support/ >> >> -------------- >> Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved. >> >> > --f46d04426b642829070513e7a46a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGRpdiBkaXI9Imx0ciI+UHJvcG9zZWQgcGF0Y2ggaW4gbWVzc2FnZSBib2R5IGFzIGlzc3VlIHRy YWNrZXIgZG9lc24mIzM5O3QgcmVjb2duaXplcyBhdHRhY2htZW50czo8YnI+PGJyPmNvbW1pdCBj OTg1N2E3YzBkZjQ0NDhhMTRhMmFhOWY1NTg1MGRmNWU4MzAwNjllPGJyPkF1dGhvcjogRG15dHJv IE1pbGluZXZza3l5ICZsdDs8YSBocmVmPSJtYWlsdG86bWlsaW5ldnNreXlAZ21haWwuY29tIj5t aWxpbmV2c2t5eUBnbWFpbC5jb208L2E+Jmd0Ozxicj5EYXRlOsKgwqAgRnJpIEFwciAxNyAxMDo0 MToyNiAyMDE1ICswMjAwPGJyPjxicj7CoMKgwqAgbGlibWRiOiByZXRyeSB3cml0ZSBvcGVyYXRp b24gaW4gY2FzZSBvZiBpbnRlcnJ1cHRlZCBzeXN0ZW08YnI+PGJyPmRpZmYgLS1naXQgYS9saWJy YXJpZXMvbGlibG1kYi9tZGIuYyBiL2xpYnJhcmllcy9saWJsbWRiL21kYi5jPGJyPmluZGV4IGE5 NWM3Y2QuLmVkN2YzNzAgMTAwNjQ0PGJyPi0tLSBhL2xpYnJhcmllcy9saWJsbWRiL21kYi5jPGJy PisrKyBiL2xpYnJhcmllcy9saWJsbWRiL21kYi5jPGJyPkBAIC0zMjM2LDYgKzMyMzYsNyBAQCBt ZGJfcGFnZV9mbHVzaChNREJfdHhuICp0eG4sIGludCBrZWVwKTxicj7CoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqAgLyogV3JpdGUgdXAgdG8gTURCX0NPTU1JVF9QQUdFUyBkaXJ0eSBwYWdl cyBhdCBhIHRpbWUuICovPGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBpZiAocG9z IT1uZXh0X3BvcyB8fCBuPT1NREJfQ09NTUlUX1BBR0VTIHx8IHdzaXplK3NpemUmZ3Q7TUFYX1dS SVRFKSB7PGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAg aWYgKG4pIHs8YnI+K8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHJldHJ5X3dyaXRlOjxicj7C oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoCAvKiBXcml0ZSBwcmV2aW91cyBwYWdlKHMpICovPGJyPsKgI2lmZGVmIE1EQl9VU0VfUFdS SVRFVjxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoCB3cmVzID0gcHdyaXRldihlbnYtJmd0O21lX2ZkLCBpb3YsIG4sIHdwb3Mp Ozxicj5AQCAtMzI0Myw4ICszMjQ0LDEwIEBAIG1kYl9wYWdlX2ZsdXNoKE1EQl90eG4gKnR4biwg aW50IGtlZXApPGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgIGlmIChuID09IDEpIHs8YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg IHdyZXMgPSBwd3JpdGUoZW52LSZndDttZV9mZCwgaW92WzBdLmlvdl9iYXNlLCB3c2l6ZSwgd3Bv cyk7PGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgIH0gZWxzZSB7PGJyPivCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHJldHJ5X3NlZWs6PGJyPsKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoCBpZiAobHNlZWsoZW52LSZndDttZV9mZCwgd3BvcywgU0VFS19TRVQpID09 IC0xKSB7PGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgcmMgPSBFcnJD b2RlKCk7PGJyPivCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBpZiAoRUlOVFIg PT0gcmMpIGdvdG8gcmV0cnlfc2Vlazs8YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoCBEUFJJTlRGKCgmcXVvdDtsc2VlazogJXMmcXVvdDssIHN0cmVycm9yKHJjKSkpOzxi cj7CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHJldHVybiByYzs8YnI+wqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgIH08YnI+QEAgLTMyNTQsNiArMzI1Nyw3IEBAIG1kYl9wYWdlX2Zs dXNoKE1EQl90eG4gKnR4biwgaW50IGtlZXApPGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIGlmICh3cmVzICE9IHdzaXplKSB7 PGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBpZiAod3JlcyAmbHQ7IDApIHs8YnI+wqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCByYyA9IEVyckNvZGUoKTs8YnI+K8KgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIGlmIChFSU5UUiA9PSByYykgZ290byByZXRyeV93 cml0ZTs8YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBEUFJJTlRGKCgm cXVvdDtXcml0ZSBlcnJvcjogJXMmcXVvdDssIHN0cmVycm9yKHJjKSkpOzxicj7CoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqAgfSBlbHNlIHs8YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoCByYyA9IEVJTzsgLyogVE9ETzogVXNlIHdoaWNoIGVycm9yIGNvZGU/ICovPGJyPkBAIC0z NjI3LDcgKzM2MzEsOCBAQCBtZGJfZW52X2luaXRfbWV0YShNREJfZW52ICplbnYsIE1EQl9tZXRh ICptZXRhKTxicj7CoMKgwqDCoMKgwqDCoCBpbnQgbGVuOzxicj7CoCNkZWZpbmUgRE9fUFdSSVRF KHJjLCBmZCwgcHRyLCBzaXplLCBsZW4sIHBvcykgZG8geyBcPGJyPsKgwqDCoMKgwqDCoMKgIGxl biA9IHB3cml0ZShmZCwgcHRyLCBzaXplLCBwb3MpO8KgwqDCoMKgwqDCoCBcPGJyPi3CoMKgwqDC oMKgwqAgcmMgPSAobGVuICZndDs9IDApOyB9IHdoaWxlKDApPGJyPivCoMKgwqDCoMKgwqAgaWYg KGxlbiA9PSAtMSAmYW1wOyZhbXA7IEVJTlZBTCA9PSBFcnJDb2RlKCkpIGNvbnRpbnVlOyBcPGJy PivCoMKgwqDCoMKgwqAgcmMgPSAobGVuICZndDs9IDApOyBicmVhazsgfSB3aGlsZSgxKTxicj7C oCNlbmRpZjxicj48YnI+wqDCoMKgwqDCoMKgwqAgRFBVVFMoJnF1b3Q7d3JpdGluZyBuZXcgbWV0 YSBwYWdlJnF1b3Q7KTs8YnI+QEAgLTM3MzUsNiArMzc0MCw3IEBAIG1kYl9lbnZfd3JpdGVfbWV0 YShNREJfdHhuICp0eG4pPGJyPjxicj7CoMKgwqDCoMKgwqDCoCAvKiBXcml0ZSB0byB0aGUgU1lO QyBmZCAqLzxicj7CoMKgwqDCoMKgwqDCoCBtZmQgPSAoZmxhZ3MgJmFtcDsgKE1EQl9OT1NZTkN8 TURCX05PTUVUQVNZTkMpKSA/IGVudi0mZ3Q7bWVfZmQgOiBlbnYtJmd0O21lX21mZDs8YnI+K3Jl dHJ5X3dyaXRlOjxicj7CoCNpZmRlZiBfV0lOMzI8YnI+wqDCoMKgwqDCoMKgwqAgezxicj7CoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgbWVtc2V0KCZhbXA7b3YsIDAsIHNpemVvZihvdikp Ozxicj5AQCAtMzc0Nyw2ICszNzUzLDcgQEAgbWRiX2Vudl93cml0ZV9tZXRhKE1EQl90eG4gKnR4 bik8YnI+wqAjZW5kaWY8YnI+wqDCoMKgwqDCoMKgwqAgaWYgKHJjICE9IGxlbikgezxicj7CoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgcmMgPSByYyAmbHQ7IDAgPyBFcnJDb2RlKCkgOiBF SU87PGJyPivCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIGlmIChFSU5UUiA9PSByYykgZ290 byByZXRyeV93cml0ZTs8YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIERQVVRTKCZx dW90O3dyaXRlIGZhaWxlZCwgZGlzayBlcnJvcj8mcXVvdDspOzxicj7CoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqAgLyogT24gYSBmYWlsdXJlLCB0aGUgcGFnZWNhY2hlIHN0aWxsIGNvbnRh aW5zIHRoZSBuZXcgZGF0YS48YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgKiBX cml0ZSBzb21lIG9sZCBkYXRhIGJhY2ssIHRvIHByZXZlbnQgaXQgZnJvbSBiZWluZyB1c2VkLjxi cj48L2Rpdj48ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+PGJyPjxkaXYgY2xhc3M9ImdtYWlsX3F1 b3RlIj5PbiBGcmksIEFwciAxNywgMjAxNSBhdCAxMDo0NiBBTSwgRG15dHJvIE1pbGluZXZza3l5 IDxzcGFuIGRpcj0ibHRyIj4mbHQ7PGEgaHJlZj0ibWFpbHRvOm1pbGluZXZza3l5QGdtYWlsLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPm1pbGluZXZza3l5QGdtYWlsLmNvbTwvYT4mZ3Q7PC9zcGFuPiB3 cm90ZTo8YnI+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAg MCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+PGRp diBkaXI9Imx0ciI+UHJvcG9zZWQgcGF0Y2ggaW4gYXR0YWNobWVudC48YnI+PC9kaXY+PGRpdiBj bGFzcz0iSE9FblpiIj48ZGl2IGNsYXNzPSJoNSI+PGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPjxi cj48ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gRnJpLCBBcHIgMTcsIDIwMTUgYXQgMTA6NDMg QU0sICA8c3BhbiBkaXI9Imx0ciI+Jmx0OzxhIGhyZWY9Im1haWx0bzpvcGVubGRhcC1pdHNAb3Bl bmxkYXAub3JnIiB0YXJnZXQ9Il9ibGFuayI+b3BlbmxkYXAtaXRzQG9wZW5sZGFwLm9yZzwvYT4m Z3Q7PC9zcGFuPiB3cm90ZTo8YnI+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHls ZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1s ZWZ0OjFleCI+PGJyPg0KKioqIFRISVMgSVMgQU4gQVVUT01BVElDQUxMWSBHRU5FUkFURUQgUkVQ TFkgKioqPGJyPg0KPGJyPg0KVGhhbmtzIGZvciB5b3VyIHJlcG9ydCB0byB0aGUgT3BlbkxEQVAg SXNzdWUgVHJhY2tpbmcgU3lzdGVtLsKgIFlvdXI8YnI+DQpyZXBvcnQgaGFzIGJlZW4gYXNzaWdu ZWQgdGhlIHRyYWNraW5nIG51bWJlciBJVFMjODEwNi48YnI+DQo8YnI+DQpPbmUgb2Ygb3VyIHN1 cHBvcnQgZW5naW5lZXJzIHdpbGwgbG9vayBhdCB5b3VyIHJlcG9ydCBpbiBkdWUgY291cnNlLjxi cj4NCk5vdGUgdGhhdCB0aGlzIG1heSB0YWtlIHNvbWUgdGltZSBiZWNhdXNlIG91ciBzdXBwb3J0 IGVuZ2luZWVyczxicj4NCmFyZSB2b2x1bnRlZXJzLsKgIFRoZXkgb25seSB3b3JrIG9uIE9wZW5M REFQIHdoZW4gdGhleSBoYXZlIHNwYXJlPGJyPg0KdGltZS48YnI+DQo8YnI+DQpJZiB5b3UgbmVl ZCB0byBwcm92aWRlIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gaW4gcmVnYXJkcyB0byB5b3VyPGJy Pg0KaXNzdWUgcmVwb3J0LCB5b3UgbWF5IGRvIHNvIGJ5IHJlcGx5aW5nIHRvIHRoaXMgbWVzc2Fn ZS7CoCBOb3RlIHRoYXQ8YnI+DQphbnkgbWFpbCBzZW50IHRvIDxhIGhyZWY9Im1haWx0bzpvcGVu bGRhcC1pdHNAb3BlbmxkYXAub3JnIiB0YXJnZXQ9Il9ibGFuayI+b3BlbmxkYXAtaXRzQG9wZW5s ZGFwLm9yZzwvYT4gd2l0aCAoSVRTIzgxMDYpPGJyPg0KaW4gdGhlIHN1YmplY3Qgd2lsbCBhdXRv bWF0aWNhbGx5IGJlIGF0dGFjaGVkIHRvIHRoZSBpc3N1ZSByZXBvcnQuPGJyPg0KPGJyPg0KwqAg wqAgwqAgwqAgbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpvcGVubGRhcC1pdHNAb3BlbmxkYXAub3Jn IiB0YXJnZXQ9Il9ibGFuayI+b3BlbmxkYXAtaXRzQG9wZW5sZGFwLm9yZzwvYT4/c3ViamVjdD0o SVRTIzgxMDYpPGJyPg0KPGJyPg0KWW91IG1heSBmb2xsb3cgdGhlIHByb2dyZXNzIG9mIHRoaXMg cmVwb3J0IGJ5IGxvYWRpbmcgdGhlIGZvbGxvd2luZzxicj4NClVSTCBpbiBhIHdlYiBicm93c2Vy Ojxicj4NCsKgIMKgIDxhIGhyZWY9Imh0dHA6Ly93d3cuT3BlbkxEQVAub3JnL2l0cy9pbmRleC5j Z2k/ZmluZGlkPTgxMDYiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vd3d3Lk9wZW5MREFQLm9yZy9p dHMvaW5kZXguY2dpP2ZpbmRpZD04MTA2PC9hPjxicj4NCjxicj4NClBsZWFzZSByZW1lbWJlciB0 byByZXRhaW4geW91ciBpc3N1ZSB0cmFja2luZyBudW1iZXIgKElUUyM4MTA2KTxicj4NCm9uIGFu eSBmdXJ0aGVyIG1lc3NhZ2VzIHlvdSBzZW5kIHRvIHVzIHJlZ2FyZGluZyB0aGlzIHJlcG9ydC7C oCBJZjxicj4NCnlvdSBkb24mIzM5O3QgdGhlbiB5b3UmIzM5O2xsIGp1c3Qgd2FzdGUgb3VyIHRp bWUgYW5kIHlvdXJzIGJlY2F1c2Ugd2U8YnI+DQp3b24mIzM5O3QgYmUgYWJsZSB0byBwcm9wZXJs eSB0cmFjayB0aGUgcmVwb3J0Ljxicj4NCjxicj4NClBsZWFzZSBub3RlIHRoYXQgdGhlIElzc3Vl IFRyYWNraW5nIFN5c3RlbSBpcyBub3QgaW50ZW5kZWQgdG88YnI+DQpiZSB1c2VkIHRvIHNlZWsg aGVscCBpbiB0aGUgcHJvcGVyIHVzZSBvZiBPcGVuTERBUCBTb2Z0d2FyZS48YnI+DQpTdWNoIHJl cXVlc3RzIHdpbGwgYmUgY2xvc2VkLjxicj4NCjxicj4NCk9wZW5MREFQIFNvZnR3YXJlIGlzIHVz ZXIgc3VwcG9ydGVkLjxicj4NCsKgIMKgIMKgIMKgIDxhIGhyZWY9Imh0dHA6Ly93d3cuT3BlbkxE QVAub3JnL3N1cHBvcnQvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3d3dy5PcGVuTERBUC5vcmcv c3VwcG9ydC88L2E+PGJyPg0KPGJyPg0KLS0tLS0tLS0tLS0tLS08YnI+DQpDb3B5cmlnaHQgMTk5 OC0yMDA3IFRoZSBPcGVuTERBUCBGb3VuZGF0aW9uLCBBbGwgUmlnaHRzIFJlc2VydmVkLjxicj4N Cjxicj4NCjwvYmxvY2txdW90ZT48L2Rpdj48YnI+PC9kaXY+DQo8L2Rpdj48L2Rpdj48L2Jsb2Nr cXVvdGU+PC9kaXY+PGJyPjwvZGl2Pg0K --f46d04426b642829070513e7a46a--

1 0

Re: (ITS#8106) Retry pwrite operations in case of EINTR
by milinevskyy＠gmail.com 17 Apr '15

17 Apr '15

--089e013d0c3883937b0513e79d1c Content-Type: multipart/alternative; boundary=089e013d0c3883936f0513e79d1a --089e013d0c3883936f0513e79d1a Content-Type: text/plain; charset=UTF-8 Proposed patch in attachment. On Fri, Apr 17, 2015 at 10:43 AM, <openldap-its(a)openldap.org> wrote: > > *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** > > Thanks for your report to the OpenLDAP Issue Tracking System. Your > report has been assigned the tracking number ITS#8106. > > One of our support engineers will look at your report in due course. > Note that this may take some time because our support engineers > are volunteers. They only work on OpenLDAP when they have spare > time. > > If you need to provide additional information in regards to your > issue report, you may do so by replying to this message. Note that > any mail sent to openldap-its(a)openldap.org with (ITS#8106) > in the subject will automatically be attached to the issue report. > > mailto:openldap-its@openldap.org?subject=(ITS#8106) > > You may follow the progress of this report by loading the following > URL in a web browser: > http://www.OpenLDAP.org/its/index.cgi?findid=8106 > > Please remember to retain your issue tracking number (ITS#8106) > on any further messages you send to us regarding this report. If > you don't then you'll just waste our time and yours because we > won't be able to properly track the report. > > Please note that the Issue Tracking System is not intended to > be used to seek help in the proper use of OpenLDAP Software. > Such requests will be closed. > > OpenLDAP Software is user supported. > http://www.OpenLDAP.org/support/ > > -------------- > Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved. > > --089e013d0c3883936f0513e79d1a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Proposed patch in attachment.<br></div><div class=3D"gmail= _extra"><br><div class=3D"gmail_quote">On Fri, Apr 17, 2015 at 10:43 AM, <= span dir=3D"ltr"><<a href=3D"mailto:openldap-its@openldap.org" target=3D= "_blank">openldap-its(a)openldap.org</a>></span> wrote:<br><blockquote cla= ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa= dding-left:1ex"><br> *** THIS IS AN AUTOMATICALLY GENERATED REPLY ***<br> <br> Thanks for your report to the OpenLDAP Issue Tracking System.=C2=A0 Your<br= > report has been assigned the tracking number ITS#8106.<br> <br> One of our support engineers will look at your report in due course.<br> Note that this may take some time because our support engineers<br> are volunteers.=C2=A0 They only work on OpenLDAP when they have spare<br> time.<br> <br> If you need to provide additional information in regards to your<br> issue report, you may do so by replying to this message.=C2=A0 Note that<br= > any mail sent to <a href=3D"mailto:openldap-its@openldap.org">openldap-its@= openldap.org</a> with (ITS#8106)<br> in the subject will automatically be attached to the issue report.<br> <br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 mailto:<a href=3D"mailto:openldap-its@openldap.= org">openldap-its(a)openldap.org</a>?subject=3D(ITS#8106)<br> <br> You may follow the progress of this report by loading the following<br> URL in a web browser:<br> =C2=A0 =C2=A0 <a href=3D"http://www.OpenLDAP.org/its/index.cgi?findid=3D810= 6" target=3D"_blank">http://www.OpenLDAP.org/its/index.cgi?findid=3D8106</a= ><br> <br> Please remember to retain your issue tracking number (ITS#8106)<br> on any further messages you send to us regarding this report.=C2=A0 If<br> you don't then you'll just waste our time and yours because we<br> won't be able to properly track the report.<br> <br> Please note that the Issue Tracking System is not intended to<br> be used to seek help in the proper use of OpenLDAP Software.<br> Such requests will be closed.<br> <br> OpenLDAP Software is user supported.<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"http://www.OpenLDAP.org/support/" ta= rget=3D"_blank">http://www.OpenLDAP.org/support/</a><br> <br> --------------<br> Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved.<br> <br> </blockquote></div><br></div> --089e013d0c3883936f0513e79d1a-- --089e013d0c3883937b0513e79d1c Content-Type: text/x-patch; charset=US-ASCII; name="0001-libmdb-retry-write-operation-in-case-of-interrupted-.patch" Content-Disposition: attachment; filename="0001-libmdb-retry-write-operation-in-case-of-interrupted-.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_i8lcpk680 RnJvbSBjOTg1N2E3YzBkZjQ0NDhhMTRhMmFhOWY1NTg1MGRmNWU4MzAwNjllIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBEbXl0cm8gTWlsaW5ldnNreXkgPG1pbGluZXZza3l5QGdtYWls LmNvbT4KRGF0ZTogRnJpLCAxNyBBcHIgMjAxNSAxMDo0MToyNiArMDIwMApTdWJqZWN0OiBbUEFU Q0hdIGxpYm1kYjogcmV0cnkgd3JpdGUgb3BlcmF0aW9uIGluIGNhc2Ugb2YgaW50ZXJydXB0ZWQg c3lzdGVtCgotLS0KIGxpYnJhcmllcy9saWJsbWRiL21kYi5jIHwgOSArKysrKysrKy0KIDEgZmls ZSBjaGFuZ2VkLCA4IGluc2VydGlvbnMoKyksIDEgZGVsZXRpb24oLSkKCmRpZmYgLS1naXQgYS9s aWJyYXJpZXMvbGlibG1kYi9tZGIuYyBiL2xpYnJhcmllcy9saWJsbWRiL21kYi5jCmluZGV4IGE5 NWM3Y2QuLmVkN2YzNzAgMTAwNjQ0Ci0tLSBhL2xpYnJhcmllcy9saWJsbWRiL21kYi5jCisrKyBi L2xpYnJhcmllcy9saWJsbWRiL21kYi5jCkBAIC0zMjM2LDYgKzMyMzYsNyBAQCBtZGJfcGFnZV9m bHVzaChNREJfdHhuICp0eG4sIGludCBrZWVwKQogCQkvKiBXcml0ZSB1cCB0byBNREJfQ09NTUlU X1BBR0VTIGRpcnR5IHBhZ2VzIGF0IGEgdGltZS4gKi8KIAkJaWYgKHBvcyE9bmV4dF9wb3MgfHwg bj09TURCX0NPTU1JVF9QQUdFUyB8fCB3c2l6ZStzaXplPk1BWF9XUklURSkgewogCQkJaWYgKG4p IHsKKyAgICAgICAgICAgICAgcmV0cnlfd3JpdGU6CiAJCQkJLyogV3JpdGUgcHJldmlvdXMgcGFn ZShzKSAqLwogI2lmZGVmIE1EQl9VU0VfUFdSSVRFVgogCQkJCXdyZXMgPSBwd3JpdGV2KGVudi0+ bWVfZmQsIGlvdiwgbiwgd3Bvcyk7CkBAIC0zMjQzLDggKzMyNDQsMTAgQEAgbWRiX3BhZ2VfZmx1 c2goTURCX3R4biAqdHhuLCBpbnQga2VlcCkKIAkJCQlpZiAobiA9PSAxKSB7CiAJCQkJCXdyZXMg PSBwd3JpdGUoZW52LT5tZV9mZCwgaW92WzBdLmlvdl9iYXNlLCB3c2l6ZSwgd3Bvcyk7CiAJCQkJ fSBlbHNlIHsKKwkJCQkgIHJldHJ5X3NlZWs6CiAJCQkJCWlmIChsc2VlayhlbnYtPm1lX2ZkLCB3 cG9zLCBTRUVLX1NFVCkgPT0gLTEpIHsKIAkJCQkJCXJjID0gRXJyQ29kZSgpOworCQkJCQkJaWYg KEVJTlRSID09IHJjKSBnb3RvIHJldHJ5X3NlZWs7CiAJCQkJCQlEUFJJTlRGKCgibHNlZWs6ICVz Iiwgc3RyZXJyb3IocmMpKSk7CiAJCQkJCQlyZXR1cm4gcmM7CiAJCQkJCX0KQEAgLTMyNTQsNiAr MzI1Nyw3IEBAIG1kYl9wYWdlX2ZsdXNoKE1EQl90eG4gKnR4biwgaW50IGtlZXApCiAJCQkJaWYg KHdyZXMgIT0gd3NpemUpIHsKIAkJCQkJaWYgKHdyZXMgPCAwKSB7CiAJCQkJCQlyYyA9IEVyckNv ZGUoKTsKKwkJCQkJCWlmIChFSU5UUiA9PSByYykgZ290byByZXRyeV93cml0ZTsKIAkJCQkJCURQ UklOVEYoKCJXcml0ZSBlcnJvcjogJXMiLCBzdHJlcnJvcihyYykpKTsKIAkJCQkJfSBlbHNlIHsK IAkJCQkJCXJjID0gRUlPOyAvKiBUT0RPOiBVc2Ugd2hpY2ggZXJyb3IgY29kZT8gKi8KQEAgLTM2 MjcsNyArMzYzMSw4IEBAIG1kYl9lbnZfaW5pdF9tZXRhKE1EQl9lbnYgKmVudiwgTURCX21ldGEg Km1ldGEpCiAJaW50IGxlbjsKICNkZWZpbmUgRE9fUFdSSVRFKHJjLCBmZCwgcHRyLCBzaXplLCBs ZW4sIHBvcykJZG8geyBcCiAJbGVuID0gcHdyaXRlKGZkLCBwdHIsIHNpemUsIHBvcyk7CVwKLQly YyA9IChsZW4gPj0gMCk7IH0gd2hpbGUoMCkKKwlpZiAobGVuID09IC0xICYmIEVJTlZBTCA9PSBF cnJDb2RlKCkpIGNvbnRpbnVlOyBcCisJcmMgPSAobGVuID49IDApOyBicmVhazsgfSB3aGlsZSgx KQogI2VuZGlmCiAKIAlEUFVUUygid3JpdGluZyBuZXcgbWV0YSBwYWdlIik7CkBAIC0zNzM1LDYg KzM3NDAsNyBAQCBtZGJfZW52X3dyaXRlX21ldGEoTURCX3R4biAqdHhuKQogCiAJLyogV3JpdGUg dG8gdGhlIFNZTkMgZmQgKi8KIAltZmQgPSAoZmxhZ3MgJiAoTURCX05PU1lOQ3xNREJfTk9NRVRB U1lOQykpID8gZW52LT5tZV9mZCA6IGVudi0+bWVfbWZkOworcmV0cnlfd3JpdGU6CiAjaWZkZWYg X1dJTjMyCiAJewogCQltZW1zZXQoJm92LCAwLCBzaXplb2Yob3YpKTsKQEAgLTM3NDcsNiArMzc1 Myw3IEBAIG1kYl9lbnZfd3JpdGVfbWV0YShNREJfdHhuICp0eG4pCiAjZW5kaWYKIAlpZiAocmMg IT0gbGVuKSB7CiAJCXJjID0gcmMgPCAwID8gRXJyQ29kZSgpIDogRUlPOworCQlpZiAoRUlOVFIg PT0gcmMpIGdvdG8gcmV0cnlfd3JpdGU7CiAJCURQVVRTKCJ3cml0ZSBmYWlsZWQsIGRpc2sgZXJy b3I/Iik7CiAJCS8qIE9uIGEgZmFpbHVyZSwgdGhlIHBhZ2VjYWNoZSBzdGlsbCBjb250YWlucyB0 aGUgbmV3IGRhdGEuCiAJCSAqIFdyaXRlIHNvbWUgb2xkIGRhdGEgYmFjaywgdG8gcHJldmVudCBp dCBmcm9tIGJlaW5nIHVzZWQuCi0tIAoyLjMuNQoK --089e013d0c3883937b0513e79d1c--

1 0

(ITS#8106) Retry pwrite operations in case of EINTR
by milinevskyy＠gmail.com 17 Apr '15

17 Apr '15

Full_Name: Dmytro Milinevskyy Version: OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (92.132.131.166) On linux systems it's common to have system calls interrupted and restarted. LMDB should retry pwrites to avoid "false" failures.

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