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.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
