Re: (ITS#4966) OpenLDAP 2.3.35 crashes on valsort overlay
by hyc＠symas.com
eagle(a)windlord.stanford.edu wrote:
> We've reproduced the crash and I have it in a crashed state in gdb right
> now.
Should be fixed now in valsort.c in HEAD.
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 1107294576 (LWP 32735)]
> valsort_modify (op=0x2aabaeae0058, rs=0x41ffef10) at valsort.c:455
> 455 for (i=0; !BER_BVISNULL( &ml->sml_values[i] ); i++) {
> (gdb) bt
> #0 valsort_modify (op=0x2aabaeae0058, rs=0x41ffef10) at valsort.c:455
> #1 0x0000000000478a2a in overlay_op_walk (op=0x2aabaeae0058, rs=0x41ffef10,
> which=op_modify, oi=0x2b240a786518, on=0x2b240a786cd8) at backover.c:498
> #2 0x0000000000478e65 in over_op_func (op=0x2aabaeae0058, rs=0x41ffef10,
> which=op_modify) at backover.c:560
> #3 0x000000000043c962 in fe_op_modify (op=0x2aabaeae0058, rs=0x41ffef10)
> at modify.c:395
> #4 0x000000000043d45a in do_modify (op=0x2aabaeae0058, rs=0x41ffef10)
> at modify.c:200
> #5 0x0000000000427af9 in connection_operation (ctx=Variable "ctx" is not available.
> ) at connection.c:1133
> #6 0x0000000000427fa4 in connection_read_thread (ctx=0x41fff060, argv=Variable "argv" is not available.
> )
> at connection.c:1261
> #7 0x00002b2408673894 in ldap_int_thread_pool_wrapper (xpool=0x2b2409d10058)
> at tpool.c:478
> #8 0x00002b24083ad9af in startMeUp () from /usr/local/lib/libhoard.so
> #9 0x00002b24090bfb55 in start_thread () from /lib/libpthread.so.0
> #10 0x00002b24092a07f0 in clone () from /lib/libc.so.6
> [...]
> (gdb) frame 0
> #0 valsort_modify (op=0x2aabaeae0058, rs=0x41ffef10) at valsort.c:455
> 455 for (i=0; !BER_BVISNULL( &ml->sml_values[i] ); i++) {
> (gdb) list
> 450 if ( ml->sml_desc == vi->vi_ad )
> 451 break;
> 452 }
> 453 if ( !ml )
> 454 continue;
> 455 for (i=0; !BER_BVISNULL( &ml->sml_values[i] ); i++) {
> 456 ptr = ber_bvchr(&ml->sml_values[i], '{' );
> 457 if ( !ptr ) {
> 458 Debug(LDAP_DEBUG_TRACE, "weight missing from attribute %s\n",
> 459 vi->vi_ad->ad_cname.bv_val, 0, 0);
> (gdb) print *ml
> $2 = {sml_mod = {sm_op = 1, sm_flags = 0, sm_desc = 0x2b2409a344d0, sm_type = {
> bv_len = 20, bv_val = 0x2aabaea1f8e9 "suorgcontactstanford"},
> sm_values = 0x0, sm_nvalues = 0x0}, sml_next = 0x2aabaeaf4770}
> (gdb) print i
> No symbol "i" in current context.
> (gdb) print ml->sml_mod.sm_values
> $3 = 0x0
>
> I'll leave it running in gdb so that I can find additional information for
> you as needed.
>
>
>
--
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
http://www.symas.com http://highlandsun.com/hyc
Symas: Premier OpenSource Development and Support
16 years
Re: (ITS#4966) OpenLDAP 2.3.35 crashes on valsort overlay
by eagle＠windlord.stanford.edu
Here are the logs of the connection that led to the crash. We think that
it may be attempting a delete after the last logged MOD, but so far we
haven't been able to get any more detailed information from the authors of
the application making the change.
May 24 14:34:01 ldap-test0 slapd[32729]: conn=13 op=0 BIND dn="" method=163
May 24 14:34:01 ldap-test0 slapd[32729]: conn=13 op=0 RESULT tag=97 err=14 text=
May 24 14:34:01 ldap-test0 slapd[32729]: conn=13 op=1 BIND dn="" method=163
May 24 14:34:01 ldap-test0 slapd[32729]: conn=13 op=1 RESULT tag=97 err=14 text=
May 24 14:34:01 ldap-test0 slapd[32729]: conn=13 op=2 BIND dn="" method=163
May 24 14:34:01 ldap-test0 slapd[32729]: conn=13 op=2 BIND authcid="service/slog-org(a)stanford.edu" authzid="service/slog-org(a)stanford.edu"
May 24 14:34:01 ldap-test0 slapd[32729]: conn=13 op=2 BIND dn="cn=slog-org,cn=service,cn=applications,dc=stanford,dc=edu" mech=GSSAPI ssf=56
May 24 14:34:01 ldap-test0 slapd[32729]: conn=13 op=2 RESULT tag=97 err=0 text=
May 24 14:34:01 ldap-test0 slapd[32729]: conn=13 op=3 SRCH base="" scope=0 deref=3 filter="(objectClass=*)"
May 24 14:34:01 ldap-test0 slapd[32729]: conn=13 op=3 SRCH attr=subschemasubentry
May 24 14:34:01 ldap-test0 slapd[32729]: conn=13 op=3 SEARCH RESULT tag=101 err=0 nentries=1 text=
May 24 14:34:01 ldap-test0 slapd[32729]: conn=13 op=4 SRCH base="cn=Subschema" scope=0 deref=3 filter="(objectClass=subschema)"
May 24 14:34:01 ldap-test0 slapd[32729]: conn=13 op=4 SRCH attr=objectClasses attributeTypes matchingRules ldapSyntaxes objectClass javaSerializedData javaClassName javaFactory javaCodeBase javaReferenceAddress javaClassNames javaRemoteLocation
May 24 14:34:01 ldap-test0 slapd[32729]: conn=13 op=4 SEARCH RESULT tag=101 err=0 nentries=1 text=
May 24 14:34:02 ldap-test0 slapd[32729]: conn=12 op=5 ABANDON msg=5
May 24 14:34:08 ldap-test0 slapd[32729]: conn=13 op=5 SRCH base="cn=organizations,dc=stanford,dc=edu" scope=0 deref=3 filter="(objectClass=*)"
May 24 14:34:08 ldap-test0 slapd[32729]: conn=13 op=5 SEARCH RESULT tag=101 err=0 nentries=1 text=
May 24 14:34:08 ldap-test0 slapd[32729]: conn=13 op=6 SRCH base="cn=organizations,dc=stanford,dc=edu" scope=1 deref=3 filter="(suRegID=dab33c07fe4f5bee9901a10446424016)"
May 24 14:34:08 ldap-test0 slapd[32729]: conn=13 op=6 SEARCH RESULT tag=101 err=0 nentries=1 text=
May 24 14:34:08 ldap-test0 slapd[32729]: conn=13 op=7 SRCH base="cn=organizations,dc=stanford,dc=edu" scope=0 deref=3 filter="(objectClass=*)"
May 24 14:34:08 ldap-test0 slapd[32729]: conn=13 op=7 SEARCH RESULT tag=101 err=0 nentries=1 text=
May 24 14:34:08 ldap-test0 slapd[32729]: conn=13 op=8 MOD dn="suRegID=dab33c07fe4f5bee9901a10446424016,cn=organizations,dc=stanford,dc=edu"
May 24 14:34:08 ldap-test0 slapd[32729]: conn=13 op=8 MOD attr=sugeneralid suseealsoorgregid suorgcontactstanford
May 24 14:34:09 ldap-test0 slapd[32729]: conn=13 op=8 RESULT tag=103 err=0 text=
May 24 14:34:11 ldap-test0 slapd[32729]: conn=13 op=9 SRCH base="cn=organizations,dc=stanford,dc=edu" scope=0 deref=3 filter="(objectClass=*)"
May 24 14:34:11 ldap-test0 slapd[32729]: conn=13 op=9 SEARCH RESULT tag=101 err=0 nentries=1 text=
May 24 14:34:11 ldap-test0 slapd[32729]: conn=13 op=10 SRCH base="cn=organizations,dc=stanford,dc=edu" scope=1 deref=3 filter="(suRegID=dab33c07fe4f5bee9901a10446424016)"
May 24 14:34:11 ldap-test0 slapd[32729]: conn=13 op=10 SEARCH RESULT tag=101 err=0 nentries=1 text=
May 24 14:34:12 ldap-test0 slapd[32729]: conn=13 op=11 SRCH base="cn=organizations,dc=stanford,dc=edu" scope=0 deref=3 filter="(objectClass=*)"
May 24 14:34:12 ldap-test0 slapd[32729]: conn=13 op=11 SEARCH RESULT tag=101 err=0 nentries=1 text=
May 24 14:34:12 ldap-test0 slapd[32729]: conn=13 op=12 SRCH base="cn=organizations,dc=stanford,dc=edu" scope=1 deref=3 filter="(suRegID=41559190986611d3acf6ab400b0baa77)"
May 24 14:34:12 ldap-test0 slapd[32729]: conn=13 op=12 SEARCH RESULT tag=101 err=0 nentries=1 text=
May 24 14:34:12 ldap-test0 slapd[32729]: conn=13 op=13 SRCH base="cn=organizations,dc=stanford,dc=edu" scope=0 deref=3 filter="(objectClass=*)"
May 24 14:34:12 ldap-test0 slapd[32729]: conn=13 op=13 SEARCH RESULT tag=101 err=0 nentries=1 text=
May 24 14:34:12 ldap-test0 slapd[32729]: conn=13 op=14 MOD dn="suRegID=41559190986611d3acf6ab400b0baa77,cn=organizations,dc=stanford,dc=edu"
May 24 14:34:12 ldap-test0 slapd[32729]: conn=13 op=14 MOD attr=suorgcontactlabelstanford eduorghomepageuri telephonenumber sugworgaddress facsimiletelephonenumber street postaladdress suorgcontactstanford suprintsection labeleduri sugeneralid
and then crash.
16 years
Re: (ITS#4966) OpenLDAP 2.3.35 crashes on valsort overlay
by eagle＠windlord.stanford.edu
We've reproduced the crash and I have it in a crashed state in gdb right
now.
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1107294576 (LWP 32735)]
valsort_modify (op=0x2aabaeae0058, rs=0x41ffef10) at valsort.c:455
455 for (i=0; !BER_BVISNULL( &ml->sml_values[i] ); i++) {
(gdb) bt
#0 valsort_modify (op=0x2aabaeae0058, rs=0x41ffef10) at valsort.c:455
#1 0x0000000000478a2a in overlay_op_walk (op=0x2aabaeae0058, rs=0x41ffef10,
which=op_modify, oi=0x2b240a786518, on=0x2b240a786cd8) at backover.c:498
#2 0x0000000000478e65 in over_op_func (op=0x2aabaeae0058, rs=0x41ffef10,
which=op_modify) at backover.c:560
#3 0x000000000043c962 in fe_op_modify (op=0x2aabaeae0058, rs=0x41ffef10)
at modify.c:395
#4 0x000000000043d45a in do_modify (op=0x2aabaeae0058, rs=0x41ffef10)
at modify.c:200
#5 0x0000000000427af9 in connection_operation (ctx=Variable "ctx" is not available.
) at connection.c:1133
#6 0x0000000000427fa4 in connection_read_thread (ctx=0x41fff060, argv=Variable "argv" is not available.
)
at connection.c:1261
#7 0x00002b2408673894 in ldap_int_thread_pool_wrapper (xpool=0x2b2409d10058)
at tpool.c:478
#8 0x00002b24083ad9af in startMeUp () from /usr/local/lib/libhoard.so
#9 0x00002b24090bfb55 in start_thread () from /lib/libpthread.so.0
#10 0x00002b24092a07f0 in clone () from /lib/libc.so.6
[...]
(gdb) frame 0
#0 valsort_modify (op=0x2aabaeae0058, rs=0x41ffef10) at valsort.c:455
455 for (i=0; !BER_BVISNULL( &ml->sml_values[i] ); i++) {
(gdb) list
450 if ( ml->sml_desc == vi->vi_ad )
451 break;
452 }
453 if ( !ml )
454 continue;
455 for (i=0; !BER_BVISNULL( &ml->sml_values[i] ); i++) {
456 ptr = ber_bvchr(&ml->sml_values[i], '{' );
457 if ( !ptr ) {
458 Debug(LDAP_DEBUG_TRACE, "weight missing from attribute %s\n",
459 vi->vi_ad->ad_cname.bv_val, 0, 0);
(gdb) print *ml
$2 = {sml_mod = {sm_op = 1, sm_flags = 0, sm_desc = 0x2b2409a344d0, sm_type = {
bv_len = 20, bv_val = 0x2aabaea1f8e9 "suorgcontactstanford"},
sm_values = 0x0, sm_nvalues = 0x0}, sml_next = 0x2aabaeaf4770}
(gdb) print i
No symbol "i" in current context.
(gdb) print ml->sml_mod.sm_values
$3 = 0x0
I'll leave it running in gdb so that I can find additional information for
you as needed.
16 years
Re: (ITS#4959) replica seg faults if syncrepl searchbase =""
by h.b.furuseth＠usit.uio.no
ali.pouya(a)free.fr writes:
> tls.c:2908: error: syntax error before '*' token
> tls.c: In function `find_oid':
> (...)
That's from ITS#4975: The code was broken for builds without TLS.
It's been fixed in HEAD. Does it work now?
--
Regards,
Hallvard
16 years
Re: AW: Documentation error in "ppolicy.schema" (ITS#4984)
by hyc＠symas.com
The text in this schema file comes directly from the IETF draft. It
should not be changed unless the draft itself has changed. This ITS
should be closed.
arnim.rupp(a)lhsystems.com wrote:
> hi Gavin,
>
> i think the sentence is ok, just in the wrong place. just move this sentence:
>
> # This attribute is not set
> # due to any actions specified by this document, it is typically set by
> # a password administrator after resetting a user's password.
>
> from "5.2.13 pwdMustChange" to "5.3.7 pwdReset".
>
> regards
> arnim rupp
>
> ---
> Arnim Rupp
>
> Lufthansa Systems Infratec GmbH
> Middleware Competence Center
> FRA AI/A-AM
>
> Am Weiher 24
> 65451 Kelsterbach
> Germany
>
> Raum/Room: 4.U1.07 LIC A
>
> Tel: +49-69-696-94944
> Fax: +49-69-696-93932
>
> Email: arnim.rupp(a)lhsystems.com
> Internet: www.lhsystems.com
>
> Sitz der Gesellschaft/Corporate Headquarters:
> Lufthansa Systems Infratec GmbH, Kelsterbach
>
> Registereintragung/Registration:
> Amtsgericht Darmstadt HRB 83851
>
> Vorsitzender des Aufsichtsrates/
> Chairman of the Supervisory Board:
> Dr. Gunter Küchler
>
> Geschäftsführung/Management:
> Dr. Hannes Pfister
>
>
>
>
>> -----Ursprüngliche Nachricht-----
>> Von: Gavin Henry [mailto:openldap-its@OpenLDAP.org]
>> Gesendet: Donnerstag, 24. Mai 2007 16:01
>> An: RUPP, ARNIM
>> Cc: openldap-its(a)OpenLDAP.org
>> Betreff: Re: Documentation error in "ppolicy.schema" (ITS#4984)
>>
>> Hi,
>>
>> Thank for your documentation report.
>>
>> How would you like it to be worded?
>>
>> Can you provide an example sentance?
>>
>> Thanks,
>>
>> Gavin.
>>
>
>
>
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
16 years
AW: Documentation error in "ppolicy.schema" (ITS#4984)
by arnim.rupp＠lhsystems.com
hi Gavin,
i think the sentence is ok, just in the wrong place. just move this sentence:
# This attribute is not set
# due to any actions specified by this document, it is typically set by
# a password administrator after resetting a user's password.
from "5.2.13 pwdMustChange" to "5.3.7 pwdReset".
regards
arnim rupp
---
Arnim Rupp
Lufthansa Systems Infratec GmbH
Middleware Competence Center
FRA AI/A-AM
Am Weiher 24
65451 Kelsterbach
Germany
Raum/Room: 4.U1.07 LIC A
Tel: +49-69-696-94944
Fax: +49-69-696-93932
Email: arnim.rupp(a)lhsystems.com
Internet: www.lhsystems.com
Sitz der Gesellschaft/Corporate Headquarters:
Lufthansa Systems Infratec GmbH, Kelsterbach
Registereintragung/Registration:
Amtsgericht Darmstadt HRB 83851
Vorsitzender des Aufsichtsrates/
Chairman of the Supervisory Board:
Dr. Gunter Küchler
Geschäftsführung/Management:
Dr. Hannes Pfister
> -----Ursprüngliche Nachricht-----
> Von: Gavin Henry [mailto:openldap-its@OpenLDAP.org]
> Gesendet: Donnerstag, 24. Mai 2007 16:01
> An: RUPP, ARNIM
> Cc: openldap-its(a)OpenLDAP.org
> Betreff: Re: Documentation error in "ppolicy.schema" (ITS#4984)
>
> Hi,
>
> Thank for your documentation report.
>
> How would you like it to be worded?
>
> Can you provide an example sentance?
>
> Thanks,
>
> Gavin.
>
16 years
(ITS#4984) Documentation error in "ppolicy.schema"
by arnim.rupp＠lhsystems.com
Full_Name: arnim rupp
Version: 2.3.35
OS: linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (87.106.39.109)
hello,
there's some wrong documentation in ./servers/slapd/schema/ppolicy.schema
in the "chapter" #5.2.13 pwdMustChange is the sentence:
# This attribute is not set
# due to any actions specified by this document, it is typically set by
# a password administrator after resetting a user's password.
this doesn't make any sense there since no admin would change a server-wide
setting after reseting a users password.
instead it is missing in the chapter "#5.3.7 pwdReset". without this sentence
it sounds like openldap automatically sets pwdReset (like good old netscape LDAP
does).
regards
arnim
16 years
Re: (ITS#4951) [contrib] RADIUS password module fixes
by richton＠nbcs.rutgers.edu
On Tue, 22 May 2007, Pierangelo Masarati wrote:
> If that's an issue, I have no problem in explicitly setting that pointer
> to NULL.
I got some more dbx time on this, and it looks like that's a workaround
for something that shouldn't be happening/needs to be fixed anyway.
config_filename is always NULL at dlopen() time, just as it should be.
Calling lock(&libradius_mutex) apparently overwrites config_filename, and
explicitly initializing to NULL somehow stops this from happening. I can't
see anything wrong with radius.c (as in HEAD), though; if anybody can
weigh in on this, it'd be much appreciated. I suppose it could still be a
compiler or a libthread bug, but I'm still missing a smoking gun here.
16 years
Re: (ITS#4981) Try -lpthread before -pthread
by kurt＠OpenLDAP.org
On May 23, 2007, at 10:16 PM, rra(a)stanford.edu wrote:
> libtool does not pass -pthread through
Our libtool does. But gcc might not do the right thing with it.
In that case, it's a gcc bug which should be reported to the gcc
folks.
I believe using -lpthread over -pthread will cause more problems
than its worth. That is, the problems caused by the missing link
on some platforms is not nearly as bad as the caused by using
-lc instead of -lc_r on other platforms.
-- Kurt
16 years
Re: (ITS#4982) link libldap_r explicitly with the threading libraries
by h.b.furuseth＠usit.uio.no
rra(a)stanford.edu writes:
> This issue, ITS#4982, is that no threading flags (not -pthread, not
> -lpthread, not anything) are passed into the final link line of libldap_r,
> as near as I can tell.
Right. grepping make >& make.out shows no thread switch in the command
line which builds libldap_r.so. Adding the ITS#4982 patch (and not
ITS#4981), I got 4 '-pthread's in a row, which should be enough:-)
--
Regards,
Hallvard
16 years
