release builds causes exceptions to be uncaught - by Laibalion

Status : 


Sign in
to vote
ID 790381 Comments
Status Active Workarounds
Type Bug Repros 0
Opened 6/18/2013 7:43:14 AM
Access Restriction Public


When building Release|Win32 configuration with cross dll boundary exceptions, causes the throw exception not to be caught by the provided catch block.
I have a attached a small VS2012 solution to reproduce the problem. It contains 2 vcxproj files:

ClassLibrary1: contains 2 classes. The first is a custom exception MyException, that inherits from std::exception, and just stores a given bool. The second class is a worker class which has 1 public inlined work method and 1 private work method. The public method forwards the call to the private method. The private method will always throw MyException.
TestConsole: contains a simple c++ console application that creates a worker object from the second project and let is do some work in a try-catch statement. The catch statement catches the exception of type MyException.

When building in Debug|Win32 this works correctly. When building Release|Win32, the catch block is never executed and results in a uncaught exception. It seems to be related to the inline statements for public method of the Worker class. If it's implemented as non-inline, it works correctly for release as well.

This example is just a simplified reproduction of real production code in our c++ back-end, so the problem is not pure academic.

This should not be this way. Release and Debug should both catch the thrown exception.

*My apologies for the confusing file attachments. For the solution to reproduce, use the most recent The other one may not open correctly.
Sign in to post a comment.
Posted by Laibalion on 7/31/2013 at 12:15 PM
Awesome, great news!
Many thanks, looking forward to it :).

Kind regards,
Posted by Microsoft on 7/31/2013 at 8:37 AM
This will be in VSUpdate4 RTM. I just checked it in yesterday :-)

Posted by Laibalion on 7/31/2013 at 2:45 AM
Hi Eric,

I noticed that VS2012 Update4 RC1 has been released. Unfortunately the list of issues that it fixed ( does not mention anything about fixing this compiler bug.
Is this because the list is not exhaustive or because it is not included?
In case it is not included, any chance that it will make it into the RTM release?

Kind regards and thanks in advance,
Geert Bleyen
Posted by Laibalion on 7/18/2013 at 2:31 AM
Hi Eric,

This would be highly appreciated. Already looking forward to Update 4 (and hoping this gets included in it :-) ).

Thanks and kind regards,
Geert Bleyen
Posted by Microsoft on 7/17/2013 at 2:31 PM
Hi, I will do my best to have fixed this in VS2012 VSUpdate 4.

Posted by Laibalion on 7/9/2013 at 1:41 PM
Hi Eric,

does this mean this won't be fixed in VS2012 (in which we discovered it)?

We noticed this behaviour during migrating our codebase (aprox. 2.5 millions lines of code) from VS2010 to VS2012.
If it only gets fixed in VS2013, this means yet another migration to VS2013, which means new installer configuration, new runtimes, fixing new compile/link issues, rebuilding thirdparty libraries, ... . I'm sure you can see this is not something that can be done easily.

One workaround is indeed not to write these methods inline, but this is not always in our control. Some VC STL (and most likely winapi calls) implementations are inlined, and finding all of these occurrences is quite time consuming. So we had to go for another workaround.
Currently we have to enable 'Safe Exception Handling' for the compiler, which in turn forces us to enable /bigobj in the linker, which leads to longer buildtimes. This impacts not only our codebase, but also those of other products in my company (another couple millions lines of code).

So I really hope it would be possible to have this fixed in VS2012 as well (*fingers-crossed*)

Thanks and kind regards,
Geert Bleyen.
Posted by Microsoft on 7/9/2013 at 1:19 PM
Hi, thanks for the great test case showing the bug. I confirm this is a bug where the compiler is incorrectly removing a catch block. We will try our best to fix this for VS2013, but if that fails it will be fixed in the first VSUpdate.

Like you mentioned, if you need a source code workaround, you can change worker::work() to _not_ be inline. In other words:

/* inline -- temporary workaround until compiler bug fixed */ void worker::work()

I am closing this MSConnect item. Feel free to re-activate it if you need any more info.

Eric Brumer
Microsoft Visual C++ Team
Posted by Laibalion on 6/18/2013 at 8:05 AM
My apologies for the confusing file attachments. For the solution to reproduce, use the most recent The other one may not open correctly.
Posted by Microsoft on 6/18/2013 at 7:50 AM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(