Discussion:
list mechs bug in cyrus-sasl 2.1.22 and memory leak
(too old to reply)
Quanah Gibson-Mount
2008-01-24 08:25:19 UTC
Permalink
In playing on the Mac platform, I found there is a bug in the mechanism
listing code on both PPC and x86 Mac. From testsuite.c:

Testing sasl_listmech()...
[EXTERNAL,ANONYMOUS,ANONYMOUS,ANONYMOUS,CRAM-MD5,CRAM-MD5,CRAM-MD5,DIGEST-MD
5,DIGEST-MD5,DIGEST-MD5,GSSAPI,GSSAPI,GSSAPI,LOGIN,LOGIN,LOGIN,OTP,OTP,OTP,PLAIN,PLAIN,PLAIN]
Client mechlist:
[PLAIN,PLAIN,PLAIN,OTP,OTP,OTP,LOGIN,LOGIN,LOGIN,GSSAPI,GSSAPI,GSSAPI,DIGEST
-MD5,DIGEST-MD5,DIGEST-MD5,CRAM-MD5,CRAM-MD5,CRAM-MD5,ANONYMOUS,ANONYMOUS,ANONYMOUS,EXTERNAL]
We have the following mechs:
[PLAIN,PLAIN,PLAIN,LOGIN,LOGIN,LOGIN,GSSAPI,GSSAPI,GSSAPI,DIGEST-MD5,DIGEST-
MD5,DIGEST-MD5,CRAM-MD5,CRAM-MD5,CRAM-MD5,ANONYMOUS,ANONYMOUS,ANONYMOUS,EXTERNAL]
Currently Still Allocated:
302EE0 ( 360) 00 00 00 00 00 00 00 00 00 00 00 00 ...
302EA0 ( 20) 01 00 00 00 00 00 00 00 D0 '.' '0' 00 ...
302CC0 ( 360) 00 00 00 00 00 00 00 00 00 00 00 00 ...
302C80 ( 20) 01 00 00 00 00 00 00 00 B0 ',' '0' 00 ...
300AE0 ( 20) 00 00 00 00 00 00 00 00 00 00 00 00 ...
300A40 ( 20) 00 00 00 00 00 00 00 00 00 00 00 00 ...
Failed with: memory error


Does anyone know of a fix for this? I can't imagine I'm the first to hit
it. It's causing problems with OpenLDAP, as after a while the server will
crash, and the stack trace on the core points to this being the issue.

Thanks!

--Quanah

--

Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
Ken Murchison
2008-01-24 18:17:30 UTC
Permalink
I don't have access to a Mac to play with, but I can't reproduce this on
my Linux dev box. I'm curious why each of the plugin mechs is listed 3
times.
Post by Quanah Gibson-Mount
In playing on the Mac platform, I found there is a bug in the mechanism
Testing sasl_listmech()...
[EXTERNAL,ANONYMOUS,ANONYMOUS,ANONYMOUS,CRAM-MD5,CRAM-MD5,CRAM-MD5,DIGEST-MD
5,DIGEST-MD5,DIGEST-MD5,GSSAPI,GSSAPI,GSSAPI,LOGIN,LOGIN,LOGIN,OTP,OTP,OTP,PLAIN,PLAIN,PLAIN]
[PLAIN,PLAIN,PLAIN,OTP,OTP,OTP,LOGIN,LOGIN,LOGIN,GSSAPI,GSSAPI,GSSAPI,DIGEST
-MD5,DIGEST-MD5,DIGEST-MD5,CRAM-MD5,CRAM-MD5,CRAM-MD5,ANONYMOUS,ANONYMOUS,ANONYMOUS,EXTERNAL]
[PLAIN,PLAIN,PLAIN,LOGIN,LOGIN,LOGIN,GSSAPI,GSSAPI,GSSAPI,DIGEST-MD5,DIGEST-
MD5,DIGEST-MD5,CRAM-MD5,CRAM-MD5,CRAM-MD5,ANONYMOUS,ANONYMOUS,ANONYMOUS,EXTERNAL]
302EE0 ( 360) 00 00 00 00 00 00 00 00 00 00 00 00 ...
302EA0 ( 20) 01 00 00 00 00 00 00 00 D0 '.' '0' 00 ...
302CC0 ( 360) 00 00 00 00 00 00 00 00 00 00 00 00 ...
302C80 ( 20) 01 00 00 00 00 00 00 00 B0 ',' '0' 00 ...
300AE0 ( 20) 00 00 00 00 00 00 00 00 00 00 00 00 ...
300A40 ( 20) 00 00 00 00 00 00 00 00 00 00 00 00 ...
Failed with: memory error
Does anyone know of a fix for this? I can't imagine I'm the first to
hit it. It's causing problems with OpenLDAP, as after a while the
server will crash, and the stack trace on the core points to this being
the issue.
Thanks!
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
--
Kenneth Murchison
Systems Programmer
Project Cyrus Developer/Maintainer
Carnegie Mellon University
Quanah Gibson-Mount
2008-01-24 18:27:16 UTC
Permalink
Me too. This problem only occurs on the Mac (PPC or i386), and does not
show up on linux at all. I'm guessing this is due to the Mac having a
slightly different source tree. I've verified it goes back as far as
2.1.18.

