On Mon, Dec 06, 2004, Victor B. Wagner wrote:
> On 2004.12.04 at 00:45:45 -0500, Geoff Thorpe wrote:
>
> > On December 3, 2004 07:30 pm, Dr. Stephen Henson wrote:
> > > On Fri, Dec 03, 2004, Dmitry Belyavsky wrote:
> > > > On Fri, 3 Dec 2004, Dmitry Belyavsky wrote:
> > > > > I have custom dynamically-loaded engine implementing some
> > > > > non-standard algorithms. So I register NIDs using OBJ_create from
> > > > > engine bind function. Registering code looks like
> > > > >
> > > > > my_NID = OBJ_create("1.2.3.4.5","OID_example","Our example OID");
> > > > >
> > > > > On unload I get segfault in apps_shutdown. It happens in
> > > > > OBJ_NAME_cleanup. It looks like OBJ_NAME_cleanup tries to free
> > > > > memory belongs to unloaded library.
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > I hacked up a quick dynamic engine that called OBJ_create() only and I
> > > couldn't reproduce this. I used the autoconfig mechanism mentioned in
> > > config(5) to load it. The object was added, it was recognized by
> > > asn1parse and there were no leaks on shutdown.
>
> First of all, I should note that there is no problem if we just use
> OBJ_create. But, if we then register cipher and digest algorithms, using
> NID returned by the OBJ_create, problem sometimes occur.
>
> We were unable so far to pin problems down. Some openssl command cause
> segfault, and some do not (although debug build reports number of memory
> leaks).
>
> We found out that dgst command never produce segfaults, and does call
> destroy function, when req command (generating CSR or self-signed
> certificate) does produce segfault. In both cases message digest
> algorithm from our engine is used.
>
> > This is probably another "global state"-type problem between the loader
> > and loadee. See IMPLEMENT_DYNAMIC_BIND_FN() in engine.h for an peek into
> > the horror. I'm guessing you guys are using different platforms, or at
> > least different methods of compilation/linking? We need to ensure that
>
> Of course, not. We are using same compiler for openssl core and our
> engine. There might be some difference in compilation flags, but it
> shouldn't matter.
>
> > the loaded engine use the loading app/lib's state - if necessary by
> > redirecting its OBJ functionality to that of the loader.
>
> We have openssl compiled as shared library, so it shouldn't pose any
> problems in ELF environment.
>
> BTW we have traced it with debugger, so we can be reasonable sure that
> correct version of library gets loaded.
>
> > I'm out of here for the weekend, but if noone gets to the bottom of this
> > before middle(ish) of next week, I'll take a nosey. Which version are you
> > using BTW?
>
> We are now using CVS snapshot of November 29.
I doubt its related to the NIDs and OBJ_create(). The NIDs and associated
objects duplicate strings for use in OpenSSLs internal tables and so there
shouldn't be any hanging references when a DLL unloads.
In any case the extra objects are freed up when OBJ_cleanup() is called.
If you want to make sure you could use existing NIDs or add some OIDs to
objects.txt to see if that resolves the problem.
Now you mentioned 'req' and it causing problems. Would this use a private key
from your ENGINE? I'm wondering if its a possible reference counting issue and
the returned EVP_PKEY doesn't up the ENGINE functional reference count. If so
the ENGINE could be unloaded while parts of it are still referenced.
Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
OpenSSL project core developer and freelance consultant.
Funding needed! Details on homepage.
Homepage: http://www.drh-consultancy.demon.co.uk
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
