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@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
_______________________________________________
xmlsec mailing list
[email protected]
http://www.aleksey.com/mailman/listinfo/xmlsec