The multi-listed mechanisms was what pointed me in the direction of SASL,
as that was what showed up in the OpenLDAP backtrace.

--Quanah

--On Thursday, January 24, 2008 1:05 PM -0500 Ken Murchison
Post by Ken Murchison
I don't have access to a Mac to play with, but I can't reproduce this on
my Linux dev box. I'm curious why each of the plugin mechs is listed 3
times.
Post by Quanah Gibson-Mount
In playing on the Mac platform, I found there is a bug in the mechanism
Testing sasl_listmech()...
[EXTERNAL,ANONYMOUS,ANONYMOUS,ANONYMOUS,CRAM-MD5,CRAM-MD5,CRAM-MD5,DIGES
T-MD
5,DIGEST-MD5,DIGEST-MD5,GSSAPI,GSSAPI,GSSAPI,LOGIN,LOGIN,LOGIN,OTP,OTP,O
TP,PLAIN,PLAIN,PLAIN]
[PLAIN,PLAIN,PLAIN,OTP,OTP,OTP,LOGIN,LOGIN,LOGIN,GSSAPI,GSSAPI,GSSAPI,DI
GEST
-MD5,DIGEST-MD5,DIGEST-MD5,CRAM-MD5,CRAM-MD5,CRAM-MD5,ANONYMOUS,ANONYMOU
S,ANONYMOUS,EXTERNAL]
[PLAIN,PLAIN,PLAIN,LOGIN,LOGIN,LOGIN,GSSAPI,GSSAPI,GSSAPI,DIGEST-MD5,DIG
EST-
MD5,DIGEST-MD5,CRAM-MD5,CRAM-MD5,CRAM-MD5,ANONYMOUS,ANONYMOUS,ANONYMOUS,
EXTERNAL]
302EE0 ( 360) 00 00 00 00 00 00 00 00 00 00 00 00
... 302EA0 ( 20) 01 00 00 00 00 00 00 00 D0 '.' '0'
00 ... 302CC0 ( 360) 00 00 00 00 00 00 00 00 00 00
00 00 ... 302C80 ( 20) 01 00 00 00 00 00 00 00 B0
',' '0' 00 ... 300AE0 ( 20) 00 00 00 00 00 00 00 00
00 00 00 00 ... 300A40 ( 20) 00 00 00 00 00 00 00
00 00 00 00 00 ... Failed with: memory error
Does anyone know of a fix for this? I can't imagine I'm the first to
hit it. It's causing problems with OpenLDAP, as after a while the
server will crash, and the stack trace on the core points to this being
the issue.
Thanks!
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
--
Kenneth Murchison
Systems Programmer
Project Cyrus Developer/Maintainer
Carnegie Mellon University
--

Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
Ken Murchison
2008-01-24 18:27:39 UTC
Permalink
I'll see if I can find a Mac on which to test the stock SASL source. If
Apple is modifying our source code, then you may have to take this up
with them.
Post by Quanah Gibson-Mount
Me too. This problem only occurs on the Mac (PPC or i386), and does not
show up on linux at all. I'm guessing this is due to the Mac having a
slightly different source tree. I've verified it goes back as far as
2.1.18.
The multi-listed mechanisms was what pointed me in the direction of
SASL, as that was what showed up in the OpenLDAP backtrace.
--Quanah
--On Thursday, January 24, 2008 1:05 PM -0500 Ken Murchison
Post by Ken Murchison
I don't have access to a Mac to play with, but I can't reproduce this on
my Linux dev box. I'm curious why each of the plugin mechs is listed 3
times.
Post by Quanah Gibson-Mount
In playing on the Mac platform, I found there is a bug in the mechanism
Testing sasl_listmech()...
[EXTERNAL,ANONYMOUS,ANONYMOUS,ANONYMOUS,CRAM-MD5,CRAM-MD5,CRAM-MD5,DIGES
T-MD
5,DIGEST-MD5,DIGEST-MD5,GSSAPI,GSSAPI,GSSAPI,LOGIN,LOGIN,LOGIN,OTP,OTP,O
TP,PLAIN,PLAIN,PLAIN]
[PLAIN,PLAIN,PLAIN,OTP,OTP,OTP,LOGIN,LOGIN,LOGIN,GSSAPI,GSSAPI,GSSAPI,DI
GEST
-MD5,DIGEST-MD5,DIGEST-MD5,CRAM-MD5,CRAM-MD5,CRAM-MD5,ANONYMOUS,ANONYMOU
S,ANONYMOUS,EXTERNAL]
[PLAIN,PLAIN,PLAIN,LOGIN,LOGIN,LOGIN,GSSAPI,GSSAPI,GSSAPI,DIGEST-MD5,DIG
EST-
MD5,DIGEST-MD5,CRAM-MD5,CRAM-MD5,CRAM-MD5,ANONYMOUS,ANONYMOUS,ANONYMOUS,
EXTERNAL]
302EE0 ( 360) 00 00 00 00 00 00 00 00 00 00 00 00
... 302EA0 ( 20) 01 00 00 00 00 00 00 00 D0 '.' '0'
00 ... 302CC0 ( 360) 00 00 00 00 00 00 00 00 00 00
00 00 ... 302C80 ( 20) 01 00 00 00 00 00 00 00 B0
',' '0' 00 ... 300AE0 ( 20) 00 00 00 00 00 00 00 00
00 00 00 00 ... 300A40 ( 20) 00 00 00 00 00 00 00
00 00 00 00 00 ... Failed with: memory error
Does anyone know of a fix for this? I can't imagine I'm the first to
hit it. It's causing problems with OpenLDAP, as after a while the
server will crash, and the stack trace on the core points to this being
the issue.
Thanks!
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
--
Kenneth Murchison
Systems Programmer
Project Cyrus Developer/Maintainer
Carnegie Mellon University
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
--
Kenneth Murchison
Systems Programmer
Project Cyrus Developer/Maintainer
Carnegie Mellon University
Quanah Gibson-Mount
2008-01-24 18:40:24 UTC
Permalink
The problem does not occur with the Mac system sasl library. It only
occurs with stock builds of cyrus-sasl. I.e., Apple's fixed the issue
apparently, but their source is very heavily modified, I've just begun
looking into it. They also are using the rather old 2.1.18, and I need
2.1.22. ;) The same issues with a stock 2.1.18 build as well.


