|
Call stack is the best option in this case... 
|
|
|
|
|
When I get this problem it's usually due to trying to deallocate a pointer that already has been deallocated. Look at the call stack to find out which object you're trying to deallocate, then check why it's been deallocated already.
If this is not called during deallocation then I have no idea, sorry.
|
|
|
|
|
Thanks for all guys who made suggestion above. When I debug I got error message:
"user break point called from code at 0x7c90120e"
-> 7C90120E int 3
Please help,
Thanks
|
|
|
|
|
You haven't mentioned what tools you use to develop and debug, but if you got a debugger running, it should automatically open the source code at the position where the error occurs. The message however sounds like it's from internal code, so, most likely, you won't recognize the code as yours.
You now need to find out where in your code this function was called. For that you need to check the call stack. If no window is shown for it, see if you can activate it from the menu. If you don't know how to do this, check the help function from your development environment.
Once you have the call stack, the focus will likely be on the topmost line, indicating the function that is shown in your source code window. Usually you can make an educated guess what kind of functionality should be performed here from the name of the function. I still suspect you're inside some deallocation routine, but it may be something different; check this!
Now scan down the list in the call stack and find the first function that you recognize as part of your own source code. Doubleclick it or do whatever is required to navigate to that position. The source code window will then show the exact location in your source code where another function not from your source code is called. If the problem occurs during deallocation it may be tricky though, as the call may in fact occur at the end of a scope, where stack variables are destroyed. In that case the cursor in the code window may point to a line past the end of the scope; this can be a bit confusing at times...
Anyway, once you've located the right location in your code, check the values of the parameters that are involved in the function (or deallocation) call, and see if they have values in the range you expect. Again, if this a deallocation problem, you may not see anything unusual amiss - in this case, if you don't know how to proceed, copy some of the code at that location and post it here.
|
|
|
|
|
My application use the named CMutex to access shared resources. When I run mulitple instances of the application, one of the instances occasionally crashes because of a failure in creating the CMutex object.
My question is: Can I created a CMutex object when other apps have the same named CMutex object locked?
Best,
Jun
|
|
|
|
|
No you cannot, you'll get an handle to the existing one, see CreateMutex documentation[^]. Instead of crashing, your application should be able to handle such scenario.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Actually, my question is about CMutex object not the kernel object created by CreateMutex(). CMutex is a MFC wrapper. Anyway, I suspect that you can create multiple CMutex objects that use the same named kernel object. I don't know how CMutex behaves exactly, as we don't have its source.
Best,
Jun
|
|
|
|
|
|
Yes you may contruct the MFC object anyway, but you HAVE to call GetLastError (as Albert Holguin already noted) to see what really happened.
Jun Du wrote: I don't know how CMutex behaves exactly, as we don't have its source.
Is by chance your Visual Studio installation broken? Do you know MFC comes with source code, don't you?
As you are using MFC synchronization objects the following Newcomer's article is a worthy reading: "Avoid CMutex, CEvent, CSemaphore and CCrticalSection"[^].
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Jun Du wrote: I suspect that you can create multiple CMutex objects that use the same named kernel object. I don't know how CMutex behaves exactly, as we don't have its source
Nope, if you try to create same named mutex it going to give your exception, simple technique is one would create it and other would open it!
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
Never mind - my own stupidity is the source of every "problem" - Mixture
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief and You
|
|
|
|
|
OK, I'm going mad here. I have a dialog class which I am creating from a dialog resource and displaying as modeless. I have data members assigned to the various controls and most of them work fine, except the CComboBox data member. I am trying to add some string data to the control in the CMyDialog::OnCreate(LPCREATESTRUCT lpCreateStruct) but it asserts because the control's hwnd is null. Do I need to do anything special with a CComboBox? My code is like this...
int CFlushDialog::OnCreate(LPCREATESTRUCT lpCreateStruct)
{
if (CDialog::OnCreate(lpCreateStruct) == -1)
return -1;
SetWindowPos(NULL, m_nXPos, m_nYPos, 0, 0, SWP_NOSIZE | SWP_NOZORDER);
m_comboDataMember.AddString("Hello");
return 0;
}
I display the dialog like this...
m_flushDialog.Create(IDD_FLUSH_DLG, this);
m_flushDialog.ShowWindow(SW_SHOW);
Anyone have any ideas? 
Tony
|
|
|
|
|
Why don't you add the data to the combobox in the OnInitDialog method ?
Watched code never compiles.
|
|
|
|
|
I think you will find that your ComboBox does not get created until after the dialog creation has completed. Use the OnInitDialog() function to handle intialisation of dialog controls.
The best things in life are not things.
|
|
|
|
|
Thanks Richard (and also Maximilien), your suggestion works great. I wasnt aware that OnInitDialog() still got called with modeless dialogs.
Tony
|
|
|
|
|
As others have suggested, all GUI initialization should occur in OnInitDialog(). The fact that some controls work is probably more of a coincidence in how they're implemented but should not be an indication that this is the proper place for this.
|
|
|
|
|
So class _base is a pure virtual class.
Class _child derives from it and implements the functions.
The code creates an instance of _base and uses it.
Question. It seems that when an instance of a pure virtual base class is created, an instance of its child is in fact created. Is this so?
An observation. VS finds it impossible to debug step into any functions of the _child instance.
Further question. What if you have two descendents from _base. How does the compiler know which one to instantiate?
While I know C++ well, I have never come across this before, and I would never code this way, it looks ugly, is unclear, and makes debugging impossible. (I work mostly in the kernel in C)
==============================
Nothing to say.
|
|
|
|
|
Eric__V wrote: instance of _base
I doubt on the term instance in case of pure virtual class.You can't create an instance of a class if it have a pure virtual function.May be the code is declaring the pointer of base class and assigning the instance of derived class.Like,
_base *pbase = new basederive();
Eric__V wrote: Further question. What if you have two descendents from _base. How does the compiler know which one to instantiate?
This will be done with help of virtual pointer table.There are lot of articles in code project on this.Start from this link,
ATL Under the Hood - Part 2
http://www.mono-project.com/Main_Page
|
|
|
|
|
Yeah, I just dug a bit dfeeper and indeed, it is newed off the derived class.
I still want to know why VS cant step into the damn code though. Its really pissing me off.
==============================
Nothing to say.
|
|
|
|
|
Eric__V wrote: I still want to know why VS cant step into the damn code though.
Have you compiled and built it in Debug mode?
The best things in life are not things.
|
|
|
|
|
Yeah, its running on a remote machine, so I am doing an 'attach to process' in VS. pdbs are on the remote machine with the exes and dlls (best way to handle symbols for VS IMO). OS symbols are stored on the dev machie locally and off Microsofts symsrv.
But weird, just cant step into the code. Its not even complaining about lack of source code and offering the view assembler approach.
Cant really devote time to finding out why its not doing it, too much real work to do else where. 
==============================
Nothing to say.
|
|
|
|
|
Sorry, no more ideas, I've never tried debugging a remote process.
The best things in life are not things.
|
|
|
|
|
Eric__V wrote: How does the compiler know which one to instantiate?
venkatmakam wrote: This will be done with help of virtual pointer table.
No, instantiation is always explicitly written in code, and the proper virtual table is selected on instantiation.
|
|
|
|
|
Eric__V wrote: It seems that when an instance of a pure virtual base class is created, an instance of its child is in fact created.
When an instance of the derived class is created then you have also an instance of the base class (because 'derived' is 'base'): you cannot instantiate an abstract class.
Eric__V wrote: An observation. VS finds it impossible to debug step into any functions of the _child instance.
Visual Studio debugger should be able to do that (the debugger is one of the amazing features of Visual Studio, in my opinion).
Eric__V wrote: Further question. What if you have two descendents from _base. How does the compiler know which one to instantiate?
Choosing the appropriate derived class to instantiate (to get base class functionality) is up to you.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
I dug a bit deeper and in fact the _base pointer instance is new'ed as the sub classes.
And now I saw that, I remember from about 12 years ago, that I have seen this before. Spent the last 10 years pretty much 100% in the kernel so I guess I got a bit rusty with the old C++ inheritance game.
==============================
Nothing to say.
|
|
|
|
|
Eric__V wrote: The code creates an instance of _base and uses it.
Maybe I do not understand the question correctly.
You cannot create an instance of the base class if it contains pure virtual member functions.
class Onion
{
public:
virtual void f( ) = 0;
};
class Tata : public Onion
{
virtual void f();
};
...
Onion onion; // will generate a compiler error.
...
Watched code never compiles.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
