On Mon, Dec 19, 2016 at 09:57:42PM +0100, Daniel Pocock wrote:
>
>
> On 19/12/16 21:26, Sebastian Andrzej Siewior wrote:
> > On 2016-12-19 09:40:38 [+0100], Daniel Pocock wrote:
> >> Could this be a known issue on ppc64el or with libssl?
> >
> > Nothing comes to mind. But it explodes the same way (but without the
> > fancy backtrace) on hurd, too.
> >
> >> FAIL: stunTestVectors
> >> =====================
> >>
> >> INFO | 20161218-094209.416 | | RESIP:TEST | 70366852992352 |
> >> stunTestVectors.cxx:168 | All tests passed!
> >> *** Error in `/«PKGBUILDDIR»/reTurn/test/.libs/stunTestVectors': double
> >> free or corruption (out): 0x000001001be00e20 ***
> >> ======= Backtrace: =========
> >> /lib/powerpc64le-linux-gnu/libc.so.6(+0x829e8)[0x3fff8ea529e8]
> >> /lib/powerpc64le-linux-gnu/libc.so.6(+0x8c098)[0x3fff8ea5c098]
> >> /lib/powerpc64le-linux-gnu/libc.so.6(+0x8cbec)[0x3fff8ea5cbec]
> >> /usr/lib/powerpc64le-linux-gnu/libcrypto.so.1.0.2(CRYPTO_free+0x60)[0x3fff8ef79430]
> >> /usr/lib/powerpc64le-linux-gnu/libssl.so.1.0.2(+0x4ded8)[0x3fff8f19ded8]
> >> /usr/lib/powerpc64le-linux-gnu/libcrypto.so.1.0.2(sk_pop_free+0x74)[0x3fff8f0134c4]
> >> /usr/lib/powerpc64le-linux-gnu/libssl.so.1.0.2(SSL_COMP_free_compression_methods+0x3c)[0x3fff8f1a0b6c]
> >> /«PKGBUILDDIR»/reTurn/test/.libs/stunTestVectors(_ZNSt15_Sp_counted_ptrIPN4asio3ssl6detail17openssl_init_base7do_initELN9__gnu_cxx12_Lock_policyE2EE10_M_disposeEv+0x64)[0x5e41a044]
> >> /«PKGBUILDDIR»/reTurn/test/.libs/stunTestVectors(_ZNSt10shared_ptrIN4asio3ssl6detail17openssl_init_base7do_initEED1Ev+0xdc)[0x5e41a41c]
> >
> > So a deconstructor in asio invokes SSL_COMP_free_compression_methods()
> > on the end and we explode while the list is cleaned up. Now lets look a
> > little… Oh what is this rutil/ssl/OpenSSLInit.cxx:
> >
> > | OpenSSLInit::~OpenSSLInit()
> > | {
> > | mInitialized = false;
> > | ERR_remove_state(0);// free thread error queue
> > | EVP_cleanup();// Clean up data allocated during
> > OpenSSL_add_all_algorithms
> > | CRYPTO_cleanup_all_ex_data();
> > | ERR_free_strings();// Clean up data allocated during
> > SSL_load_error_strings
> > | sk_SSL_COMP_free (SSL_COMP_get_compression_methods());
> > |
> > | // CRYPTO_mem_leaks_fp(stderr);
> > | cerr << "HELLO" << endl;
> > | delete [] mMutexes;
> > | }
> >
> > |(sid)bigeasy@debbuildd:/build/resiprocate-1.11.0~alpha8/reTurn/test$
> > ./stunTestVectors
> > |INFO | 20161219-202446.416 | | RESIP:TEST | 140378940325248 |
> > stunTestVectors.cxx:168 | All tests passed!
> > |HELLO
> >
> > Hmmm. It gives me the impression that exploding here is what should be
> > expected and libssl is the victim here.
> >
>
> Thanks for taking the time to look at this.
>
> Is there an example of how this cleanup should be done, or is there a
> specific line of code there that you believe is out of place?
>
> If it is definitely not an openssl issue then the bug can be moved back
> to src:resiprocate
You should use SSL_COMP_free_compression_methods() so that we can
put the internal pointer to NULL.
Kurt