Using 2.1.22 stock build:

build-mac:~/sasl build$ gcc -I/Users/build/sasl
-I/opt/zimbra/cyrus-sasl/include/sasl -L/opt/zimbra/cyrus-sasl/lib -lsasl2
testsuite.c

build-mac:~/sasl build$ ./a.out
Testing sasl_listmech()...
[EXTERNAL,ANONYMOUS,ANONYMOUS,ANONYMOUS,CRAM-MD5,CRAM-MD5,CRAM-MD5,DIGEST-MD
5,DIGEST-MD5,DIGEST-MD5,GSSAPI,GSSAPI,GSSAPI,LOGIN,LOGIN,LOGIN,OTP,OTP,OTP,PLAIN,PLAIN,PLAIN]
Client mechlist:
[PLAIN,PLAIN,PLAIN,OTP,OTP,OTP,LOGIN,LOGIN,LOGIN,GSSAPI,GSSAPI,GSSAPI,DIGEST
-MD5,DIGEST-MD5,DIGEST-MD5,CRAM-MD5,CRAM-MD5,CRAM-MD5,ANONYMOUS,ANONYMOUS,ANONYMOUS,EXTERNAL]
We have the following mechs:
[PLAIN,PLAIN,PLAIN,LOGIN,LOGIN,LOGIN,GSSAPI,GSSAPI,GSSAPI,DIGEST-MD5,DIGEST-
MD5,DIGEST-MD5,CRAM-MD5,CRAM-MD5,CRAM-MD5,ANONYMOUS,ANONYMOUS,ANONYMOUS,EXTERNAL]
Currently Still Allocated:
502BF0 ( 360) 00 00 00 00 00 00 00 00 00 00 00 00 ...
502BB0 ( 20) 00 00 00 01 00 00 00 00 00 'P' '+' E0 ...
5029D0 ( 360) 00 00 00 00 00 00 00 00 00 00 00 00 ...
502990 ( 20) 00 00 00 01 00 00 00 00 00 'P' ')' C0 ...
500B10 ( 20) 00 00 00 00 00 00 00 00 00 00 00 00 ...
500A70 ( 20) 00 00 00 00 00 00 00 00 00 00 00 00 ...
Failed with: memory error



