|
the application crashed on pTthread 0x01430140{CWinThread h=0xfeeefeee proc=0xfeeefeee}, in the C:\...\VC98\CRT\SRC\DBGHEAP.C, _ASSERTE(pHead->nBlockUse == nBlockUse);
then it will report the memory leak and stop debug, but release works fine. it should be a bad pointer somewhere?
dbName::dbName()
{
m_pdbf = NULL;
}
dbName::~dbName()
{
delete m_pdbf;
}
after delete m_pdbf, m_pdbf will still contant the address, is it what causing the problem? thanks!
|
|
|
|
|
valerie99 wrote:
after delete m_pdbf, m_pdbf will still contant the address, is it what causing the problem?
No, because the dbName object (and thus its m_pdbf member) is being destructed, anyway.
If you break in the debugger when the assertion fails, does the call stack trace back to this destructor? If so, you might be deleting an invalid dbName object, or doing so through an invalid dbName* ; check the value of the this pointer in the context of the destructor.
--
jlr
http://jlamas.blogspot.com/[^]
|
|
|
|
|
Thanks for your reply.
the call stack couldn't trace back on any part of my code except MFC, but assertion failed is happening around destructor been called.
I just checked the this pointer in the contest of destructor "0X0012f844", the value of m_pdbf is "0X013afef0"......thank you!
|
|
|
|
|
Try setting a breakpoint in the destructor, and each time it breaks, inspect the content of the dbName object and the object pointed to by m_pdbf, and check the call stack to see from where the destructor is being called. When the program crash, try to relate it to what you observed last time the destructor was executed.
--
jlr
http://jlamas.blogspot.com/[^]
|
|
|
|
|
seems like assertion failed right after clean up the local thread in c:\...\MFC\SRC\THRDCORE.CPP, in function AfxTermThread();
could it be the wrong thread been cleaned up causing the problem?
thanks.
|
|
|
|
|
make sure that each time you delete an object that you assign NULL to the pointer.
delete m_pdbf;
m_pdbf = NULL;
and that each time you declare a pointer you assign it NULL.
Maximilien Lincourt
Your Head A Splode - Strong Bad
|
|
|
|
|
This sounds like a slight twist on an old problem. Where the problem appears to be may not be where the problem is. You need to work backwards from where you first see the problem and examine every allocation and memory access. The simpilest way it to place a lot of TRACE(...) commands in your code along the path leading upto the problem, and examine the trace output. A validator like BoundsChecker will probably help solve the problem, but validators have limits to; so the TRACEs may be your best bet.
INTP
"The more help VB provides VB programmers, the more miserable your life as a C++ programmer becomes."
Andrew W. Troelsen
|
|
|
|
|
Thank you! yeah, seems like it could be anywhere now.......
I might have to try to use TRACE(...) the only thing is I haven't checked out the project yet, because the release version works, and nobody want to mess with it......oh, well.....thanks again!
|
|
|
|
|
Not absolutely positive, but have seen similar crashes before, and the cause was a double-delete. If I remember right, 0xfeeefeee is one of the fill patterns for already deleted memory. Hope that's helpful.
|
|
|
|
|
1. you are deleting the instance of dbName multiple times.
2. You have deleted m_pdbf in another method of dbName and didn't NULL it out thus the double delete.
3. You didn't initialize m_pdbf to NULL (assuming it will get a value in another location) thus when the destructor gets called, you are trying to delete trash.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
Hi,
Just wondering, if it's possible, what the right way to get my 32 bit project to be compiled to 64 bit executable?
Just one restriction, it shouldbe done in VS .NET 2003 (not 2005).
Thanks.
|
|
|
|
|
Folks, I am looking for a simple way to load two bitmaps in C++ .NET All I need to do is load them, and know they are there. I have a .DLL that will then run comparison test. My expertise in this is only starting to develop, so advice is appreciated.
Sincerely,
Max Pastchenko
|
|
|
|
|
Is LoadBitmap() what you are looking for?
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
|
|
|
|
|
You are probably, right, I am gona work on trying to figure out how to implement it. An example you would useful.
Sincerely,
Max Pastchenko
|
|
|
|
|
mpastchenko wrote:
An example you would useful.
See here.
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
|
|
|
|
|
|
Yes, this appers useful. I will look at this example in details later today.
Sincerely,
Max Pastchenko
|
|
|
|
|
LoadImage does this, just use the LR_LOADFROMFILE flag.
"You're obviously a superstar." - Christian Graus about me - 12 Feb '03
"Obviously ??? You're definitely a superstar!!!" - mYkel - 21 Jun '04
"There's not enough blatant self-congratulatory backslapping in the world today..." - HumblePie - 21 Jun '05
Within you lies the power for good - Use it!
|
|
|
|
|
What does this flag indicate?
Sincerely,
Max Pastchenko
|
|
|
|
|
That you're loading an image from a file. You can use it to load from resources as well, from memory.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
Read all about LoadImage in MSDN[^]
"You're obviously a superstar." - Christian Graus about me - 12 Feb '03
"Obviously ??? You're definitely a superstar!!!" - mYkel - 21 Jun '04
"There's not enough blatant self-congratulatory backslapping in the world today..." - HumblePie - 21 Jun '05
Within you lies the power for good - Use it!
|
|
|
|
|
I am trying to launch a program executable(Program A) from another program's menu (Program B). I coded the program B such that it searches the registry for the installation path of program B's executable. This works fine under an administrator login but not for non-admins. I thought it was because I did not grant proper security access by adding KEY_READ to the following line of code:
bRetVal = regKey.Open(HKEY_LOCAL_MACHINE ,(LPCTSTR)strTmp, KEY_READ);
But when I do include KEY_READ, under an admin login, the above code fails. Why is that? For non-admins, it fails either way. The entire code is shown below. Thanks!
CProgramB::Notify(DataNotificationType notifyType, VARIANT data)
{
STARTUPINFO stStartUpInfo;
PROCESS_INFORMATION pProcessInfo;
memset(&stStartUpInfo, 0, sizeof(STARTUPINFO));
stStartUpInfo.cb = sizeof(STARTUPINFO);
stStartUpInfo.dwFlags = STARTF_USESHOWWINDOW;
stStartUpInfo.wShowWindow = SW_SHOWDEFAULT;
CRegKey regKey;
BOOL bRetVal;
CString strTmp = "Software\\ProgramA";
if (bRetVal==ERROR_SUCCESS)
{
CString key = "InstallDir";
char getValue[256] ;
DWORD d = 255;
bRetVal=regKey.QueryValue( getValue , (LPCTSTR)key , &d);
if (bRetVal==ERROR_SUCCESS)
{
char comLine[300];
CString keyValue = (CString)getValue;
strcpy(comLine, keyValue);
strcat(comLine, "programA.exe");
CreateProcess(NULL, comLine, NULL, NULL, FALSE,
NORMAL_PRIORITY_CLASS, NULL, NULL, &stStartUpInfo,
&pProcessInfo);
}
else
AfxMessageBox("Query Failed");
}
else
{
AfxMessageBox( "Program Fail to open.");
}
regKey.Close();
return S_OK;
}
|
|
|
|
|
elephantstar wrote:
bRetVal = regKey.Open(HKEY_LOCAL_MACHINE ,(LPCTSTR)strTmp, KEY_READ);
Does this mean that the default security access of KEY_ALL_ACCESS works?
elephantstar wrote:
BOOL bRetVal;
...
if (bRetVal==ERROR_SUCCESS)
At this point, bRetVal has not been assigned a value.
elephantstar wrote:
bRetVal=regKey.QueryValue( getValue , (LPCTSTR)key , &d);
You can't call QueryValue() without having first called Open() .
elephantstar wrote:
CString keyValue = (CString)getValue;
Why the unnecessary cast?
Use of the <pre> tag will make your code much easier to read.
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
|
|
|
|
|
when I click on the debug menu, it brings up a find symbols window and asks me to enter the path for vc60.pdb. I don't know what I should do.
Thanks,
|
|
|
|
|
valerie99 wrote:
I don't know what I should do.
How about entering the path to the vc60.pdb file? Most likely this is in the project's Debug folder.
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
|
|
|
|