VC6 - bug - I desparately need advice
-
Read my story, I desparately need advice. Spent the last 8 hours extracting a nasty release build problem from a huge app to a standalone project, reproducing the problem in ca. 40 lines of code (Whew!) Despite all my trust in Compiler and knowledge of C++ language pitfalls, and with all my debugging assembly experience I would say semi-proudly it is a bug in the optimizer. The problem - occurs only in Release Builds - occurs with various optimization settings (including the release-default) - with SP5 or SP6 installed - on 3 different Developer PC's - exposes an identical pattern of register misuse in all the iterations I took in isolating it - does NOT occur when no SP is installed (don't have other SP's avail) - does NOT occur on Standard edition (where no optimizer is included), independent of Service Pack - it is straightforward code (no templates, but a few classes ond some basic COM stuff is involved) I have an workaround for the one place I isolated, but we have multiple problems with identical occurence pattern. They all revolve around a central data class. Going back? They all surfaced not to long ago, but (a) I cannot safely determine the point of breakage, and (b) to many "pressing changes" have been included since. (Yes, we delayed finding these. Shame on us.) The repro code still relies on _com_ptr_t, and some (arbitrary) COM object. With all my C++ power I cannot see anything wrong with the code. options I see: - disabling optimizations (YUCK. SLOW is not an option) - going back to no service pack (I Don't want to) - MS Support indident (I will do, but I don't expect much as this is VC6) Any experiences with that? - Disabling optimizations while moving to VC7.1 (messy, no time, wanted to wait for VC 2005) Thank you for listening. Wish me Luck.
I never really know a killer from a savior
boost your code || Fold With Us! || sighist | doxygen -
Read my story, I desparately need advice. Spent the last 8 hours extracting a nasty release build problem from a huge app to a standalone project, reproducing the problem in ca. 40 lines of code (Whew!) Despite all my trust in Compiler and knowledge of C++ language pitfalls, and with all my debugging assembly experience I would say semi-proudly it is a bug in the optimizer. The problem - occurs only in Release Builds - occurs with various optimization settings (including the release-default) - with SP5 or SP6 installed - on 3 different Developer PC's - exposes an identical pattern of register misuse in all the iterations I took in isolating it - does NOT occur when no SP is installed (don't have other SP's avail) - does NOT occur on Standard edition (where no optimizer is included), independent of Service Pack - it is straightforward code (no templates, but a few classes ond some basic COM stuff is involved) I have an workaround for the one place I isolated, but we have multiple problems with identical occurence pattern. They all revolve around a central data class. Going back? They all surfaced not to long ago, but (a) I cannot safely determine the point of breakage, and (b) to many "pressing changes" have been included since. (Yes, we delayed finding these. Shame on us.) The repro code still relies on _com_ptr_t, and some (arbitrary) COM object. With all my C++ power I cannot see anything wrong with the code. options I see: - disabling optimizations (YUCK. SLOW is not an option) - going back to no service pack (I Don't want to) - MS Support indident (I will do, but I don't expect much as this is VC6) Any experiences with that? - Disabling optimizations while moving to VC7.1 (messy, no time, wanted to wait for VC 2005) Thank you for listening. Wish me Luck.
I never really know a killer from a savior
boost your code || Fold With Us! || sighist | doxygenAre you able to post those 40 lines of code that cause the problem. Perhaps another set of eyes can find something you missed (unlikely I know, but possible). Man, you really confused me when I replied and found your post had disappeared ;P
Ryan
"Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
-
Are you able to post those 40 lines of code that cause the problem. Perhaps another set of eyes can find something you missed (unlikely I know, but possible). Man, you really confused me when I replied and found your post had disappeared ;P
Ryan
"Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
Someone considered it a programming question it seems :) Well, I'm to tired to argue with anyone. I'll poke some other eyes and sticks on the code tomorrow. My main problem is that fixing that one place doesn't help me, and I don't expect another patch from Microsoft either :-/ OK, tomorrow. tired. cat wants food.
I never really know a killer from a savior
boost your code || Fold With Us! || sighist | doxygen -
Someone considered it a programming question it seems :) Well, I'm to tired to argue with anyone. I'll poke some other eyes and sticks on the code tomorrow. My main problem is that fixing that one place doesn't help me, and I don't expect another patch from Microsoft either :-/ OK, tomorrow. tired. cat wants food.
I never really know a killer from a savior
boost your code || Fold With Us! || sighist | doxygenBest Wishes... ;) - - - - - - - - - - - - - - - - - - - - - - - - Many nights we've prayed with no proof anyone could hear, we were moving moutains long before we knew we could ! Yet now i'm standing here, although we know there's much to fear, hope seemed like summer bird too swiftly flown away ... There can be miracles! When you believe, though hope is frail, it's hard to kill ! Who knows what miracles, you can achieve! When you believe, somehow you will ... YOU WILL WHEN YOU BELIEVE
-
Someone considered it a programming question it seems :) Well, I'm to tired to argue with anyone. I'll poke some other eyes and sticks on the code tomorrow. My main problem is that fixing that one place doesn't help me, and I don't expect another patch from Microsoft either :-/ OK, tomorrow. tired. cat wants food.
I never really know a killer from a savior
boost your code || Fold With Us! || sighist | doxygenpeterchen wrote: My main problem is that fixing that one place doesn't help me No, but it might reveal the construct that is causing the problem and a way to get around it. I've had situations where the compiler has simply crashed trying to compile moderately complex logic, and it took forever to isolate where the problem was. I've also had "Internal Compiler Error"s when I've accidentally used bitwise rather than logical operators in conditional expressions. Are you able to isolate which line of code (or near enough, considering the optimisation) causes the incorrect instructions?
Ryan
"Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
-
Read my story, I desparately need advice. Spent the last 8 hours extracting a nasty release build problem from a huge app to a standalone project, reproducing the problem in ca. 40 lines of code (Whew!) Despite all my trust in Compiler and knowledge of C++ language pitfalls, and with all my debugging assembly experience I would say semi-proudly it is a bug in the optimizer. The problem - occurs only in Release Builds - occurs with various optimization settings (including the release-default) - with SP5 or SP6 installed - on 3 different Developer PC's - exposes an identical pattern of register misuse in all the iterations I took in isolating it - does NOT occur when no SP is installed (don't have other SP's avail) - does NOT occur on Standard edition (where no optimizer is included), independent of Service Pack - it is straightforward code (no templates, but a few classes ond some basic COM stuff is involved) I have an workaround for the one place I isolated, but we have multiple problems with identical occurence pattern. They all revolve around a central data class. Going back? They all surfaced not to long ago, but (a) I cannot safely determine the point of breakage, and (b) to many "pressing changes" have been included since. (Yes, we delayed finding these. Shame on us.) The repro code still relies on _com_ptr_t, and some (arbitrary) COM object. With all my C++ power I cannot see anything wrong with the code. options I see: - disabling optimizations (YUCK. SLOW is not an option) - going back to no service pack (I Don't want to) - MS Support indident (I will do, but I don't expect much as this is VC6) Any experiences with that? - Disabling optimizations while moving to VC7.1 (messy, no time, wanted to wait for VC 2005) Thank you for listening. Wish me Luck.
I never really know a killer from a savior
boost your code || Fold With Us! || sighist | doxygenTry disabling optimizations using pragma's and sucessively narrow down the area where optimizations are disabled until you can isolate the line that the problem is on... then either fix the issue by re-writing the line or simply leave optimizations disabled for that specific line. steve