Using the system SASL library instead:

build-mac:~/sasl build$ gcc -I/Users/build/sasl
-I/opt/zimbra/cyrus-sasl/include/sasl -L/usr/lib -lsasl2 testsuite.c

Testing sasl_listmech()...
[EXTERNAL,APOP,DHX,WEBDAV-DIGEST,ANONYMOUS,CRAM-MD5,DIGEST-MD5,GSSAPI,LOGIN,
NTLM,OTP,PLAIN,MS-CHAPv2,SMB-LAN-MANAGER,SMB-NT,SMB-NTLMv2]
Client mechlist:
[SMB-NTLMv2,SMB-NT,SMB-LAN-MANAGER,MS-CHAPv2,PLAIN,OTP,NTLM,LOGIN,GSSAPI,DIG
EST-MD5,CRAM-MD5,ANONYMOUS,WEBDAV-DIGEST,DHX,APOP,EXTERNAL]
We have the following mechs:
[SMB-NTLMv2,SMB-NT,SMB-LAN-MANAGER,MS-CHAPv2,PLAIN,OTP,NTLM,LOGIN,GSSAPI,DIG
EST-MD5,CRAM-MD5,ANONYMOUS,WEBDAV-DIGEST,DHX,APOP,EXTERNAL]
All memory accounted for!
Testing sasl_listmech()... ok


--Quanah

--On Thursday, January 24, 2008 1:20 PM -0500 Ken Murchison
Post by Ken Murchison
I'll see if I can find a Mac on which to test the stock SASL source. If
Apple is modifying our source code, then you may have to take this up
with them.
Post by Quanah Gibson-Mount
Me too. This problem only occurs on the Mac (PPC or i386), and does not
show up on linux at all. I'm guessing this is due to the Mac having a
slightly different source tree. I've verified it goes back as far as
2.1.18.
The multi-listed mechanisms was what pointed me in the direction of
SASL, as that was what showed up in the OpenLDAP backtrace.
--Quanah
--On Thursday, January 24, 2008 1:05 PM -0500 Ken Murchison
Post by Ken Murchison
I don't have access to a Mac to play with, but I can't reproduce this on
my Linux dev box. I'm curious why each of the plugin mechs is listed 3
times.
Post by Quanah Gibson-Mount
In playing on the Mac platform, I found there is a bug in the mechanism
Testing sasl_listmech()...
[EXTERNAL,ANONYMOUS,ANONYMOUS,ANONYMOUS,CRAM-MD5,CRAM-MD5,CRAM-MD5,DIG
ES T-MD
5,DIGEST-MD5,DIGEST-MD5,GSSAPI,GSSAPI,GSSAPI,LOGIN,LOGIN,LOGIN,OTP,OTP
,O TP,PLAIN,PLAIN,PLAIN]
[PLAIN,PLAIN,PLAIN,OTP,OTP,OTP,LOGIN,LOGIN,LOGIN,GSSAPI,GSSAPI,GSSAPI,
DI GEST
-MD5,DIGEST-MD5,DIGEST-MD5,CRAM-MD5,CRAM-MD5,CRAM-MD5,ANONYMOUS,ANONYM
OU S,ANONYMOUS,EXTERNAL]
[PLAIN,PLAIN,PLAIN,LOGIN,LOGIN,LOGIN,GSSAPI,GSSAPI,GSSAPI,DIGEST-MD5,D
IG EST-
MD5,DIGEST-MD5,CRAM-MD5,CRAM-MD5,CRAM-MD5,ANONYMOUS,ANONYMOUS,ANONYMOU
S, EXTERNAL]
302EE0 ( 360) 00 00 00 00 00 00 00 00 00 00 00 00
... 302EA0 ( 20) 01 00 00 00 00 00 00 00 D0 '.' '0'
00 ... 302CC0 ( 360) 00 00 00 00 00 00 00 00 00 00
00 00 ... 302C80 ( 20) 01 00 00 00 00 00 00 00 B0
',' '0' 00 ... 300AE0 ( 20) 00 00 00 00 00 00 00 00
00 00 00 00 ... 300A40 ( 20) 00 00 00 00 00 00 00
00 00 00 00 00 ... Failed with: memory error
Does anyone know of a fix for this? I can't imagine I'm the first to
hit it. It's causing problems with OpenLDAP, as after a while the
server will crash, and the stack trace on the core points to this being
the issue.
Thanks!
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
--
Kenneth Murchison
Systems Programmer
Project Cyrus Developer/Maintainer
Carnegie Mellon University
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
--
Kenneth Murchison
Systems Programmer
Project Cyrus Developer/Maintainer
Carnegie Mellon University
--

Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
Quanah Gibson-Mount
2008-01-29 21:02:26 UTC
Permalink
--On Thursday, January 24, 2008 10:32 AM -0800 Quanah Gibson-Mount
Post by Quanah Gibson-Mount
The problem does not occur with the Mac system sasl library. It only
occurs with stock builds of cyrus-sasl. I.e., Apple's fixed the issue
apparently, but their source is very heavily modified, I've just begun
looking into it. They also are using the rather old 2.1.18, and I need
2.1.22. ;) The same issues with a stock 2.1.18 build as well.
This appears to be a problem in the way that the plugins are loaded with
add_plugin.

