On 2014-10-15 13:57, Aaron Richton wrote:
On Wed, 15 Oct 2014, Tobias Ljunggren wrote:
> I built with moznss instead of openSSL. That solves the problem and I don't try
to fix someone else mistakes.
It might hide the problem, but that doesn't fix anything. It's worth reiterating
up front that MozNSS isn't ideal, especially
if you're planning to use slapd(8) as a server.
But more importantly, you're probably just kicking the can. You're noticing a
conflict on SSL_new today, but it could just as
easily be malloc(3) or strcmp(3) tomorrow. Are you seriously going to change OpenLDAP to
use uClibc or who-knows-what as a way
of tricking the linker? The long-term answer is ensuring that everything is linked to
"the normal libraries" in the way that
you'd expect.
You are right, and I would if I could. Problem is that the application that starts the
process (which loads my module) is closed
source and I can't do anything about it. This is a module that will update a ldap
directory based on events from another system
(or update the system based on changes in a LDAP directory), this only concerns the
libraries (liblber and libldap_r) not slapd.
I've checked with both ldd(1) and nm(1) and system libraries like libc*, libgcc*,
libstdc++ and libpthread* are linked correctly.
How to accomplish this is somewhat platform-dependent, although the principles are always
the same. On Solaris, for example,
-Bdirect and mapfiles would help in this situation. ld from GNU binutils has other -B
options that may be relevant, and
"dynamic-list" functionality. etc etc. Bottom line, this is a fundamental build
issue, and changing the color of the Legos
doesn't really address the root cause.
As far as I understand, today, I
can't really do anything about this since the application that cause the openSSL
conflicts is
closed source?
> Best regards,
> Tobias
>
> On 2014-10-08 14:59, Tobias Ljunggren wrote:
> Hello,
>
> I just found what's causing the crash. The application that loads my
library already have some of the openSSL
> functions. Either they have copied the source code or statically linked to openSSL.
Because of this openLDAP
> sometimes uses the wrong functions (SSL_new is one of them).
>
> I guess my only option is to build openLDAP with a static linkage to openSSL?
>
> Best regards,
> Tobias
>
> On 2014-10-07 17:06, Tobias Ljunggren wrote:
> Hello,
>
> I've been trying to track a segmentation fault for a couple of days
but I'm running out of ideas and need some
> help or suggestion on how to proceed.
>
> Perhaps this is the wrong forum and if so I apologize. It's also
worth mentioning that I don't have any knowledge
> about the openSSL library source code but I've been working with ldap libraries
for quite
> some time (about 10 years).
>
> What I have is shared object (.so) that is loaded from another program
(nothing I have control of) using a public
> API. My library loads openLDAP (libldap_r and liblber) using dlopen/dlsym. After
some
> initialization code I try to bind to a ldap source (ldaps://ldaphost:636)
but I get a segmentation fault in
> s23_clnt.c at line 159:
> else if (s->ctx->info_callback != NULL)
>
> For some reason s->ctx is a null pointer. My first thoughts was that I
do something I shouldn't prior to
> ldap_sasl_bind_s which corrupts the LDAP handle but after days with gdb and valgrind
I still can't
> find anything.
>
> openLDAP version used is 2.4.40 built with openSSL 1.0.1i.
>
> If I copy the ldap code to a test executable it works fine.
>
> Is there anything special to consider when loading the libraries from a
shared object?
>
> I understand that it is almost impossible to give me any good answers but
since I'm a bit frustrated I hope
> someone can give me some hints.
>
> Best regards,
> Tobias
>
>
>
>
>