Archived

This topic is now archived and is closed to further replies.

kuphryn

Weird Acception Violation :: MFC

Recommended Posts

Hi. I have discovered a major bug in a simple program. The problem has a propertysheet. There are two pages the are almost exactly the same. Both pages have a CListCtrl box. In both pages, the user can add items, select items, and/or remove existing items. For some reason, only one page worked in the *release* version of the program. Everything worked perfect in debug mode, but one page crashed in release. The page that crashed does so in the same manner every time. Below is a logs of the crash. // debug log ----- // this occurs AFTER the user options a propertysheet // program does NOT crash at this point First-chance exception at 0x7196254a in myProgram: 0xC0000005: Access violation writing location 0x00463b2c. // this occurs when the user selects an item in a CListCtrl box // program crashes at this point First-chance exception at 0x046936d7 in myProgram: 0xC0000005: Access violation reading location 0x046936d7. Unhandled exception at 0x046936d7 in myProgram: 0xC0000005: Access violation reading location 0x046936d7. The program ''[1120] myProgram: Native'' has exited with code 128 (0x80). ----- I have no idea how to fix this problem. I have compared the two property pages I mentioned that have the CListCtrl boxes. The code in both property pages are flawless. First, I thought the program crashed because there was a code program in the function that determines what item is selected in the CListCtrl box. However, I have found that the program does not crash at all inside that function. It crashed sometime after leaving the function. Is this a memory problem? Please post if you have any idea on debugging this problem. Thanks, Kuphryn

Share this post


Link to post
Share on other sites
Debug it. Go to project settings, choose 'program database' for debug information on C++ page and check 'include debug info' on Link page. Also turn all optimizations off by selecting Disable (Debug) from the appropriate combobox. Hit F5 and wait for the access violation, then use the call stack to look around.

edit: also try optimizing for size instead of speed. MSVC does some strange things with speed optimizations on.

---
Come to #directxdev IRC channel on AfterNET

[edited by - niyaw on July 15, 2002 4:11:46 PM]

Share this post


Link to post
Share on other sites
Thanks. "Debug Info" is enabled.

When the program crashed, Visual C++ points to the line that caused the crash. In this case, it points to the following line from *cmdtarg.cpp*.

Note: cmdtarg.cpp is NOT part my the program. I have no idea what where Visual C++ gets it.

-----
// cmdtarg.cpp
#endif //_DEBUG

// this line

-> return _AfxDispatchCmdMsg(this, nID, nCode,
lpEntry->pfn, pExtra, lpEntry->nSig, pHandlerInfo);
}
}
-----

Kuphryn

[edited by - kuphryn on July 15, 2002 4:55:29 PM]

Share this post


Link to post
Share on other sites
That source is part of MFC. Which message are you handling? Are you sure that all your message handlers have correct prototypes?

---
Come to #directxdev IRC channel on AfterNET

[edited by - niyaw on July 15, 2002 5:00:34 PM]

Share this post


Link to post
Share on other sites
I am handling different messages. Are you referring to main, doc, views, or the property sheet?

To be honest with you, I have no idea where to even start debugging it.

My best guess right now is it has something to do with maybe the property sheet because this problem occurs after the user opens options.

Kuphryn

Share this post


Link to post
Share on other sites
That line of code is deep inside MFC and in my opinion you need to try pretty hard to make it crash there. So:

- You may have messed up your memory and/or stack, possibly in a piece of code that has nothing to do with property sheets.

- The optimizer may be generating bad code. Did you turn all optimizations off?

- MFC performs blind casts on message handler functions. If you, for example, have a ON_MESSAGE handler that has the following signature:

void OnMyMessage();

you''re asking for stack corruption because the handler is passed WPARAM and LPARAM and you''re not accounting for that. Check allyou message handlers, make sure they have proper signatures.

You can:

- Remove property sheet code altogether, see if that cures the problem. If it does, add parts of it back slowly, run your app often to make sure you''re not breaking anything.

- If that doesn''t help, post your call stack when the crash occurs. I might get some ideas by looking at it. Don''t you think debugging MFC is fun? I''m only kidding, of course.

- Drop to #directxdev. I may be able to do more for you in realtime, as debugging requires a lot of questions answered.

Share this post


Link to post
Share on other sites
Thanks.

I will recheck all ON_MESSAGE calls and make sure the corresponding functions all have WPARAM and LPARAM as their in their parameters.

-----
- If that doesn''t help, post your call stack when the crash occurs. I might get some ideas by looking at it. Don''t you think debugging MFC is fun? I''m only kidding, of course.
-----

What do you mean "call stack?" I can post anything that could help debug this problem. Where do I get a log of the call stack?

I tried removing the property sheet. Removing the property sheet does in fact fix the initial Acception Violation. However, I cannot test the program to make sure the property page works, since the entire property sheet has been removed. Now I am 90% positive the property page is okay. I think Windows is doing something to the property sheet that I need to stop or take into account.

I have not remove any optimization. How do I do that? I am using Visual C++ .NET.

Last, what IRC network are you on? I can meet you in #directxdev.

Thanks,
Kuphryn

Share this post


Link to post
Share on other sites
quote:
Original post by kuphryn
What do you mean "call stack?" I can post anything that could help debug this problem. Where do I get a log of the call stack?


A call stack is the list of all functions that lead from WinMain to this particular piece of code. For example, if WinMain calls A and A call B and B crashes, your call stack would look like this:

B
A
WinMain

There''s more information in it, of course. In MSVC6, you can see it by hitting Alt-7, I don''t know about MSVC7. Check the docs, the combination should be there, or look in menus (I have it under View-Debug Windows).
quote:

I have not remove any optimization. How do I do that? I am using Visual C++ .NET.


In MSVC6 again, in Project Settings/C++/General there''s a combobox "Optimizations". Check your docs for location of it in your IDE.
quote:

Last, what IRC network are you on? I can meet you in #directxdev.


AfterNet, that''s irc.afternet.org (I''m using therk.us.afternet.org as the server).

---
Come to #directxdev IRC channel on AfterNET

Share this post


Link to post
Share on other sites
Okay. I disabled all optimization. This time, the program did not crash, but some features does not work. For example, the program does not update the selection list when a user select or deselect items in the CListCtrl box.

Disabling optimization definitely fix something in the program. This is weird. In general, is optimization good or bad?

Kuphryn

Share this post


Link to post
Share on other sites
Optimizations give the faulty code a better chance to crash. By moving code around, eliminating unused variables, changing execution paths, and making assumptions about how the code "should" behave, the compiler presents the bad code with an environment that is less fault-tolerant and less predictable. Bad code usually makes its own assumptions, mostly that the compiler or other code will correct its misbehavior. With optimizations on, nothing is corrected, and bad code messes itself up beyond recovery.

Maybe you should comment out other portions of your program until it behaves like it should, with whatever functionality is left, and then uncomment them one-by-one.

---
Come to #directxdev IRC channel on AfterNET

Share this post


Link to post
Share on other sites
Okay. I have found the problem.

The problem has to do with the way I was determining the state of an item in a CListCtrl. I had to change the algorithm. Now the program no longer crashes.

MFC does some really weird stuff in the background. Be careful or you might end up with many problems.

Kuphryn

Share this post


Link to post
Share on other sites