C / C++ / MFC

Re: Help needed: another strange calloc/malloc issue

21-Jul-06 7:23

I tried to use the new and delete operators without success.

I will try several things before posting again. Thanks for all your comments and talk to you later!

Stephen Hewitt21-Jul-06 18:56

Re: Help needed: another strange calloc/malloc issue

21-Jul-06 18:56

Follow the steps I posted here[^]. If you've got heap corruption the last thing you want to do is poke around the edges until you "solve" the problem: it's there lurking until you find the cause and you're lucky you can reproduce it so easily.

Steve

lyuabe29-Jul-06 2:24

Re: Help needed: another strange calloc/malloc issue

29-Jul-06 2:24

Hi!

I left the debugging problem for later on, because my code ran fine when I changed the parameters (it has to deal with the size of many arrays, but it does not necessarily crash when I increase these sizes). Anyway, I just realized that I forgot to mention that the code is crashing only in the "release" executable, and runs fine in debug mode. Also, one important thing is that I use either an AMD machine (desktop for simulations) or an Intel proc (laptop) for coding and debugging. The release exe sometimes runs fine on the Intel, but crash on the AMD.

This being said, I should say that I'm not familiar with debugging tools (like WinDbg) apart fom the Visual debugger. But it's not of big help if the code only crashes in the release exe.

Anyone could give me a hint to start? (Sorry Steve, although you detailed the process to do it, I'm afraid I'm missing somthing at some point Sigh | :sigh:

)

Stephen Hewitt29-Jul-06 2:39

Re: Help needed: another strange calloc/malloc issue

29-Jul-06 2:39

lyuabe wrote:
This being said, I should say that I'm not familiar with debugging tools (like WinDbg) apart fom the Visual debugger. But it's not of big help if the code only crashes in the release exe.

I gave detailed step by step instructions. Debugging tools (such as WinDBG) work almost as well on release builds as they do on debug builds as long you build the release build with debugging info (.PDB files).

Steve

lyuabe29-Jul-06 5:47

Re: Help needed: another strange calloc/malloc issue

29-Jul-06 5:47

Hi Steve,

Stephen Hewitt wrote:
as long you build the release build with debugging info (.PDB files)

Yes, but I did not know how to make WinDbg use the PDB file. First I tried to use PDB from the debug version, but of course it does not work. And actually I did not know that it's possible to generate the debug info for the release, so thanks very much for the info!!... so I just found the option to generate the debug info file PDB for the release executable. Okay, I'll try this and tell you the results of the process... Thanks again!

Stephen Hewitt29-Jul-06 16:33

Re: Help needed: another strange calloc/malloc issue

29-Jul-06 16:33

Remember to enable the debug info for the compiler and the linker.
On MSVC6 follow these steps on your release build:
1. Select "Project->Settings..."
2. Select "C/C++" tab.
3. In the "Category:" combo select "General".
4. In the "Debug info:" combo select "Program Database". We don't use the edit and continue option in a release build.
5. Select the "Link" tab.
6. In the "Category:" combo select "Debug".
7. In the "Debig Info" group tick "Debug info", "Microsoft format" and "Seperate types".

If your using a later version you'll have to adapt these steps.

Steve

lyuabe30-Jul-06 15:56

Re: Help needed: another strange calloc/malloc issue

30-Jul-06 15:56

Hi,

I generated the debug info (PDB file) for my release exe. But when I use it on the simulation computer with WinDbg, it keeps on saying:
*** ERROR: Symbol file could not be found. Default...
although I specified the "symbol file path" to be the correct one (I think). What am I doing wrong?

...and you were right, because windbg indicates:
HEAP[FMCT.exe]: Invalid allocation size - AC1905B4 (exceeds 7ffdefff)
But I do not know where that is without the trace of the code...

Stephen Hewitt31-Jul-06 1:43

Re: Help needed: another strange calloc/malloc issue

31-Jul-06 1:43

First locate the .PDB file. It should be in the same directoy as the .EXEs in. Enter the path of the directory that contains it in the symbol file path. You shouldn't need to do this however. Are you sure you've got the PDBs?

Steve

lyuabe31-Jul-06 15:43

Re: Help needed: another strange calloc/malloc issue

31-Jul-06 15:43

Stephen Hewitt wrote:
You shouldn't need to do this however. Are you sure you've got the PDBs?

Yes I'm sure. But here the exact configuration I use: first I compile the code on my laptop (Intel proc) with all the compiling options you mentioned for debugging (although I could not find any option in .NET 2003 for the "Microsoft format" and "Seperate types" for debugging info). Then I copy the EXE and PDB files on the AMD machine and run WinDbg on the AMD: I launch WinDbg, set the symbol file path, then use the command Open Executable and select my EXE, and specifiy the running directory of my EXE (which is different from the location of the PDB file). Is there something wrong in what I'm doing?

Thanks again.

lyuabe2-Aug-06 21:22

