 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / Languages / Managed C++ / April 2006VS2005 major development bug
After spending more than a day reducing a complicated compiler bug to a simple case I reported it to the MSDN Product Feedback Center as a bug just now. However this bug is completely stymying my development of a VC++ component. Does Microsoft still offer any free bug reporting cases for VS2005, as they did two for VS2003 so that I can talk with a technical representative directly to try to find a workaround for the compiler bug ? While I would be normally willing to wait for a response from the bug report, the magnitude of the bug in my code, where the compiler is either producing wrong code or the vtable is being destroyed at run-time by the CLR system, is such that I am dead in the water until the bug is addressed. While I can continue searching for a workaround for the bug, for instance by switching from Managed C++ to C++/CLI and see if that causes any change so that the bug does not occur, if there is none I can find I must give up creating my code entirely. Therefore I am hoping that there is some way of addressing the problem directly with Microsoft without having to pay them directly just to fix their own bad code. > After spending more than a day reducing a complicated compiler bug to > a simple case I reported it to the MSDN Product Feedback Center as a [quoted text clipped - 15 lines] > problem directly with Microsoft without having to pay them directly > just to fix their own bad code. There's normally no charge for a support incident that's due to a bug in the product. You may have to pay for a support incident to get things rolling, but my understanding is that if it's confirmed to be due to a bug, they'll credit the charge back to you. If you're blocked from proceeding, you should contact PSS - that's the only way you'll get a hotfix to a current product. Reporting the bug through the feedback center may get it fixed in the next release of VC++, but it won't help you in the short term. If there's a small repro case (it sounds like you did develop one) that you could post here, perhaps someone can help find a workaround. I'm assuming that your feedback FDBK48932 is the bug in question - if you could post the files to the newgroup then we all could take a look. -cd > After spending more than a day reducing a complicated compiler bug to a > simple case I reported it to the MSDN Product Feedback Center as a bug > just now. Which Bug, haven't found one in your example only an access exception ? Change private: File: ValidationEdit.h Line: 34 into public: Then recompile your sample try to run it. Then retry to run your original sample and look which exception is thrown: ----->>>>>>> System.FieldAccessException To get detailed information by the compiler define your "pimpl" class outside the form. As I interpret the pimpl idiom, I would implement it in a CPP. > [...] I hope I haven't again misinterpreted your posts again ......... you remember ...... ? Or done something wrong ? If I have not misinterpreted your sample, have you another one ? Andre >> After spending more than a day reducing a complicated compiler bug to >> a simple case I reported it to the MSDN Product Feedback Center as a >> bug just now. > > Which Bug, haven't found one in your example only an access exception ? When and where ? Did you follow the instructions I gave in my bug report ? If you follow my bug report, when you step into the debugger and try to trace into "pimpl -> InitializeValidator();", which is line number 46 of ValidationEdit.cpp, you will see in the Disassembly window that it does not go to that routine but somewhere off of the WndProc routine instead. This od course causes an exception which is shown in the design window of the TestValidation project. > Change > [quoted text clipped - 6 lines] > > public: Line 34 in ValiditionEdit.h is a comment. /// Required designer variable. > Then recompile your sample try to run it. > > Then retry to run your original sample and look which exception is thrown: > > ----->>>>>>> System.FieldAccessException No other exception is thrown when I run my code in the debugger except in the design window specified. It is possible I do not have exception handling turned on in the debugger but I do not see debugger setting(s) which controls this. In Tools | Options | Debugging | General is there an option which controls whether or not an exception is picked up by the debugger ? Most of my options there are checked. > To get detailed information by the compiler define your "pimpl" class > outside the form. As I interpret the pimpl idiom, I would implement it > in a CPP. Please do not tell me how to program. The pimpl class is a nested class of my ref class so that it can access all of the members of my ref class when it is passed a ref class pointer. In the simple example this is not an issue but in the more common coding of mixed mode C++ programming in .NET, this is an easy way for a C++ native class to share code with its ref class. If it were not a nested class it could only access the public members of my corresponding ref class when passed a pointer to that ref class. I notice that in C++/CLI it is no longer allowed for a native C++ class to be a nested class of a ref class. Oh brother !!! How does a native C++ class which contains a good part of the actual functionality of a ref class now get to call and access protected and private members of its corresponding ref class in C++/CLI ? > > [...] > > I hope I haven't again misinterpreted your posts again ......... you > remember ...... ? Or done something wrong ? I am not getting the exception you mentioned. Your line number is incorrect. I know how to program and don't need to be told how to use the pimpl idiom. Other than that I do very much appreciate your help. >>> After spending more than a day reducing a complicated compiler bug to >>> a simple case I reported it to the MSDN Product Feedback Center as a [quoted text clipped - 3 lines] > > When and where ? Did you follow the instructions I gave in my bug report I simply compiled your sample you've attached to a post in this thread and it crashed. > ? If you follow my bug report, when you step into the debugger and try > to trace into "pimpl -> InitializeValidator();", which is line number 46 > of ValidationEdit.cpp, you will see in the Disassembly window that it > does not go to that routine but somewhere off of the WndProc routine > instead. This od course causes an exception which is shown in the design > window of the TestValidation project. Exactly. I haven't debugged the sample into depth, but as I would interpret it the .NET runtime checks if the embedded class has access to the outer class, ValidationEdit and as it's forbidden to access private members from another class (friend declaration don't work also), it simply throws a security exception. >> [...] >> ----->>>>>>> System.FieldAccessException > > No other exception is thrown when I run my code in the debugger except Your application (attached to your newsgroup post) crashs, with a failure report stating that an uncaught system access exception has been thrown. It won't throw that exception if you make the class >> To get detailed information by the compiler define your "pimpl" class >> outside the form. As I interpret the pimpl idiom, I would implement it >> in a CPP. > > Please do not tell me how to program. The pimpl class is a nested class > of my ref class so that it can access all of the members of my ref class I only mentioned that IMHO a nested class is not the pimpl idiom I read about in Lakos book, but may be that there are different "pimpl" idioms. You may name the variable so, but may be somewhat confusing. > I notice that in C++/CLI it is no longer allowed for a native C++ class It seems that this is also true (now ?) for managed cpp. Don't know if the compiler should rather throw a compile time error instead of runtime error. The sample will also run if you don't access the member variable initializing directly, but use a public member method: rClass->IsInitializing() > to be a nested class of a ref class. Oh brother !!! How does a native > C++ class which contains a good part of the actual functionality of a [quoted text clipped - 8 lines] > I am not getting the exception you mentioned. Your line number is > incorrect. Sorry, must have been moved downwards, because I edited the code somewhat, checking the access restrictions. the lines are: 32 private: 33 /// <summary> 34 /// Required designer variable. 35 /// </summary> If you temporarily change line 32 into public the sample doesn't crash, at least on my computer / my IDE. > I know how to program and don't need to be told how to use > the pimpl idiom. Other than that I do very much appreciate your help. You have blamed me not knowing C++ very well too, some months ago. I'll forget about that from now on, but I couldn't resist to make some notes about pimpl in my previous post. And you are using still managed CPP, although you have made such a bad experience about it, regarding the loader lock. It hasn't directly something to do with managed CPP itself, but wouldn't it be better to port to C++/CLI ? Regarding the crash in your sample, C++/CLI seems to throw a compile time error, while managed cpp silently compiles, but seems to have the same restrictions (at runtime), as C++/CLI. As I interpret the problem, the compiler should rather throw a compile time error, instead of throwing an exception at runtime. So you should perhaps change your bug report in this regard. Andre >>>> After spending more than a day reducing a complicated compiler bug >>>> to a simple case I reported it to the MSDN Product Feedback Center [quoted text clipped - 6 lines] > I simply compiled your sample you've attached to a post in this thread > and it crashed. If you had used the project which was in the .zip file you would have seen that it was compiled with Managed C++ and not C++/CLI, and that it compiles fine. >> ? If you follow my bug report, when you step into the debugger and try >> to trace into "pimpl -> InitializeValidator();", which is line number [quoted text clipped - 8 lines] > members from another class (friend declaration don't work also), it > simply throws a security exception. No in Managed C++. >>> [...] >>> ----->>>>>>> System.FieldAccessException [quoted text clipped - 17 lines] > about in Lakos book, but may be that there are different "pimpl" idioms. > You may name the variable so, but may be somewhat confusing. In normal C++ programming a pimpl class does not have to be a nested class because one can use the 'friend' declaration to allow the pimpl class to access all of the members of the other class if necessary. Because C++ .NET does not allow 'friend', the solution to this in Managed C++ was to make the pimpl class a nested class of the ref class and pass a pointer of the ref class to the pimpl class. However even the ability to have a pimpl nested native class of a ref class has been taken away in C++/CLI. That is not progress but regress. See my other post and the only solution I have found for this. >> I notice that in C++/CLI it is no longer allowed for a native C++ class > [quoted text clipped - 6 lines] > > rClass->IsInitializing() While I appreciate your workarounds, my actual code is far more complicated than my simple sample and the point of posting my bug was to have someone else ascertain that the bug actually exists on their machine also. This you did not do because you did not use the solutions/projects in my zip file. Instead you created your own solutions/projects, added my source file, then told me what you found. That is not the way to test someone else's bug. >> to be a nested class of a ref class. Oh brother !!! How does a native >> C++ class which contains a good part of the actual functionality of a [quoted text clipped - 35 lines] > throw a compile time error, while managed cpp silently compiles, but > seems to have the same restrictions (at runtime), as C++/CLI. I am using Managed C++ because I had a ton of mixed-mode code I developed for VS2003 in C++, but never ran because of the loader-lock bug, and I first wanted to move that code to VS2005 and try to build and run it. However because of this bug, and the assumption that MS will not be too interested in fixing bugs in Managed C++ code generation, I am forced to change my code to use C++/CLI immediately. Changing my sample to use C++/CLI I see that everything works perfectly. For me this bug is the final chapter of the Managed C++ fiasco, including the destructive loader-lock bug in VS2003, other bugs I reported to MS regarding Managed C++ and VS2003, and now this horrendous bug with Managed C++ and VS2005. All in all a hideous example of computer programming by the VC++ team. I am moving to C++/CLI and hopefully my efforts to use .NET programming with C++ will now be much better. It could not be worse than it is has been with Managed C++. I am truly sorry for Microsoft having put out such bad technology as Managed C++. They are usually a company that does not make such mistakes. Hi Edward! > For me this bug is the final chapter of the Managed C++ fiasco, I agree... I also know of other (small) bugs in /clr:oldsyntax... But I am also happy that the new syntax is simpler and hopefully durable... but I also now need to move about 3000 lines of code to C++/CLI... ;-(  SignatureGreetings Jochen My blog about Win32 and .NET http://blog.kalmbachnet.de/ Hi Jochen, > Hi Edward! > >> For me this bug is the final chapter of the Managed C++ fiasco, > > I agree... I also know of other (small) bugs in /clr:oldsyntax... Please do me a favor. It seems that I and Edward are discussing cross-purposes. Take Edwards example and verify that the bug is due to some new (???) security restrictions. Take the attached 2 projects in the ZIP file. Compile them and verify that the project crashs running it outside the IDE (or started without debugger). Then change a single line of code: File: ValidationEdit.h Line: 32 Change: private: into: public: Recompile the component and then the form and restart it again. It shouldn't crash anymore. Please write your results in this thread. Thank you very much in advance. > But I am also happy that the new syntax is simpler and hopefully > durable... but I also now need to move about 3000 lines of code to > C++/CLI... ;-( IMHO they should have started with C++/CLI at the beginning. But they wanted it to make it C++ standard compliant. By using __ double underscores and not introducing new keywords, without underscores. Many developers complained about that syntax and what was even worse, that managed objects couldn't be differentiated from native objects in template functions and classes. IMHO now they got it right now, but they are now accused (by C++ ISO members) having done so. That it's not C++ anymore and that the name C++/CLI implies it to be so - an advanced C++ standard. And that it's slowly polluting the C++ standard. You'll never can make it right for all developers :-/ Andre >> I simply compiled your sample you've attached to a post in this thread >> and it crashed. > > If you had used the project which was in the .zip file you would have > seen that it was compiled with Managed C++ and not C++/CLI, and that it > compiles fine. The DEBUG configuration compiles fine and then crashs after it is started. Where did I wrote something about C++/CLI ? Crashing during compilation would mean then compiler to throw an ICE, but that's surely not the case. >> Exactly. I haven't debugged the sample into depth, but as I would >> interpret it the .NET runtime checks if the embedded class has access [quoted text clipped - 3 lines] > > No in Managed C++. Yes in managed C++ it compiles rewritten in C++/CLI it compiles not. That is the main problem. When the managed version is run and the native object tries to access a private method of the managed object the runtime throws an System.FieldAccessException. > In normal C++ programming a pimpl class does not have to be a nested No problem with that. > class because one can use the 'friend' declaration to allow the pimpl > class to access all of the members of the other class if necessary. I just wondered why you defined the class members in the header. Pimpl, is commonly used or is designed to decouple objects. Therefore the class is only declared in the header. public __gc class ValidationEdit : ...... { ......... __nogc class ValidationEditPimpl; }; And defined in the CPP unit. But I don't want to be pedantic and this has nothing to do with the problem / bug we are discussing in this thread about. > Because C++ .NET does not allow 'friend', the solution to this in > Managed C++ was to make the pimpl class a nested class of the ref class > and pass a pointer of the ref class to the pimpl class. However even the > ability to have a pimpl nested native class of a ref class has been > taken away in C++/CLI. And it has been taken away for managed C++ too. Except that it compiles, but throws a runtime error. While in C++/CLI the compiler, as you wrote, will throw an error at compilation time. > That is not progress but regress. It seems that this has nothing to do with C++/CLI itself. But rather with the code generation / runtime itself. There must have been some security reasons for this change. > See my other > post and the only solution I have found for this. > While I appreciate your workarounds, my actual code is far more > complicated than my simple sample and the point of posting my bug was to > have someone else ascertain that the bug actually exists on their > machine also. This you did not do because you did not use the > solutions/projects in my zip file. I did. > Instead you created your own > solutions/projects, added my source file, then told me what you found. > That is not the way to test someone else's bug. I have not, why should I do so ? You are making assumptions, which you have in another discussion accused me (always) to do so. So: Take your example posted in this newsgroup. Make all private variables in class ValidationEdit public, as I already wrote, by changing a single line of code: File: ValidationEdit.h Line: 32 private: /// <summary> /// Required designer variable. /// </summary> System::ComponentModel::Container* components; into: public: /// <summary> /// Required designer variable. /// </summary> System::ComponentModel::Container* components; Then recompile your control and test it. I did no >>>> other <<<< changes to your project and I used your project configuration. > I am using Managed C++ because I had a ton of mixed-mode code I > developed for VS2003 in C++, but never ran because of the loader-lock [quoted text clipped - 3 lines] > However because of this bug, and the assumption that MS will not be too > interested in fixing bugs in Managed C++ code generation, IMHO they cannot fix it, because it's a runtime restriction. They could however throw an error at compilation time. > I am forced to > change my code to use C++/CLI immediately. IMHO it would be the same in managed C++ if you change your code. But anyways directly porting to C++/CLI is the better way to go. > Changing my sample to use > C++/CLI I see that everything works perfectly. [quoted text clipped - 3 lines] > reported to MS regarding Managed C++ and VS2003, and now this horrendous > bug with Managed C++ and VS2005. The bug is, that the compiler doesn't throw an error at compilation time. A nested class seems not to be allowed anymore to access private members of a managed class. This is true for C++/CLI as it's true for managed C++. > [...] Andre >>> I simply compiled your sample you've attached to a post in this >>> thread and it crashed. [quoted text clipped - 20 lines] > object tries to access a private method of the managed object the > runtime throws an System.FieldAccessException. Where does this happen when executing my code example ? >>>> I simply compiled your sample you've attached to a post in this >>>> thread and it crashed. [quoted text clipped - 22 lines] > > Where does this happen when executing my code example ? Somewhere inside the function call: pimpl -> InitializeValidator(); I suppose it's the line: if (!init_val && rClass -> initializing) if I change this line to: if (!init_val) and recompile both solutions everything seems to be OK and a form with only an edit box is displayed. I suppose this to be the correct behavior you would expect ? There seems to be some assembly code before the function's code checking perhaps if the class may be accessed, but I can't step into it since the "auto" mode doesn't stop at the line I want to and the native only debug mode crashs :-(. Anyway it's a bug and it's a good idea, as you did, to convert managed C++ code to C++/CLI. Since the compiler then seems to correctly complain about the problem at compilation time. Good luck to you, that you won't run into any (such) trouble again. Andre >>>>> I simply compiled your sample you've attached to a post in this >>>>> thread and it crashed. [quoted text clipped - 26 lines] > > pimpl -> InitializeValidator(); When I debug the code and this call is made, the code goes to somewhere after the beginning of the WndProc routine instead. Try going into the disassembly, when you stop the debugger at the above line, and you will see this happening. This is exactly what I reported in the bug report. >>>[...] >>> Where does this happen when executing my code example ? [quoted text clipped - 5 lines] > When I debug the code and this call is made, the code goes to somewhere > after the beginning of the WndProc routine instead. Not here on my machine. When I try to step into the function call a System.FieldAccessViolation is thrown, in the Debug configuration. The Release configuration runs without any problems (???) and doesn't throw the exception anymore. Seems to be everything O.K. with the Release. Perhaps another one here in this newsgroup should try to reproduce my or your behavior, since MS might have the same behavior as I have and won't address the problem. > Try going into the disassembly, when you stop the debugger > at the above line, and you will > see this happening. This is exactly what I reported > in the bug report. I can't. Either the exception is thrown directly, when I try to step into the code (auto mode), or if I switch to native (or managed or mixed) debugging mode, the debugger stops somewhere in Heap Free. This behavior might be caused, because an exception (in my case) is thrown in the Forms constructor and corrupts either the heap, because some code is dealing with invalid handles / pointers or because the debugger deals with corrupted data and doesn't show valid results. Try to encapsulate the function call with a try {} catch(...) E.g.: try { pimpl -> InitializeValidator(); } catch(...) { System::Windows::Forms::MessageBox::Show("Exception"); } What happens on your system, when you start the compiled assembly outside the debugger ? Andre > >>>[...] >>>> Where does this happen when executing my code example ? [quoted text clipped - 23 lines] > into the code (auto mode), or if I switch to native (or managed or > mixed) debugging mode, the debugger stops somewhere in Heap Free. I do not understand this "auto mode" or "native mode" or "managed or mixed" debugging mode. What are these in the IDE ? Is this something I have to turn on or off from the debugger options ? When the breakpoint in the code stops at the 'pimpl -> Initializevalidator() line' why can you not open the Disassembly window and step through the code there ? > This behavior might be caused, because an exception (in my case) is > thrown in the Forms constructor and corrupts either the heap, because > some code is dealing with invalid handles / pointers or because the > debugger deals with corrupted data and doesn't show valid results. How do you know that an exception is being thrown in the Forms constructor if you do not see it when stepping through the code in the debugger ? > Try to encapsulate the function call with a try {} catch(...) > [quoted text clipped - 11 lines] > What happens on your system, when you start the compiled assembly > outside the debugger ? This is meaningless since, as I have stated, if the 'pimpl -> Initializevalidator()' goes to the wrong code completely of course some exception will be thrown. What I am trying to tell you is what I wrote in my bug report. If you try to step into 'pimpl -> Initializevalidator()' you will see that it goes to some place near the beginning of the WndProc routine. You may be right in what you have conjectured as the reason this happens, but it is still a bug in the product, as is any situation where code generation is incorrect. > I do not understand this "auto mode" or "native mode" or "managed or > mixed" debugging mode. What are these in the IDE ? Is this something I > have to turn on or off from the debugger options ? It's the setting of the Project Properties - Configuration Properties - Debugging - Debugger Type. Where you can select which debugger to start. By default "Auto" is selected, but sometimes I cannot step into machine code, when debugging a managed application. I'll then switch to either "Mixed" or "Native Only" debugger. > When the breakpoint in the code stops at the 'pimpl -> > Initializevalidator() line' why can you not open the Disassembly window > and step through the code there ? I don't know why I cannot step into the machine code in the disassembly window, or better said into a "function call". As soon as I try an exception is thrown or if I use the "Mixed" debugger it executes the call instruction and stops somewhere in the heap manager with the following output: "First-chance exception at 0x7c81eb33 in TestValidation.exe: Microsoft C++ exception: [rethrow] at memory location 0x00000000.." With the native debugger I should be able to step into the code anyways, but it doesn't stop and just after the I've started the debugger it disables the breakpoint I've set :-(( >> This behavior might be caused, because an exception (in my case) is >> thrown in the Forms constructor and corrupts either the heap, because [quoted text clipped - 4 lines] > constructor if you do not see it when stepping through the code in the > debugger ? That's my problem, I try to step through the function call, but instead single stepping the debugger executes all the code I want to step into and throws the exception. >> Try to encapsulate the function call with a try {} catch(...) >> [quoted text clipped - 15 lines] > Initializevalidator()' goes to the wrong code completely of course some > exception will be thrown. Perhaps the debugger doesn't work correctly and you get different results when you run the application without a debugger ? The debugger may show wrong results too. Just give it a try. > What I am trying to tell you is what I wrote > in my bug report. If you try to step into 'pimpl -> > Initializevalidator()' you will see that it goes to some place near the > beginning of the WndProc routine. I only wonder what has the code generation bug to do with if I access a variable or not or if I make all variables public instead of private ? If I make all variables public then the same error should occur ? But it's gone - no exception is thrown and the correct function is called. > You may be right in what you have > conjectured as the reason this happens, but it is still a bug in the > product, as is any situation where code generation is incorrect. May be I've got different results than you for what reason ever. All I did is downloading your sample code, compiling and starting it. But others may have different results too. Very weird bug. Andre Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.