Bad code generation for std::atomic in visual c++ - by Eternal Wind

Status : 

  Not Reproducible<br /><br />
		The product team could not reproduce this item with the description and steps provided.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.


1
0
Sign in
to vote
ID 800824 Comments
Status Closed Workarounds
Type Bug Repros 1
Opened 9/15/2013 10:03:13 AM
Access Restriction Public

Description

Recently I happened to run into a bad code generation situation. I got a struct contains static std::atomic_ullong objects and a function performs operations on them. The code compiles and runs without any problems under debug mode. However, it gets access violation exceptions under release mode with the code optimizations applied. No such problem with either std::atomic_uint or std::atomic_ulong though. And this issue happens only with compiling against x86. After I asked on stack overflow, it seems the generated assembly code is problematic. One answer said something like this:

"EBX is used as a scratch register in the body of the function. Its value happens to be 1 by this point. So then ESP becomes 1, and then POP tries to read from that, obviously bogus, address"

My code is in the attachment file. Thanks.
Sign in to post a comment.
Posted by Microsoft on 10/1/2013 at 3:01 PM
This bug fix is not ported in VS2012. We will evaluate it and let you know.

Thanks
Charles Fu
Posted by Eternal Wind on 9/30/2013 at 4:44 PM
Ah, vs2013 rtm. I thought that was vs2012 update 4 rtm. Is there a solution for vs2012?
Posted by Microsoft on 9/30/2013 at 11:05 AM
Thanks for reporting this bug. Under release mode, compiler does link-time-optimization with /GL. So the correspondent function for "Profiler::a++/Profiler::b++" is inlined. One of the inlinee is InterlockedExchangeAdd64() which is written in inline-asm that uses EBX. But EBX is also used as parameter register. So the value of EBX is corrupted. That causes the access violation.

This should already be fixed in VS2013 RC.
Posted by Microsoft on 9/16/2013 at 4:32 AM
Thank you for submitting feedback on Visual Studio and .NET Framework. Your issue has been routed to the appropriate VS development team for investigation. We will contact you if we require any additional information.
Posted by Eternal Wind on 9/15/2013 at 9:55 PM
According to the one Mike suggested, I tried update 4 rc but still my issue is not solved.
Posted by Eternal Wind on 9/15/2013 at 7:49 PM
Saw that. Sorry for the duplication. I thought that one was not solved since it's closed with reason "cannot reproduce" when I saw.
Posted by Mike Danes on 9/15/2013 at 11:13 AM
Sounds similar to this: https://connect.microsoft.com/VisualStudio/feedback/details/791910/std-atomic-int64-t-compare-exchange-strong-can-crash-32-bit-code-by-overwriting-ebx
Posted by Microsoft on 9/15/2013 at 10:54 AM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)