[xmlsec] New xmlsec 1.2.17 release

[Aleksey Sanin]

Any chance you can run it under valgrind?

Aleksey


On 4/14/11 3:00 PM, Roumen Petrov wrote:
> Aleksey Sanin wrote:
>> Yes, I did a smarter move - I changed tests to use verification time 
>> from the past :) :) :)
>> This way I can keep "original" test files from XMLSec working group 
>> certification tests.
> Clever ;)
>>
>> Aleksey
> Now with repository versions of xmlsec,libxml, libxslt I could not 
> found big issues in xmlsec regression tests.
>
> Only one test crash :  xmldsig2ed-tests/defCan-2 with gnutls (on 
> exit?). Same test pass with openssl, nss and gcrypt.
>
> The information below is form x86_64 build environment. All (xmlsec, 
> libxslt, libxml) is build with libtool 2.4 FSF version, i.e without 
> vendor patches.
>
>
> a) The file testDSig.sh*.log report:
> Test: xmldsig2ed-tests/defCan-2 in folder 
> <SOURCEDIR>/tests/xmldsig2ed-tests  (success)
>
> b) output on console report:
> xmldsig2ed-tests/defCan-2
>     Checking required transforms                            OK
>     Checking required key data                              OK
>     Verify existing signature                            
> ./tests/testrun.sh[439]: .: line 255: 21615: Abort
>  Fail
>     Create new signature                                 
> ./tests/testrun.sh[439]: .: line 262: 21622: Abort
>  Fail
>     Verify new signature                                    OK
>
> c) This is the crash log:
> rumen at master:<BUILDROOT>/xmlsec-origin$ make check > 
> test-20110407/console-log 2>&1
> .....
> *** glibc detected *** 
> <BUILDROOT>/xmlsec-origin/apps/.libs/lt-xmlsec1: free(): invalid next 
> size (fast): 0x00000000006350a0 ***
> ======= Backtrace: =========
> /lib64/libc.so.6(+0x76ce6)[0x2ba0b5ea4ce6]
> /lib64/libc.so.6(cfree+0x73)[0x2ba0b5eab553]
> <BUILDROOT>/libxml2-origin/.libs/libxml2.so.2(xmlHashFree+0x140)[0x2ba0b52982c0] 
>
> <BUILDROOT>/libxml2-origin/.libs/libxml2.so.2(xmlXPathRegisteredFuncsCleanup+0x14)[0x2ba0b52c0734] 
>
> <BUILDROOT>/libxml2-origin/.libs/libxml2.so.2(xmlXPathFreeContext+0x2a)[0x2ba0b52c076a] 
>
> <BUILDROOT>/xmlsec-origin/src/.libs/libxmlsec1.so.1(+0x5a046)[0x2ba0b4ba9046] 
>
> <BUILDROOT>/xmlsec-origin/src/.libs/libxmlsec1.so.1(xmlSecPtrListEmpty+0x109)[0x2ba0b4b826ec] 
>
> <BUILDROOT>/xmlsec-origin/src/.libs/libxmlsec1.so.1(xmlSecPtrListFinalize+0x67)[0x2ba0b4b825cb] 
>
> <BUILDROOT>/xmlsec-origin/src/.libs/libxmlsec1.so.1(+0x5b32a)[0x2ba0b4baa32a] 
>
> <BUILDROOT>/xmlsec-origin/src/.libs/libxmlsec1.so.1(xmlSecTransformDestroy+0x15c)[0x2ba0b4b93a8d] 
>
> <BUILDROOT>/xmlsec-origin/src/.libs/libxmlsec1.so.1(xmlSecTransformCtxReset+0xef)[0x2ba0b4b8fe13] 
>
> <BUILDROOT>/xmlsec-origin/src/.libs/libxmlsec1.so.1(xmlSecTransformCtxFinalize+0x5b)[0x2ba0b4b8fcfc] 
>
> <BUILDROOT>/xmlsec-origin/src/.libs/libxmlsec1.so.1(xmlSecDSigReferenceCtxFinalize+0x62)[0x2ba0b4b9e033] 
>
> <BUILDROOT>/xmlsec-origin/src/.libs/libxmlsec1.so.1(xmlSecDSigReferenceCtxDestroy+0x5b)[0x2ba0b4b9ddc6] 
>
> <BUILDROOT>/xmlsec-origin/src/.libs/libxmlsec1.so.1(xmlSecPtrListEmpty+0x109)[0x2ba0b4b826ec] 
>
> <BUILDROOT>/xmlsec-origin/src/.libs/libxmlsec1.so.1(xmlSecPtrListFinalize+0x67)[0x2ba0b4b825cb] 
>
> <BUILDROOT>/xmlsec-origin/src/.libs/libxmlsec1.so.1(xmlSecDSigCtxFinalize+0x98)[0x2ba0b4b9a646] 
>
> <BUILDROOT>/xmlsec-origin/apps/.libs/lt-xmlsec1[0x40429d]
> <BUILDROOT>/xmlsec-origin/apps/.libs/lt-xmlsec1[0x4039c2]
> /lib64/libc.so.6(__libc_start_main+0xfd)[0x2ba0b5e4cb6d]
> <BUILDROOT>/xmlsec-origin/apps/.libs/lt-xmlsec1[0x4033e9]
> ======= Memory map: ========
> .....
>
> Note that above does not mean bug in xmlsec code.  I will continue to 
> investigate core of the issue.
> Some internet reports issue with memory allocation in libc-2.11. May 
> be is related to "new" memcpy behavior that follows the spec but I'm 
> not sure whether my libc version "follows the spec ".
>
> Regards,
> Roumen
>