http://bugs.winehq.org/show_bug.cgi?id=26098
Summary: rsaenh/rsaenh tests shows some valgrind warnings Product: Wine Version: 1.3.13 Platform: x86 OS/Version: Linux Status: NEW Keywords: download, source, testcase Severity: trivial Priority: P2 Component: rsaenh AssignedTo: wine-bugs@winehq.org ReportedBy: austinenglish@gmail.com
Invalid read of size 4 at CryptHashData (crypt.c:1753) by test_hashes (rsaenh.c:571) by func_rsaenh (rsaenh.c:2980) by run_test (test.h:556) by main (test.h:624) Address 0x7f0095d0 is 0 bytes inside a block of size 24 free'd at notify_free (heap.c:262) by RtlFreeHeap (heap.c:1747) by HeapFree (heap.c:272) by GlobalFree (heap.c:748) by LocalFree (heap.c:1009) by CryptReleaseContext (crypt.c:652) by test_hashes (rsaenh.c:567) by func_rsaenh (rsaenh.c:2980) by run_test (test.h:556) by main (test.h:624)
...
Invalid read of size 4 at CryptDestroyHash (crypt.c:884) by test_hashes (rsaenh.c:577) by func_rsaenh (rsaenh.c:2980) by run_test (test.h:556) by main (test.h:624) Address 0x7f0095d0 is 0 bytes inside a block of size 24 free'd at notify_free (heap.c:262) by RtlFreeHeap (heap.c:1747) by HeapFree (heap.c:272) by GlobalFree (heap.c:748) by LocalFree (heap.c:1009) by CryptReleaseContext (crypt.c:652) by test_hashes (rsaenh.c:567) by func_rsaenh (rsaenh.c:2980) by run_test (test.h:556) by main (test.h:624)
...
12 bytes in 1 blocks are definitely lost at notify_alloc (heap.c:254) by RtlAllocateHeap (heap.c:1701) by HeapAlloc (heap.c:267) by GlobalAlloc (heap.c:360) by LocalAlloc (heap.c:960) by CryptCreateHash (crypt.c:739) by test_hashes (rsaenh.c:563) by func_rsaenh (rsaenh.c:2980) by run_test (test.h:556) by main (test.h:624)
...
368 bytes in 1 blocks are definitely lost at notify_alloc (heap.c:254) by RtlAllocateHeap (heap.c:1701) by ??? by ??? by CryptCreateHash (crypt.c:747) by test_hashes (rsaenh.c:563) by func_rsaenh (rsaenh.c:2980) by run_test (test.h:556) by main (test.h:624)
...
there's also: Conditional jump or move depends on uninitialised value(s) at RSAENH_CPDeriveKey (rsaenh.c:3926) by CryptDeriveKey (crypt.c:844) by test_schannel_provider (rsaenh.c:2373) by func_rsaenh (rsaenh.c:2998) by run_test (test.h:556) by main (test.h:624) Uninitialised value was created by a client request at mark_block_uninitialized (heap.c:208) by initialize_block (heap.c:239) by RtlAllocateHeap (heap.c:1702) by new_object (handle.c:359) by new_key (rsaenh.c:850) by import_symmetric_key (rsaenh.c:2911) by import_key (rsaenh.c:3066) by RSAENH_CPImportKey (rsaenh.c:3103) by CryptImportKey (crypt.c:1843) by test_schannel_provider (rsaenh.c:2339) by func_rsaenh (rsaenh.c:2998) by run_test (test.h:556) by main (test.h:624)
but I'm betting that http://source.winehq.org/patches/data/71353 may fix that (which was caught today by +heap).
http://bugs.winehq.org/show_bug.cgi?id=26098
--- Comment #1 from Juan Lang juan_lang@yahoo.com 2011-02-14 17:05:14 CST --- (In reply to comment #0)
Invalid read of size 4 at CryptHashData (crypt.c:1753) by test_hashes (rsaenh.c:571)
This is expected. The provider in which the hash is created was destroyed before the hash, invalidating the hash.
Invalid read of size 4 at CryptDestroyHash (crypt.c:884) by test_hashes (rsaenh.c:577)
Likewise with this one.
12 bytes in 1 blocks are definitely lost 368 bytes in 1 blocks are definitely lost
The leaks are likewise related.
It could be that a better reference counting mechanism could be devised to avoid such errors, but it's not clear that apps would benefit as a result. I think a suppression might well be the appropriate response here.
http://bugs.winehq.org/show_bug.cgi?id=26098
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX
--- Comment #2 from Austin English austinenglish@gmail.com 2011-02-14 17:36:18 CST --- Okay, suppressed now. Thanks.
http://bugs.winehq.org/show_bug.cgi?id=26098
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #3 from Austin English austinenglish@gmail.com 2011-02-14 19:11:14 CST --- Closing.