Re: Help needed: another strange calloc/malloc issue

2-Aug-06 21:22

Hi there,

That's it, I fixed it. Actually, I was mislead by the first debugger comment when opening the EXE. It said that it could not locate the SYMBOL info, but later when it crashed, it correctly reported the error using the PDB (and source code?) I put in the Symbol folder.

Okay, thanks very much for your help. I hope next time I have a crash in my RELEASE I will be able to find the exact reason... althgouh now I've chanegd my code to run in Multi-Thread Unsure | :~

... so debugging is even more complicated.

By the way I have a question about multi-threading, are you familiar with it?

-Lyu ABE

Stephen Hewitt2-Aug-06 21:43

Re: Help needed: another strange calloc/malloc issue

2-Aug-06 21:43

Somewhat....What's your question?

Steve

lyuabe2-Aug-06 22:28

Re: Help needed: another strange calloc/malloc issue

2-Aug-06 22:28

Humm.. I was about to ask why one of my two threads was finishing the job much before the other (they are performing the same task, but on separate memory spaces, so no lag due to access to shared ressources). Then I realized it was because I used a (stupid) while to wait for some bool flags in each thread to be set to true, and the laggy thread was running on the same core than the main program. That's why it was slown down. Now I'm using Events to signal the state of the thread, using CreateEvent, SetEvent and ResetEvent. I have the same crashing issue on the AMD proc Frown | :(

. It runs fine on the Intel laptop, but crashes on the AMD (both with RELEASE EXEs). (if you have suggestions, they are welcome...)

Anyway, I am now wondering if these multithread functions _beginthread, etc. are portable to other platforms (i.e. is that standard C++)??

lyuabe2-Aug-06 22:55

[SOLVED] Re: Help needed: another strange calloc/malloc issue

2-Aug-06 22:55

I found why the code crashed on the AMD machine: it is because I got this strange crashing issue (the origin of my message). But now what is puzzling me is that when I use WinDbg to launch the EXE, it runs fine, but when I use console command, it crashes Cry | :((

. Any explanation to that?

lyuabe2-Aug-06 23:36

Communication between propertypages

2-Aug-06 23:36

Okay, I guess I've found the cause of the crash: I was not freeing some (small) arrays in one of my subroutines... However, it seems strange to me that it made my code crash. I thought that if it was not freed, then the memory space was just allocated and not available to other allocation during the code execution...

Anyway, I got it solved, so I'm happy Smile | :)

Thanks all for your suggestions to this thread.

Lyu ABE

vc++_fragrance21-Jul-06 0:13

vc++_fragrance

21-Jul-06 0:13

Hi,
Can u please help me to solve the problem.

I have two property pages in a property sheet.

The first one is CCmpListSetupDlg
and the second one is CCmpDataEntryDlg.

In the first propertypage i am getting a string into the variable "str".

BOOL CCmpListSetupDlg::OnKillActive()
{

CString str;

// I used CListCtrl two create grid lines and when user click on a row(item)
// i am getting the text value into the CString variable "str"

CListCtrl* pListCtrl = (CListCtrl*) GetDlgItem(IDC_LISTITEMS);

POSITION pos = pListCtrl->GetFirstSelectedItemPosition();
if (pos == NULL)
{
AfxMessageBox("No items were selected!\n");
}
else
{
while (pos)
{
nItem = pListCtrl->GetNextSelectedItem(pos);
str=pListCtrl->GetItemText(nItem,0);
AfxMessageBox(str);
return CPropertyPage::OnKillActive();
}
}
}

//This is my second property page
//When ever my second property page is activated i want the text
//value of "str" to get displayed .
BOOL CCmpDataEntryDlg::OnSetActive()
{
AfxMessageBox("Hi Dataentry page is active");

// here str value should be displayed.

return CPropertyPage::OnSetActive();
}

Thanks in Advance.

ThatsAlok21-Jul-06 0:38

ThatsAlok

21-Jul-06 0:38

tejaswini.g wrote:
AfxMessageBox("Hi Dataentry page is active");

// here str value should be displayed.

return CPropertyPage::OnSetActive();

"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow

cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief and You

ThatsAlok21-Jul-06 0:38

ThatsAlok

21-Jul-06 0:38

tejaswini.g wrote:
AfxMessageBox("Hi Dataentry page is active");

// here str value should be displayed.

return CPropertyPage::OnSetActive();

is CPropertyPage* CPropertySheet::GetPage(int nPage) of any help!

"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow

cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief and You

vc++_fragrance21-Jul-06 0:51

vc++_fragrance

21-Jul-06 0:51

Can u show me please How can I use it in my program.

prasad_som21-Jul-06 3:12

prasad_som

21-Jul-06 3:12

to continue what Alok has suggested , refer
http://www.codeproject.com/script/comments/forums.asp?msg=1257711&forumid=1647&Page=4&userid=1304767&mode=all#xx1257711xx