"Problems"
in [MFC]
|
From: William on 12 Feb 2010 14:43 Joeseph Newcomer said: "Generally, when problems arise when you are starting an app, it means you are doing something that ends up being out-of-sequence with its preconditions." Perhaps. Late to the party but I wanted to add my experience with VS 2008 and dialogs from extension dlls. Its not at all out of the question sometimes that the framework itself is simply wrong (or buggy). Simply laying every problem at the feet of users is an expedient way out of a question, often correct, but not always. For example; extension dlls. We have known for years that the AFX_MANAGE_STATE macro was responsible for exposing the resource layer of a dll to the parent thread; using dialogs within extension dlls is something I've been doing from the vs 1.5 days. Then I start using 2008 and this same basic operation goes haywire with an assert from the ENSURE check in objcore.cpp. Release mode is fine. Horrified at the prospect of trying to maintain release-only code I did a little research and found that if I simply unwrapped the macro to "AfxSetResourceHandle(AfxGetStaticModuleState()->m_hCurrentResourceHandle);" both release and debug versions of my source work fine. Digging into afxstate_.h and some of the other mfc core routines didn't yield any reasonable explanation to me of why the ENSURE got tripped, none at all. Perhaps the esteemed Mr. Newcomer can explain it. Joseph M. Newcomer wrote: Generally, when problems arise when you are starting an app, it means you are 29-Oct-07 Generally, when problems arise when you are starting an app, it means you are doing something that ends up being out-of-sequence with its preconditions. So you have to figure out what is out of sequence. A side effect of creating the console is that something is invoked that causes a sequence of actions that tries to use a NULL pointer. Creating a console seems an odd thing to do. Is there a good reason for it? (Note that "debug output" is not a good reason) joe On Mon, 29 Oct 2007 13:28:05 -0000, chhenning <chhenning(a)gmail.com> wrote: Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm Previous Posts In This Thread: On Friday, October 26, 2007 9:58 AM chhenning wrote: Annoying assertion in objcore.cpp Hi there, every time I start my debug executable I'm receiving this annoying assertion (popup) in objcore.cpp[40]. Basically the creation of a CConsole is failing for whatever reason. Is there anyway to get rid this assertion? Thanks ahead, Christian On Friday, October 26, 2007 10:56 PM Joseph M. Newcomer wrote: No, it is not failing for "some reason". No, it is not failing for "some reason". It is failing for a very explicit reason, and if you look at line 40 of objcore.cpp, it will demonstrate what this reason is! Note that there are three different versions of MFC in existence: VS6, VS .NET 2003 and VS2005, and I don't feel like looking every single one of them, but in the VS.NET 2003 there is a line 39 that says ASSERT(this != NULL); which would make it pretty obvious what is wrong. The next line, line 41, says ASSERT(AfxIsValidAddres(this)); so all you need to do is look at the value of 'this', then go back to your code and see where it was called, and see why 'this' is either NULL or an invalid address. joe On Fri, 26 Oct 2007 13:58:09 -0000, chhenning <chhenning(a)gmail.com> wrote: Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm On Monday, October 29, 2007 9:28 AM chhenning wrote: Hi Joseph, thanks for your answer. Hi Joseph, thanks for your answer. I, of course, did the check why the this pointer is NULL but I'm failing to see how it can be my fault. Looking at stack it all begins when creating a console. The location is server.cpp[476]. I think I wrote in my last email that all this happens when starting the application. I was actually hoping that other people have the same problem and there is a simple solution. I'm using VS2005. I should probably mention that the application is a COM server. Hope there is a solution, Christian On Oct 26, 10:56 pm, Joseph M. Newcomer <newco...(a)flounder.com> wrote: On Monday, October 29, 2007 9:08 PM Joseph M. Newcomer wrote: Generally, when problems arise when you are starting an app, it means you are Generally, when problems arise when you are starting an app, it means you are doing something that ends up being out-of-sequence with its preconditions. So you have to figure out what is out of sequence. A side effect of creating the console is that something is invoked that causes a sequence of actions that tries to use a NULL pointer. Creating a console seems an odd thing to do. Is there a good reason for it? (Note that "debug output" is not a good reason) joe On Mon, 29 Oct 2007 13:28:05 -0000, chhenning <chhenning(a)gmail.com> wrote: Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm Submitted via EggHeadCafe - Software Developer Portal of Choice SharePoint List Usage and Statistics http://www.eggheadcafe.com/tutorials/aspnet/892bae83-5b96-4275-95fd-9723a79fdb14/sharepoint-list-usage-and.aspx
From: Stephen Myers on 12 Feb 2010 15:42 William Ross wrote: > Joeseph Newcomer said: "Generally, when problems arise when you are starting an app, it means you are doing > something that ends up being out-of-sequence with its preconditions." > > Perhaps. Late to the party but I wanted to add my experience with VS 2008 and dialogs from extension dlls. Its not at all out of the question sometimes that the framework itself is simply wrong (or buggy). Simply laying every problem at the feet of users is an expedient way out of a question, often correct, but not always. > > For example; extension dlls. We have known for years that the AFX_MANAGE_STATE macro was responsible for exposing the resource layer of a dll to the parent thread; using dialogs within extension dlls is something I've been doing from the vs 1.5 days. Then I start using 2008 and this same basic operation goes haywire with an assert from the ENSURE check in objcore.cpp. Release mode is fine. Horrified at the prospect of trying to maintain release-only code I did a little research and found that if I simply unwrapped the macro to > "AfxSetResourceHandle(AfxGetStaticModuleState()->m_hCurrentResourceHandle);" both release and debug versions of my source work fine. Digging into afxstate_.h and some of the other mfc core routines didn't yield any reasonable explanation to me of why the ENSURE got tripped, none at all. Perhaps the esteemed Mr. Newcomer can explain it. > > > > Joseph M. Newcomer wrote: > > Generally, when problems arise when you are starting an app, it means you are > 29-Oct-07 > > Generally, when problems arise when you are starting an app, it means you are doing > something that ends up being out-of-sequence with its preconditions. So you have to > figure out what is out of sequence. A side effect of creating the console is that > something is invoked that causes a sequence of actions that tries to use a NULL pointer. > > Creating a console seems an odd thing to do. Is there a good reason for it? (Note that > "debug output" is not a good reason) > joe > > On Mon, 29 Oct 2007 13:28:05 -0000, chhenning <chhenning(a)gmail.com> wrote: > > Joseph M. Newcomer [MVP] > email: newcomer(a)flounder.com > Web: http://www.flounder.com > MVP Tips: http://www.flounder.com/mvp_tips.htm > > Previous Posts In This Thread: > > On Friday, October 26, 2007 9:58 AM > chhenning wrote: > > Annoying assertion in objcore.cpp > Hi there, every time I start my debug executable I'm receiving this > annoying assertion (popup) in objcore.cpp[40]. Basically the creation > of a CConsole is failing for whatever reason. Is there anyway to get > rid this assertion? > > Thanks ahead, > Christian > > On Friday, October 26, 2007 10:56 PM > Joseph M. Newcomer wrote: > > No, it is not failing for "some reason". > No, it is not failing for "some reason". It is failing for a very explicit reason, and if > you look at line 40 of objcore.cpp, it will demonstrate what this reason is! > > Note that there are three different versions of MFC in existence: VS6, VS .NET 2003 and > VS2005, and I don't feel like looking every single one of them, but in the VS.NET 2003 > there is a line 39 that says > ASSERT(this != NULL); > which would make it pretty obvious what is wrong. The next line, line 41, says > ASSERT(AfxIsValidAddres(this)); > > so all you need to do is look at the value of 'this', then go back to your code and see > where it was called, and see why 'this' is either NULL or an invalid address. > joe > > On Fri, 26 Oct 2007 13:58:09 -0000, chhenning <chhenning(a)gmail.com> wrote: > > Joseph M. Newcomer [MVP] > email: newcomer(a)flounder.com > Web: http://www.flounder.com > MVP Tips: http://www.flounder.com/mvp_tips.htm > > On Monday, October 29, 2007 9:28 AM > chhenning wrote: > > Hi Joseph, thanks for your answer. > Hi Joseph, thanks for your answer. I, of course, did the check why the > this pointer is NULL but I'm failing to see how it can be my fault. > Looking at stack it all begins when creating a console. The location > is server.cpp[476]. I think I wrote in my last email that all this > happens when starting the application. I was actually hoping that > other people have the same problem and there is a simple solution. > > I'm using VS2005. I should probably mention that the application is a > COM server. > > Hope there is a solution, > Christian > > On Oct 26, 10:56 pm, Joseph M. Newcomer <newco...(a)flounder.com> wrote: > > On Monday, October 29, 2007 9:08 PM > Joseph M. Newcomer wrote: > > Generally, when problems arise when you are starting an app, it means you are > Generally, when problems arise when you are starting an app, it means you are doing > something that ends up being out-of-sequence with its preconditions. So you have to > figure out what is out of sequence. A side effect of creating the console is that > something is invoked that causes a sequence of actions that tries to use a NULL pointer. > > Creating a console seems an odd thing to do. Is there a good reason for it? (Note that > "debug output" is not a good reason) > joe > > On Mon, 29 Oct 2007 13:28:05 -0000, chhenning <chhenning(a)gmail.com> wrote: > > Joseph M. Newcomer [MVP] > email: newcomer(a)flounder.com > Web: http://www.flounder.com > MVP Tips: http://www.flounder.com/mvp_tips.htm > > > Submitted via EggHeadCafe - Software Developer Portal of Choice > SharePoint List Usage and Statistics > http://www.eggheadcafe.com/tutorials/aspnet/892bae83-5b96-4275-95fd-9723a79fdb14/sharepoint-list-usage-and.aspx I'd be curious to see the offending code. We use the AFX_MANAGE_STATE macro extensively in our regular DLLs and have had no particular problem migrating from VS 2003 to VS 2008. I do know that the macro placement is critical. I know this doesn't do anything for your problem, just my 2 cents. Steve
From: Joseph M. Newcomer on 12 Feb 2010 23:13 On Fri, 12 Feb 2010 11:43:04 -0800, William Ross wrote: > >Joeseph Newcomer said: "Generally, when problems arise when you are starting an app, it means you are doing >something that ends up being out-of-sequence with its preconditions." > >Perhaps. Late to the party but I wanted to add my experience with VS 2008 and dialogs from extension dlls. Its not at all out of the question sometimes that the framework itself is simply wrong (or buggy). Simply laying every problem at the feet of users is an expedient way out of a question, often correct, but not always. > >For example; extension dlls. We have known for years that the AFX_MANAGE_STATE macro was responsible for exposing the resource layer of a dll to the parent thread; using dialogs within extension dlls is something I've been doing from the vs 1.5 days. Then I start using 2008 and this same basic operation goes haywire with an assert from the ENSURE check in objcore.cpp. Release mode is fine. Horrified at the prospect of trying to maintain release-only code I did a little research and found that if I simply unwrapped the macro to >"AfxSetResourceHandle(AfxGetStaticModuleState()->m_hCurrentResourceHandle);" both release and debug versions of my source work fine. Digging into afxstate_.h and some of the other mfc core routines didn't yield any reasonable explanation to me of why the ENSURE got tripped, none at all. Perhaps the esteemed Mr. Newcomer can explain it. > > If there were an example I could reproduce, I could analyze it and tell what is going wrong. This has a bit of the flavor of "if I remove the ASSERT statement it no longer asserts" which isn't really solving the problem. By removing the test, you allow it to silently fail, but it is probably still failing. The other classic surprise is "I don't get errors in release mode, but I get all these annoying ASSERTs in debug mode, what's wrong?" and what's usually wrong is the code is incorrect. Since the code is incorrect, removing the error checks does not make the code correct, it merely disguises the fact that an error exists. Consequently, until I can analyze the problem, there is no way I can say that the solution you give here is an acceptable solution. (For example: do any of the reports of the error give a complete stack traceback to the line of source that caused the error? Without that, the analysis-no, cancel that, there *isn't any* analysis-without that, it is meaningless to conjecture as to what is happening.) You don't solve problems by removing error checks, you remove them by solving the cause of the problem. And without a reproducible example, I can't tell what the root cause might be. It *might* be a bug in MFC, but I would first suspect erroneous application code. Only after I had studied the problem in detail would I make a decision about whether or not it was a real MFC error. joe > >Joseph M. Newcomer wrote: > >Generally, when problems arise when you are starting an app, it means you are >29-Oct-07 > >Generally, when problems arise when you are starting an app, it means you are doing >something that ends up being out-of-sequence with its preconditions. So you have to >figure out what is out of sequence. A side effect of creating the console is that >something is invoked that causes a sequence of actions that tries to use a NULL pointer. > >Creating a console seems an odd thing to do. Is there a good reason for it? (Note that >"debug output" is not a good reason) > joe > >On Mon, 29 Oct 2007 13:28:05 -0000, chhenning <chhenning(a)gmail.com> wrote: > >Joseph M. Newcomer [MVP] >email: newcomer(a)flounder.com >Web: http://www.flounder.com >MVP Tips: http://www.flounder.com/mvp_tips.htm > >Previous Posts In This Thread: > >On Friday, October 26, 2007 9:58 AM >chhenning wrote: > >Annoying assertion in objcore.cpp >Hi there, every time I start my debug executable I'm receiving this >annoying assertion (popup) in objcore.cpp[40]. Basically the creation >of a CConsole is failing for whatever reason. Is there anyway to get >rid this assertion? > >Thanks ahead, >Christian > >On Friday, October 26, 2007 10:56 PM >Joseph M. Newcomer wrote: > >No, it is not failing for "some reason". >No, it is not failing for "some reason". It is failing for a very explicit reason, and if >you look at line 40 of objcore.cpp, it will demonstrate what this reason is! > >Note that there are three different versions of MFC in existence: VS6, VS .NET 2003 and >VS2005, and I don't feel like looking every single one of them, but in the VS.NET 2003 >there is a line 39 that says > ASSERT(this != NULL); >which would make it pretty obvious what is wrong. The next line, line 41, says > ASSERT(AfxIsValidAddres(this)); > >so all you need to do is look at the value of 'this', then go back to your code and see >where it was called, and see why 'this' is either NULL or an invalid address. > joe > >On Fri, 26 Oct 2007 13:58:09 -0000, chhenning <chhenning(a)gmail.com> wrote: > >Joseph M. Newcomer [MVP] >email: newcomer(a)flounder.com >Web: http://www.flounder.com >MVP Tips: http://www.flounder.com/mvp_tips.htm > >On Monday, October 29, 2007 9:28 AM >chhenning wrote: > >Hi Joseph, thanks for your answer. >Hi Joseph, thanks for your answer. I, of course, did the check why the >this pointer is NULL but I'm failing to see how it can be my fault. >Looking at stack it all begins when creating a console. The location >is server.cpp[476]. I think I wrote in my last email that all this >happens when starting the application. I was actually hoping that >other people have the same problem and there is a simple solution. > >I'm using VS2005. I should probably mention that the application is a >COM server. > >Hope there is a solution, >Christian > >On Oct 26, 10:56 pm, Joseph M. Newcomer <newco...(a)flounder.com> wrote: > >On Monday, October 29, 2007 9:08 PM >Joseph M. Newcomer wrote: > >Generally, when problems arise when you are starting an app, it means you are >Generally, when problems arise when you are starting an app, it means you are doing >something that ends up being out-of-sequence with its preconditions. So you have to >figure out what is out of sequence. A side effect of creating the console is that >something is invoked that causes a sequence of actions that tries to use a NULL pointer. > >Creating a console seems an odd thing to do. Is there a good reason for it? (Note that >"debug output" is not a good reason) > joe > >On Mon, 29 Oct 2007 13:28:05 -0000, chhenning <chhenning(a)gmail.com> wrote: > >Joseph M. Newcomer [MVP] >email: newcomer(a)flounder.com >Web: http://www.flounder.com >MVP Tips: http://www.flounder.com/mvp_tips.htm > > >Submitted via EggHeadCafe - Software Developer Portal of Choice >SharePoint List Usage and Statistics >http://www.eggheadcafe.com/tutorials/aspnet/892bae83-5b96-4275-95fd-9723a79fdb14/sharepoint-list-usage-and.aspx Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
|
Pages: 1 Prev: WPF equivalent of TextOut() Next: Thread Deadlock Problem. |