openldap-bugs

openldap-bugs@openldap.org

1 participants
21002 discussions

Re: (ITS#8892) ISC dhcpd cannot start TLS session to 389-DS after updating openldap rpm
by quanah＠symas.com 06 Aug '18

06 Aug '18

--On Monday, August 06, 2018 3:42 PM +0000 krejci(a)i3.cz wrote: > Full_Name: Mira Krejci > Version: 2.4.44-15 > OS: CentOS Linux release 7.5.1804 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (93.99.54.254) Hello, This is likely due to RedHat's customizations to the OpenLDAP libldap library. In their most recent builds, they switched from MozNSS to OpenSSL as the underlying TLS library and wrote their own custom bridging function for this change. It has apparently caused various problems for end users. I would suggest contacting RedHat or using an unmodified version of OpenLDAP. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8892) ISC dhcpd cannot start TLS session to 389-DS after updating openldap rpm
by michael＠stroeder.com 06 Aug '18

06 Aug '18

On 8/6/18 4:42 PM, krejci(a)i3.cz wrote: > ISC dhcp server cannot start TLS session to 389 Directory server after updating > openldap from 2.4.44-5 to newist version. > Error: Cannot start TLS session to 10.0.252.31:389: Connect error > > dhcpd version: 4.2.5-68 > 389-ds-base verson: 1.3.7.5-21 > > When I try manually copy old libraries (liblber, libldap, libslapi) back to > updated system, dhcpd works fine with TLS to 389-DS. > > We can disable TLS by "ldap-ssl off" option at /etc/dhcp/dhcpd.conf as a > workaround. The ITS is only for reporting bugs. Please post your questions on the openldap-technical mailing list: https://www.openldap.org/lists/mm/listinfo/openldap-technical Ciao, Michael.

1 0

(ITS#8892) ISC dhcpd cannot start TLS session to 389-DS after updating openldap rpm
by krejci＠i3.cz 06 Aug '18

06 Aug '18

Full_Name: Mira Krejci Version: 2.4.44-15 OS: CentOS Linux release 7.5.1804 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (93.99.54.254) ISC dhcp server cannot start TLS session to 389 Directory server after updating openldap from 2.4.44-5 to newist version. Error: Cannot start TLS session to 10.0.252.31:389: Connect error dhcpd version: 4.2.5-68 389-ds-base verson: 1.3.7.5-21 When I try manually copy old libraries (liblber, libldap, libslapi) back to updated system, dhcpd works fine with TLS to 389-DS. We can disable TLS by "ldap-ssl off" option at /etc/dhcp/dhcpd.conf as a workaround.

1 0

Re: (ITS#8891) LMDB fails to compile on latest Microsoft Visual Studio
by hyc＠symas.com 06 Aug '18

06 Aug '18

hrissan(a)mail.ru wrote: > Full_Name: Hrissan > Version: commit 86a90cad721cbdc0bb0a9c3bf15396f5c946ae95 > OS: Windows 7 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (5.44.169.206) > > > Sorry this seems to be the only way to report bug in LMDB. No need to apologize for using the documented mechanism. Thanks for the report, fixed now in mdb.master. > > In mdb.c line 55, 68, 77 > > typedef NTSTATUS WINAPI (NtCreateSectionFunc) > > Should be > > typedef NTSTATUS (WINAPI NtCreateSectionFunc) > > Visual Studio Community 2017 version 15.7.6 does not accept the incorrect > typedef any more. > > > -- -- 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#8891) LMDB fails to compile on latest Microsoft Visual Studio
by hrissan＠mail.ru 05 Aug '18

05 Aug '18

Full_Name: Hrissan Version: commit 86a90cad721cbdc0bb0a9c3bf15396f5c946ae95 OS: Windows 7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (5.44.169.206) Sorry this seems to be the only way to report bug in LMDB. In mdb.c line 55, 68, 77 typedef NTSTATUS WINAPI (NtCreateSectionFunc) Should be typedef NTSTATUS (WINAPI NtCreateSectionFunc) Visual Studio Community 2017 version 15.7.6 does not accept the incorrect typedef any more.

1 0

Re: (ITS#8650) EAGAIN from gnutls_handshake not respected
by subbarao＠computer.org 03 Aug '18

03 Aug '18

On 08/03/2018 12:09 PM, Ryan Tandy wrote: > Thanks for letting me know about this. This patch is running on quite > a few systems by now, I'm sorry the problem wasn't caught sooner. :/ No worries, thanks for responding so quickly on this! >> I'm wondering if there is a better way to handle EAGAIN returned from >> gnutls_handshake(), instead of doing a busywait as in ITS#8650, or my >> simplistic attempt at inserting a sleep() call which doesn't really >> seem to help. I'm wondering how the GnuTLS developers intend for >> people to use gnutls_handshake() properly, so as to gracefully handle >> sessions that involve long packets on the one hand, without opening >> up a vulnerability to chew up lots of system resources on the other >> hand. > > Right. I mean, this is how GnuTLS' own example shows to do it: > > https://gitlab.com/gnutls/gnutls/blob/master/doc/examples/ex-client-dtls.c#… > Hmm, that's a head-scratcher. It doesn't seem very effective to have a non-blocking I/O interface and then recommend wrapping it in a busywait loop :-) > We could place a limit on the number of iterations, though any such > limit would have to be arbitrary. > > There might be an asynchronous GnuTLS API that could be used to avoid > tying up slapd while this is going on. > > I will look at how some other GnuTLS servers deal with this... Cool, thanks Ryan. Regards, -Kartik

1 0

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

03 Aug '18

Hi Kartik, On Fri, Aug 03, 2018 at 11:19:06AM -0400, Kartik Subbarao wrote: >I'm running into a problem with slapd 2.4.46 hanging on Ubuntu 18.04, >which seems to be a side effect of the ITS#8650 patch: > >https://github.com/openldap/openldap/commit/7b5181da8cdd47a13041f9ee36fa959… > >slapd will run fine for a while, but during some periods of >high-traffic, it'll hang. It'll peg the CPU at 100% and won't respond >to any new LDAP connections. After some time, it'll resume working >again, but overall it's fairly unreliable. Thanks for letting me know about this. This patch is running on quite a few systems by now, I'm sorry the problem wasn't caught sooner. :/ >I'm wondering if there is a better way to handle EAGAIN returned from >gnutls_handshake(), instead of doing a busywait as in ITS#8650, or my >simplistic attempt at inserting a sleep() call which doesn't really >seem to help. I'm wondering how the GnuTLS developers intend for >people to use gnutls_handshake() properly, so as to gracefully handle >sessions that involve long packets on the one hand, without opening up >a vulnerability to chew up lots of system resources on the other hand. Right. I mean, this is how GnuTLS' own example shows to do it: https://gitlab.com/gnutls/gnutls/blob/master/doc/examples/ex-client-dtls.c#… We could place a limit on the number of iterations, though any such limit would have to be arbitrary. There might be an asynchronous GnuTLS API that could be used to avoid tying up slapd while this is going on. I will look at how some other GnuTLS servers deal with this...

1 0

Re: (ITS#8650) EAGAIN from gnutls_handshake not respected
by subbarao＠computer.org 03 Aug '18

03 Aug '18

Hi Ryan, I'm running into a problem with slapd 2.4.46 hanging on Ubuntu 18.04, which seems to be a side effect of the ITS#8650 patch: https://github.com/openldap/openldap/commit/7b5181da8cdd47a13041f9ee36fa959… slapd will run fine for a while, but during some periods of high-traffic, it'll hang. It'll peg the CPU at 100% and won't respond to any new LDAP connections. After some time, it'll resume working again, but overall it's fairly unreliable. strace on slapd during the hang shows that it's constantly making read() calls that return EAGAIN. After doing a gdb stack trace on slapd, I realized that these read() calls are happening as part of the busywait for loop in tlsg_session_accept() that repeatedly calls gnutls_handshake() when it gets EAGAIN. When slapd recovers from this hang state, the first message it prints is a TLS negotiation failure error on the culprit file descriptor. If I back out the ITS#8650 patch, the problem goes away. If I insert sleep(1) in the for loop, slapd no longer pegs the CPU at 100%, but it still becomes unresponsive during these high-traffic periods. I don't know what's happening during these high-traffic periods that causes the TLS negotiation to go astray. Unfortunately it's not easy to reproduce this problem outside of this production environment, given the diversity of clients running different OSes with various versions of SSL libraries. I'm wondering if there is a better way to handle EAGAIN returned from gnutls_handshake(), instead of doing a busywait as in ITS#8650, or my simplistic attempt at inserting a sleep() call which doesn't really seem to help. I'm wondering how the GnuTLS developers intend for people to use gnutls_handshake() properly, so as to gracefully handle sessions that involve long packets on the one hand, without opening up a vulnerability to chew up lots of system resources on the other hand. Regards, -Kartik

1 0

Re: (ITS#8890) Bug fix patches unbreaking the build on x32 systems
by tg＠debian.org 01 Aug '18

01 Aug '18

Hi, > Thanks. Most of these look OK, but the unconditional use of "long > long" instead of "long" will break on machines where "long long" is > not 64 bits. 64 bits is not the requirement for all those, but size of time_t. Each of these instances was changed from outputting a time_t with %ld (without cast to long) to outputting a time_t with %lld after being cast to long long. As long long is either the same size or greater than long, this cannot break any existing scenario. It merely fixes the scenario in which time_t is larger than long but fits into long long. (It also fixes the case where time_t is smaller than long, incidentally, as it was not cast, prior.) Actual bit sizes are of no import here due to the explicit casts, given that time_t can be of various sizes and, in constrast to e.g. size_t with its %zu specifier, does not have a printf specifier of its own. Fixing this is already common practice for me, as MirBSD/i386 is also a platform with 32-bit long and 64-bit time_t, and has been for 14 years and about five weeks or so. bye, //mirabilos -- When he found out that the m68k port was in a pretty bad shape, he did not, like many before him, shrug and move on; instead, he took it upon himself to start compiling things, just so he could compile his shell. How's that for dedication. -- Wouter, about my Debian/m68k revival

1 0

Re: (ITS#8890) Bug fix patches unbreaking the build on x32 systems
by hyc＠symas.com 01 Aug '18

01 Aug '18

tg(a)debian.org wrote: > Full_Name: mirabilos > Version: 2.4.46 > OS: Debian > URL: > Submission from: (NULL) (2a01:4f8:150:946c::42:3) >=20 >=20 > I=C3=A2=E2=82=AC=E2=84=A2ve just managed to unbreak the build of openld= ap on x32 > (basically amd64ilp32: a 64-bit x86 architecture using 32-bit > =C3=A2=E2=82=AC=C5=93long=C3=A2=E2=82=AC=C2=9D and pointers) by fixing = a couple of simple GCC warnings. Thanks. Most of these look OK, but the unconditional use of "long long" i= nstead of "long" will break on machines where "long long" is not 64 bits. >=20 > Original bugreport: https://bugs.debian.org/905237 >=20 > Please find the attached patches (pretty machinal, so not > copyright-relevant) and include them in your next release. > Thanks! >=20 > --- a/clients/tools/common.c > +++ b/clients/tools/common.c > @@ -2326,7 +2326,7 @@ void tool_print_ctrls( > /* known controls */ > for ( j =3D 0; tool_ctrl_response[j].oid !=3D NULL; j++ ) { > if ( strcmp( tool_ctrl_response[j].oid, ctrls[i]->ldctl_oid ) =3D=3D= 0 ) { > - if ( !tool_ctrl_response[j].mask & tool_type ) { > + if ( !(tool_ctrl_response[j].mask & tool_type) ) { > /* this control should not appear > * with this tool; warning? */ > } > --- a/servers/slapd/backend.c > +++ b/servers/slapd/backend.c > @@ -1500,7 +1500,7 @@ fe_acl_group( > * or if filter parsing fails. > * In the latter case, > * we should give up. */ > - if ( ludp->lud_filter !=3D NULL && ludp->lud_filter !=3D '\0') { > + if ( ludp->lud_filter !=3D NULL && ludp->lud_filter[0] !=3D '\0')= { > filter =3D str2filter_x( op, ludp->lud_filter ); > if ( filter =3D=3D NULL ) { > /* give up... */ > --- a/servers/slapd/overlays/constraint.c > +++ b/servers/slapd/overlays/constraint.c > @@ -446,7 +446,7 @@ constraint_cf_gen( ConfigArgs *c ) > } > =20 > if ( ap.restrict_lud->lud_attrs !=3D NULL ) { > - if ( ap.restrict_lud->lud_attrs[0] !=3D '\0' ) { > + if ( ap.restrict_lud->lud_attrs[0] !=3D NULL ) { > snprintf( c->cr_msg, sizeof( c->cr_msg ), > "%s %s: attrs not allowed in restrict URI %s\n", > c->argv[0], c->argv[1], arg); > --- a/servers/slapd/syntax.c > +++ b/servers/slapd/syntax.c > @@ -219,8 +219,8 @@ syn_add( > } > =20 > assert( (*lsei)->lsei_values !=3D NULL ); > - if ( (*lsei)->lsei_values[0] =3D=3D '\0' > - || (*lsei)->lsei_values[1] !=3D '\0' ) > + if ( (*lsei)->lsei_values[0] =3D=3D NULL > + || (*lsei)->lsei_values[1] !=3D NULL ) > { > Debug( LDAP_DEBUG_ANY, "syn_add(%s): exactly one substitute synta= x must be > present\n", > ssyn->ssyn_syn.syn_oid, 0, 0 ); > --- a/tests/progs/slapd-addel.c > +++ b/tests/progs/slapd-addel.c > @@ -173,7 +173,7 @@ main( int argc, char **argv ) > =20 > } > =20 > - if (( attrs =3D=3D NULL ) || ( *attrs =3D=3D '\0' )) { > + if (( attrs =3D=3D NULL ) || ( *attrs =3D=3D NULL )) { > =20 > fprintf( stderr, "%s: invalid attrs in file \"%s\".\n", > argv[0], filename ); > --- a/contrib/slapd-modules/smbk5pwd/smbk5pwd.c > +++ b/contrib/slapd-modules/smbk5pwd/smbk5pwd.c > @@ -605,7 +605,7 @@ static int smbk5pwd_exop_passwd( > keys[0].bv_val =3D ch_malloc( LDAP_PVT_INTTYPE_CHARS(long) ); > keys[0].bv_len =3D snprintf(keys[0].bv_val, > LDAP_PVT_INTTYPE_CHARS(long), > - "%ld", slap_get_time()); > + "%lld", (long long)slap_get_time()); > BER_BVZERO( &keys[1] ); > =09 > ml->sml_desc =3D ad_sambaPwdLastSet; > @@ -627,7 +627,7 @@ static int smbk5pwd_exop_passwd( > keys[0].bv_val =3D ch_malloc( LDAP_PVT_INTTYPE_CHARS(long) ); > keys[0].bv_len =3D snprintf(keys[0].bv_val, > LDAP_PVT_INTTYPE_CHARS(long), > - "%ld", slap_get_time() + pi->smb_must_change); > + "%lld", (long long)slap_get_time() + (long long)pi->smb_must_chan= ge); > BER_BVZERO( &keys[1] ); > =20 > ml->sml_desc =3D ad_sambaPwdMustChange; > @@ -650,7 +650,7 @@ static int smbk5pwd_exop_passwd( > keys[0].bv_val =3D ch_malloc( LDAP_PVT_INTTYPE_CHARS(long) ); > keys[0].bv_len =3D snprintf(keys[0].bv_val, > LDAP_PVT_INTTYPE_CHARS(long), > - "%ld", slap_get_time() + pi->smb_can_change); > + "%lld", (long long)slap_get_time() + (long long)pi->smb_can_chang= e); > BER_BVZERO( &keys[1] ); > =20 > ml->sml_desc =3D ad_sambaPwdCanChange; > --- a/libraries/libldap/os-ip.c > +++ b/libraries/libldap/os-ip.c > @@ -282,8 +282,8 @@ ldap_int_poll( > int rc; > =09 > =20 > - osip_debug(ld, "ldap_int_poll: fd: %d tm: %ld\n", > - s, tvp ? tvp->tv_sec : -1L, 0); > + osip_debug(ld, "ldap_int_poll: fd: %d tm: %lld\n", > + s, tvp ? (long long)tvp->tv_sec : -1LL, 0); > =20 > #ifdef HAVE_POLL > { > @@ -432,8 +432,8 @@ ldap_pvt_connect(LDAP *ld, ber_socket_t > opt_tv =3D &tv; > } > =20 > - osip_debug(ld, "ldap_pvt_connect: fd: %d tm: %ld async: %d\n", > - s, opt_tv ? tv.tv_sec : -1L, async); > + osip_debug(ld, "ldap_pvt_connect: fd: %d tm: %lld async: %d\n", > + s, opt_tv ? (long long)tv.tv_sec : -1LL, async); > =20 > if ( opt_tv && ldap_pvt_ndelay_on(ld, s) =3D=3D -1 ) > return ( -1 ); > --- a/libraries/libldap/os-local.c > +++ b/libraries/libldap/os-local.c > @@ -176,8 +176,8 @@ ldap_pvt_connect(LDAP *ld, ber_socket_t > opt_tv =3D &tv; > } > =20 > - oslocal_debug(ld, "ldap_connect_timeout: fd: %d tm: %ld async: %d\n", > - s, opt_tv ? tv.tv_sec : -1L, async); > + oslocal_debug(ld, "ldap_connect_timeout: fd: %d tm: %lld async: %d\n"= , > + s, opt_tv ? (long long)tv.tv_sec : -1LL, async); > =20 > if ( ldap_pvt_ndelay_on(ld, s) =3D=3D -1 ) return -1; > =20 > --- a/libraries/libldap/result.c > +++ b/libraries/libldap/result.c > @@ -264,8 +264,8 @@ wait4msg( > Debug( LDAP_DEBUG_TRACE, "wait4msg ld %p msgid %d (infinite timeout= )\n", > (void *)ld, msgid, 0 ); > } else { > - Debug( LDAP_DEBUG_TRACE, "wait4msg ld %p msgid %d (timeout %ld usec)= \n", > - (void *)ld, msgid, (long)timeout->tv_sec * 1000000 + timeout->tv_us= ec ); > + Debug( LDAP_DEBUG_TRACE, "wait4msg ld %p msgid %d (timeout %lld usec= )\n", > + (void *)ld, msgid, (long long)timeout->tv_sec * 1000000LL + timeout= ->tv_usec > ); > } > #endif /* LDAP_DEBUG */ > =20 > --- a/servers/slapd/back-ldap/bind.c > +++ b/servers/slapd/back-ldap/bind.c > @@ -3008,14 +3008,14 @@ ldap_back_conn2str( const ldapconn_base_ > } > =20 > if ( lc->lcb_create_time !=3D 0 ) { > - len =3D snprintf( tbuf, sizeof(tbuf), "%ld", lc->lcb_create_time ); > + len =3D snprintf( tbuf, sizeof(tbuf), "%lld", (long long)lc->lcb_cre= ate_time > ); > if ( ptr + sizeof(" created=3D") + len >=3D end ) return -1; > ptr =3D lutil_strcopy( ptr, " created=3D" ); > ptr =3D lutil_strcopy( ptr, tbuf ); > } > =20 > if ( lc->lcb_time !=3D 0 ) { > - len =3D snprintf( tbuf, sizeof(tbuf), "%ld", lc->lcb_time ); > + len =3D snprintf( tbuf, sizeof(tbuf), "%lld", (long long)lc->lcb_tim= e ); > if ( ptr + sizeof(" modified=3D") + len >=3D end ) return -1; > ptr =3D lutil_strcopy( ptr, " modified=3D" ); > ptr =3D lutil_strcopy( ptr, tbuf ); > --- a/servers/slapd/back-meta/config.c > +++ b/servers/slapd/back-meta/config.c > @@ -1277,8 +1277,8 @@ meta_back_cf_gen( ConfigArgs *c ) > if ( mc->mc_network_timeout =3D=3D 0 ) { > return 1; > } > - bv.bv_len =3D snprintf( c->cr_msg, sizeof(c->cr_msg), "%ld", > - mc->mc_network_timeout ); > + bv.bv_len =3D snprintf( c->cr_msg, sizeof(c->cr_msg), "%lld", > + (long long)mc->mc_network_timeout ); > bv.bv_val =3D c->cr_msg; > value_add_one( &c->rvalue_vals, &bv ); > break; > --- a/servers/slapd/overlays/dds.c > +++ b/servers/slapd/overlays/dds.c > @@ -417,7 +417,7 @@ dds_op_add( Operation *op, SlapReply *rs > assert( ttl <=3D DDS_RF2589_MAX_TTL ); > =20 > bv.bv_val =3D ttlbuf; > - bv.bv_len =3D snprintf( ttlbuf, sizeof( ttlbuf ), "%ld", ttl ); > + bv.bv_len =3D snprintf( ttlbuf, sizeof( ttlbuf ), "%lld", (long long= )ttl ); > assert( bv.bv_len < sizeof( ttlbuf ) ); > =20 > /* FIXME: apparently, values in op->ora_e are malloc'ed > @@ -695,7 +695,7 @@ dds_op_modify( Operation *op, SlapReply > goto done; > } > =20 > - bv_entryTtl.bv_len =3D snprintf( textbuf, sizeof( textbuf ), "%ld"= , entryTtl > ); > + bv_entryTtl.bv_len =3D snprintf( textbuf, sizeof( textbuf ), "%lld= ", (long > long)entryTtl ); > break; > =20 > default: > @@ -917,7 +917,7 @@ dds_response( Operation *op, SlapReply * > ttl =3D (ttl < 0) ? 0 : ttl; > assert( ttl <=3D DDS_RF2589_MAX_TTL ); > =20 > - len =3D snprintf( ttlbuf, sizeof(ttlbuf), "%ld", ttl ); > + len =3D snprintf( ttlbuf, sizeof(ttlbuf), "%lld", (long long)ttl ); > if ( len < 0 ) > { > goto done; > @@ -1177,7 +1177,7 @@ dds_op_extended( Operation *op, SlapRepl > ttlmod.sml_values =3D ttlvalues; > ttlmod.sml_numvals =3D 1; > ttlvalues[ 0 ].bv_val =3D ttlbuf; > - ttlvalues[ 0 ].bv_len =3D snprintf( ttlbuf, sizeof( ttlbuf ), "%ld",= ttl ); > + ttlvalues[ 0 ].bv_len =3D snprintf( ttlbuf, sizeof( ttlbuf ), "%lld"= , (long > long)ttl ); > BER_BVZERO( &ttlvalues[ 1 ] ); > =20 > /* the entryExpireTimestamp is added by modify */ > @@ -1205,8 +1205,8 @@ dds_op_extended( Operation *op, SlapRepl > rs->sr_rspoid =3D ch_strdup( slap_EXOP_REFRESH.bv_val ); > =20 > Log3( LDAP_DEBUG_TRACE, LDAP_LEVEL_INFO, > - "%s REFRESH dn=3D\"%s\" TTL=3D%ld\n", > - op->o_log_prefix, op->o_req_ndn.bv_val, ttl ); > + "%s REFRESH dn=3D\"%s\" TTL=3D%lld\n", > + op->o_log_prefix, op->o_req_ndn.bv_val, (long long)ttl ); > } > =20 > ber_free_buf( ber ); > --- a/servers/slapd/overlays/pcache.c > +++ b/servers/slapd/overlays/pcache.c > @@ -2728,8 +2728,8 @@ pc_bind_search( Operation *op, SlapReply > pbi->bi_flags |=3D BI_HASHED; > } else { > Debug( pcache_debug, "pc_bind_search: cache is stale, " > - "reftime: %ld, current time: %ld\n", > - pbi->bi_cq->bindref_time, op->o_time, 0 ); > + "reftime: %lld, current time: %lld\n", > + (long long)pbi->bi_cq->bindref_time, (long long)op->o_time, 0 ); > } > } else if ( pbi->bi_si ) { > /* This search result is going into the cache */ > @@ -3831,9 +3831,9 @@ pc_cf_gen( ConfigArgs *c ) > struct berval bv; > switch( c->type ) { > case PC_MAIN: > - bv.bv_len =3D snprintf( c->cr_msg, sizeof( c->cr_msg ), "%s %d %d %= d %ld", > + bv.bv_len =3D snprintf( c->cr_msg, sizeof( c->cr_msg ), "%s %d %d %= d %lld", > cm->db.bd_info->bi_type, cm->max_entries, cm->numattrsets, > - cm->num_entries_limit, cm->cc_period ); > + cm->num_entries_limit, (long long)cm->cc_period ); > bv.bv_val =3D c->cr_msg; > value_add_one( &c->rvalue_vals, &bv ); > break; > @@ -3875,12 +3875,12 @@ pc_cf_gen( ConfigArgs *c ) > /* HEADS-UP: always print all; > * if optional =3D=3D 0, ignore */ > bv.bv_len =3D snprintf( c->cr_msg, sizeof( c->cr_msg ), > - " %d %ld %ld %ld %ld", > + " %d %lld %lld %lld %lld", > temp->attr_set_index, > - temp->ttl, > - temp->negttl, > - temp->limitttl, > - temp->ttr ); > + (long long)temp->ttl, > + (long long)temp->negttl, > + (long long)temp->limitttl, > + (long long)temp->ttr ); > bv.bv_len +=3D temp->querystr.bv_len + 2; > bv.bv_val =3D ch_malloc( bv.bv_len+1 ); > ptr =3D bv.bv_val; > @@ -3897,9 +3897,9 @@ pc_cf_gen( ConfigArgs *c ) > for (temp=3Dqm->templates; temp; temp=3Dtemp->qmnext) { > if ( !temp->bindttr ) continue; > bv.bv_len =3D snprintf( c->cr_msg, sizeof( c->cr_msg ), > - " %d %ld %s ", > + " %d %lld %s ", > temp->attr_set_index, > - temp->bindttr, > + (long long)temp->bindttr, > ldap_pvt_scope2str( temp->bindscope )); > bv.bv_len +=3D temp->bindbase.bv_len + temp->bindftemp.bv_len + 4= ; > bv.bv_val =3D ch_malloc( bv.bv_len + 1 ); > --- a/servers/slapd/syncrepl.c > +++ b/servers/slapd/syncrepl.c > @@ -2395,8 +2395,8 @@ syncrepl_message_to_op( > op->o_callback =3D &cb; > slap_op_time( &op->o_time, &op->o_tincr ); > =20 > - Debug( LDAP_DEBUG_SYNC, "syncrepl_message_to_op: %s tid %x\n", > - si->si_ridtxt, op->o_tid, 0 ); > + Debug( LDAP_DEBUG_SYNC, "syncrepl_message_to_op: %s tid %lx\n", > + si->si_ridtxt, (unsigned long)op->o_tid, 0 ); > =20 > switch( op->o_tag ) { > case LDAP_REQ_ADD: > @@ -2905,8 +2905,8 @@ syncrepl_entry( > int freecsn =3D 1; > =20 > Debug( LDAP_DEBUG_SYNC, > - "syncrepl_entry: %s LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_%s) tid %x\n", > - si->si_ridtxt, syncrepl_state2str( syncstate ), op->o_tid ); > + "syncrepl_entry: %s LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_%s) tid %lx\n", > + si->si_ridtxt, syncrepl_state2str( syncstate ), (unsigned long)op->o= _tid ); > =20 > if (( syncstate =3D=3D LDAP_SYNC_PRESENT || syncstate =3D=3D LDAP_SY= NC_ADD ) ) { > if ( !si->si_refreshPresent && !si->si_refreshDone ) { >=20 >=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

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