http://bugs.winehq.org/show_bug.cgi?id=34829
Bug #: 34829 Summary: wintrust:softpub crashes on Windows 8 Product: Wine Version: 1.7.5 Platform: x86 OS/Version: Windows Status: NEW Severity: normal Priority: P2 Component: wintrust AssignedTo: wine-bugs@winehq.org ReportedBy: fgouget@codeweavers.com Classification: Unclassified
The wintrust:softpub conformance test crashes on Windows 8:
softpub.c:264: this is the last test seen before the exception softpub: unhandled exception c0000005 at 75B0471A
The crash happens on this testObjTrust() line:
ret = funcs->pfnObjectTrust(&data); ok(ret == S_FALSE, "Expected S_FALSE, got %08x\n", ret);
(funcs->pfnObjectTrust is not NULL)
http://bugs.winehq.org/show_bug.cgi?id=34829
François Gouget fgouget@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |source
https://bugs.winehq.org/show_bug.cgi?id=34829
François Gouget fgouget@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression, testcase URL| |http://test.winehq.org/data | |/tests/wintrust:softpub.htm | |l Regression SHA1| |5a3fb3b566875b4ba52430e460e | |14318db3a469f
--- Comment #1 from François Gouget fgouget@codeweavers.com --- This crash happens systematically on all Windows 8 and 8.1 machines, including the WineTestBot ones. See:
http://test.winehq.org/data/tests/wintrust:softpub.html
The commit that introduced this test is:
commit 5a3fb3b566875b4ba52430e460e14318db3a469f Author: Juan Lang juan.lang@gmail.com Date: Mon Aug 27 16:17:52 2007 -0700
wintrust: Test and implement SoftpubLoadMessage.
https://bugs.winehq.org/show_bug.cgi?id=34829
--- Comment #2 from Nikolay Sivov bunglehead@gmail.com --- I think it's worth to try to zero this one:
--- SAFE_PROVIDER_FUNCTIONS funcs = { sizeof(SAFE_PROVIDER_FUNCTIONS), 0 }; ---
not just a first pointer but all of them, it's possible some garbage value sits there.
If this doesn't help another possibility is that CRYPT_PROVIDER_DATA.cbStruct should be initialized.
https://bugs.winehq.org/show_bug.cgi?id=34829
--- Comment #3 from François Gouget fgouget@codeweavers.com --- This initialization already causes the whole structure to be zeroed. Same thing for 'CRYPT_PROVIDER_DATA data = { 0 }'. So adding a memset makes no change. See:
https://newtestbot.winehq.org/JobDetails.pl?Key=4962
https://bugs.winehq.org/show_bug.cgi?id=34829
--- Comment #4 from Nikolay Sivov bunglehead@gmail.com --- Sure it does, I meant it's not initialized to sizeof(CRYPT_PROVIDER_DATA).
https://bugs.winehq.org/show_bug.cgi?id=34829
--- Comment #5 from François Gouget fgouget@codeweavers.com --- (In reply to comment #4)
Sure it does, I meant it's not initialized to sizeof(CRYPT_PROVIDER_DATA).
My understanding is that it is initialized to sizeof(CRYPT_PROVIDER_DATA):
From https://stackoverflow.com/questions/10828294/c-and-c-partial-initialization-... --- C99 Standard 6.7.8.21
If there are fewer initializers in a brace-enclosed list than there are elements or members of an aggregate, or fewer characters in a string literal used to initialize an array of known size than there are elements in the array, the remainder of the aggregate shall be initialized implicitly the same as objects that have static storage duration. ---
Objects (aggregates, arrays, etc.) that have static storage duration are always initializaed to all zeroes.
Now we may have trouble if the compiler does not follow the C99 standard but the WineTestBot run I referenced shows that this is not the case here.
https://bugs.winehq.org/show_bug.cgi?id=34829
--- Comment #6 from Nikolay Sivov bunglehead@gmail.com --- Looks like we keep talking about different things. So:
--- CRYPT_PROVIDER_DATA data = { 0 }; WINTRUST_DATA wintrust_data = { 0 }; WINTRUST_CERT_INFO certInfo = { sizeof(WINTRUST_CERT_INFO), 0 }; WINTRUST_FILE_INFO fileInfo = { sizeof(WINTRUST_FILE_INFO), 0 }; ---
here two last structs have size field initialized while first 'data' variable has not. I was talking about that 'data', that maybe it should be { sizeof(CRYPT_PROVIDER_DATA) } instead of { 0 }.
https://bugs.winehq.org/show_bug.cgi?id=34829
--- Comment #7 from François Gouget fgouget@codeweavers.com --- Oh, sorry about the misunderstanding. So I applied the patch below but unfortunately without luck:
- CRYPT_PROVIDER_DATA data = { 0 }; + CRYPT_PROVIDER_DATA data = { sizeof(CRYPT_PROVIDER_DATA) };
I then tried variants, adding a redundant ',0', giving the same treatment to 'WINTRUST_DATA wintrust_data = { 0 }', but no luck either.
(Just in case, I also checked that pfnObjectTrust points to valid memory. It does.)
https://bugs.winehq.org/show_bug.cgi?id=34829
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download
--- Comment #8 from Austin English austinenglish@gmail.com --- Still in 1.7.37.
https://bugs.winehq.org/show_bug.cgi?id=34829
Bernhard Übelacker bernhardu@mailbox.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bernhardu@mailbox.org
--- Comment #9 from Bernhard Übelacker bernhardu@mailbox.org --- Created attachment 55308 --> https://bugs.winehq.org/attachment.cgi?id=55308 Try to prove that data variable is accessed beyond allocated memory.
By placing the data variable just before a memory page with PAGE_NOACCESS the address of the crash changes. Could we assume then that there is a problem with the CRYPT_PROVIDER_DATA type?
https://bugs.winehq.org/show_bug.cgi?id=34829
Hans Leidekker hans@meelstraat.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Fixed by SHA1| |efd063f5c569fe704a29f247ad5 | |3e4226872e704 Status|NEW |RESOLVED
--- Comment #10 from Hans Leidekker hans@meelstraat.net --- Fixed with efd063f5c569fe704a29f247ad53e4226872e704.
https://bugs.winehq.org/show_bug.cgi?id=34829
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #11 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 2.0-rc2.
-
wine-bugs＠winehq.org