My cyrus-sasl/lib/sasl2/ directory had:

build-mac-x86:/opt/zimbra/cyrus-sasl/lib/sasl2 root# ls
libanonymous.2.0.22.so libcrammd5.2.0.22.so libdigestmd5.2.0.22.so
libgssapiv2.2.0.22.so liblogin.2.0.22.so libotp.2.0.22.so
libplain.2.0.22.so
libanonymous.2.so libcrammd5.2.so libdigestmd5.2.so
libgssapiv2.2.so liblogin.2.so libotp.2.so
libplain.2.so
libanonymous.la libcrammd5.la libdigestmd5.la
libgssapiv2.la liblogin.la libotp.la
libplain.la
libanonymous.so libcrammd5.so libdigestmd5.so
libgssapiv2.so liblogin.so libotp.so
libplain.so


So I then did:

build-mac-x86:/opt/zimbra/cyrus-sasl/lib/sasl2 root# rm libplain.so
build-mac-x86:/opt/zimbra/cyrus-sasl/lib/sasl2 root# rm libplain.2.so


Then when I run the script, I get:

[EXTERNAL,ANONYMOUS,ANONYMOUS,ANONYMOUS,CRAM-MD5,CRAM-MD5,CRAM-MD5,DIGEST-MD
5,DIGEST-MD5,DIGEST-MD5,GSSAPI,GSSAPI,GSSAPI,LOGIN,LOGIN,LOGIN,OTP,OTP,OTP,PLAIN]


See how plain is only listed *once* now.

So apparently SASL is treating every *.so file as a plugin when on a Mac,
rather than ignoring the symlinks.

In fact, if I remove all the symlinks, I get:

Testing sasl_listmech()...
Client sasl_client_add_plugin: Added mech EXTERNAL
Client sasl_client_add_plugin: Added mech ANONYMOUS
Client sasl_client_add_plugin: Added mech CRAM-MD5
Client sasl_client_add_plugin: Added mech DIGEST-MD5
Client sasl_client_add_plugin: Added mech GSSAPI
Client sasl_client_add_plugin: Added mech LOGIN
Client sasl_client_add_plugin: Added mech OTP
Client sasl_client_add_plugin: Added mech PLAIN
Global mechanisms list:
[EXTERNAL,ANONYMOUS,CRAM-MD5,DIGEST-MD5,GSSAPI,LOGIN,OTP,PLAIN]
Client mechlist:
[PLAIN,OTP,LOGIN,GSSAPI,DIGEST-MD5,CRAM-MD5,ANONYMOUS,EXTERNAL]
We have the following mechs:
[PLAIN,LOGIN,GSSAPI,DIGEST-MD5,CRAM-MD5,ANONYMOUS,EXTERNAL]
All memory accounted for!
Testing sasl_listmech()... ok
All tests seemed to go ok (i.e. we didn't crash)

Yeah, no memory leak. So this is definitely a problem of determining
symlink vs actual file in the SASL code for macintosh.

--Quanah


--

Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
Howard Chu
2008-01-29 22:08:23 UTC
Permalink
Post by Quanah Gibson-Mount
--On Thursday, January 24, 2008 10:32 AM -0800 Quanah Gibson-Mount
Post by Quanah Gibson-Mount
The problem does not occur with the Mac system sasl library. It only
occurs with stock builds of cyrus-sasl. I.e., Apple's fixed the issue
apparently, but their source is very heavily modified, I've just begun
looking into it. They also are using the rather old 2.1.18, and I need
2.1.22. ;) The same issues with a stock 2.1.18 build as well.
This appears to be a problem in the way that the plugins are loaded with
add_plugin.
build-mac-x86:/opt/zimbra/cyrus-sasl/lib/sasl2 root# ls
libanonymous.2.0.22.so libcrammd5.2.0.22.so libdigestmd5.2.0.22.so
libgssapiv2.2.0.22.so liblogin.2.0.22.so libotp.2.0.22.so
libplain.2.0.22.so
libanonymous.2.so libcrammd5.2.so libdigestmd5.2.so
libgssapiv2.2.so liblogin.2.so libotp.2.so
libplain.2.so
libanonymous.la libcrammd5.la libdigestmd5.la
libgssapiv2.la liblogin.la libotp.la
libplain.la
libanonymous.so libcrammd5.so libdigestmd5.so
libgssapiv2.so liblogin.so libotp.so
libplain.so
build-mac-x86:/opt/zimbra/cyrus-sasl/lib/sasl2 root# rm libplain.so
build-mac-x86:/opt/zimbra/cyrus-sasl/lib/sasl2 root# rm libplain.2.so
[EXTERNAL,ANONYMOUS,ANONYMOUS,ANONYMOUS,CRAM-MD5,CRAM-MD5,CRAM-MD5,DIGEST-MD
5,DIGEST-MD5,DIGEST-MD5,GSSAPI,GSSAPI,GSSAPI,LOGIN,LOGIN,LOGIN,OTP,OTP,OTP,PLAIN]
See how plain is only listed *once* now.
So apparently SASL is treating every *.so file as a plugin when on a Mac,
rather than ignoring the symlinks.
The SASL code never checks to see if a file is a symlink or not. (Nor should
it, since you might legitimately symlink a plugin from some other location
into the default plugin directory.) All it does is look for a ".so" or ".la"
suffix, and it ignores anything else. This works on most platforms because for
versioned files, they stick the version *after* the .so suffix. E.g. you would
have libplain.so and libplain.so.2, libplain.so.2.0.22.

Why they've messed with the order of name components on MacOS is beyond me. Is
that the way all other shared libraries are named as well, or is this just a
broken libtool installing things with the wrong names?
Post by Quanah Gibson-Mount
Testing sasl_listmech()...
Client sasl_client_add_plugin: Added mech EXTERNAL
Client sasl_client_add_plugin: Added mech ANONYMOUS
Client sasl_client_add_plugin: Added mech CRAM-MD5
Client sasl_client_add_plugin: Added mech DIGEST-MD5
Client sasl_client_add_plugin: Added mech GSSAPI
Client sasl_client_add_plugin: Added mech LOGIN
Client sasl_client_add_plugin: Added mech OTP
Client sasl_client_add_plugin: Added mech PLAIN
[EXTERNAL,ANONYMOUS,CRAM-MD5,DIGEST-MD5,GSSAPI,LOGIN,OTP,PLAIN]
[PLAIN,OTP,LOGIN,GSSAPI,DIGEST-MD5,CRAM-MD5,ANONYMOUS,EXTERNAL]
[PLAIN,LOGIN,GSSAPI,DIGEST-MD5,CRAM-MD5,ANONYMOUS,EXTERNAL]
All memory accounted for!
Testing sasl_listmech()... ok
All tests seemed to go ok (i.e. we didn't crash)
Yeah, no memory leak. So this is definitely a problem of determining
symlink vs actual file in the SASL code for macintosh.
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
--
-- 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/
Quanah Gibson-Mount
2008-01-29 22:09:11 UTC
Permalink
--On Tuesday, January 29, 2008 1:52 PM -0800 Howard Chu
Post by Howard Chu
The SASL code never checks to see if a file is a symlink or not. (Nor
should it, since you might legitimately symlink a plugin from some other
location into the default plugin directory.) All it does is look for a
".so" or ".la" suffix, and it ignores anything else. This works on most
platforms because for versioned files, they stick the version *after* the
.so suffix. E.g. you would have libplain.so and libplain.so.2,
libplain.so.2.0.22.
Why they've messed with the order of name components on MacOS is beyond
me. Is that the way all other shared libraries are named as well, or is
this just a broken libtool installing things with the wrong names?
Macintosh doesn't natively create "*.so" files. It creates "*.dylib"
files. The fact that SASL is creating "*.so" files indicates that
something is been done by SASL to change the default Macintosh behavior.

However, "*.dylib" creation is done in the rather broken manner you
describe, so I would guess that is the default behavior for libtool on the
mac. ;)

build-mac-x86:/tmp/qi/openldap-2.3.40.7z/lib build$ ls -l
total 7936
-rw-r--r-- 1 build wheel 126816 Jan 22 14:41 liblber-2.3.0.2.28.dylib
lrwxr-xr-x 1 build wheel 24 Jan 29 13:54 liblber-2.3.0.dylib ->
liblber-2.3.0.2.28.dylib
-rw-r--r-- 1 build wheel 146300 Jan 22 14:41 liblber.a
lrwxr-xr-x 1 build wheel 24 Jan 29 13:54 liblber.dylib ->
liblber-2.3.0.2.28.dylib
-rw-r--r-- 1 build wheel 1151 Jan 22 14:41 liblber.la
-rw-r--r-- 1 build wheel 836724 Jan 22 14:41 libldap-2.3.0.2.28.dylib
lrwxr-xr-x 1 build wheel 24 Jan 29 13:54 libldap-2.3.0.dylib ->
libldap-2.3.0.2.28.dylib
-rw-r--r-- 1 build wheel 954604 Jan 22 14:41 libldap.a
lrwxr-xr-x 1 build wheel 24 Jan 29 13:54 libldap.dylib ->
libldap-2.3.0.2.28.dylib
-rw-r--r-- 1 build wheel 1313 Jan 22 14:41 libldap.la
-rw-r--r-- 1 build wheel 909264 Jan 22 14:41 libldap_r-2.3.0.2.28.dylib
lrwxr-xr-x 1 build wheel 26 Jan 29 13:54 libldap_r-2.3.0.dylib ->
libldap_r-2.3.0.2.28.dylib
-rw-r--r-- 1 build wheel 1041556 Jan 22 14:41 libldap_r.a
lrwxr-xr-x 1 build wheel 26 Jan 29 13:54 libldap_r.dylib ->
libldap_r-2.3.0.2.28.dylib
-rw-r--r-- 1 build wheel 1327 Jan 22 14:41 libldap_r.la


--Quanah

--

Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
Howard Chu
2008-01-29 22:47:19 UTC
Permalink
Post by Quanah Gibson-Mount
--On Tuesday, January 29, 2008 1:52 PM -0800 Howard Chu
Post by Howard Chu
Why they've messed with the order of name components on MacOS is beyond
me. Is that the way all other shared libraries are named as well, or is
this just a broken libtool installing things with the wrong names?
Macintosh doesn't natively create "*.so" files. It creates "*.dylib"
files. The fact that SASL is creating "*.so" files indicates that
something is been done by SASL to change the default Macintosh behavior.
However, "*.dylib" creation is done in the rather broken manner you
describe, so I would guess that is the default behavior for libtool on the
mac. ;)
I guess you should take a look at the diff's between Apple's sasl/lib/dlopen.c
and the stock Cyrus version then.

This is one of the big weaknesses of all current open source licenses, IMO.
Back before the GPL, I used to release all my freeware projects with a clause
"you are free to modify this code in any way, but you must send all bug fixes
back to me for inclusion into the main code" as a condition of the license.

When you use free software, you have an obligation to contribute back. When
you encounter bugs, you should report them. When you fix them for yourself,
you should contribute the fix too. It seems that only a small minority of the
people/companies using free software actually understand this principle.
--
-- 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/
Quanah Gibson-Mount
2008-01-30 04:22:04 UTC
Permalink
--On Tuesday, January 29, 2008 2:31 PM -0800 Howard Chu
Post by Howard Chu
I guess you should take a look at the diff's between Apple's
sasl/lib/dlopen.c and the stock Cyrus version then.
It's heavily modified... I'll look at putting together a readable diff.

--Quanah

--

Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration

Loading...