|
There is nothing wrong with this code. Are you sure one of the pointers isn't being changed after the allocation? To guard againt this try the following:
...
double * const a = (double * const)malloc(Na*sizeof(double));
double * const b = (double * const)malloc(Nb*sizeof(double));
double * const c = (double * const)malloc(Nc*sizeof(double));
...
This makes the pointer constant but not the data it actually points to. With this in place any code (almost) which attempts to change the address of the pointers will not compile.
const is the programmer's friend.
Steve
|
|
|
|
|
Hi Steve, thanks for your reply!
Stephen Hewitt wrote: Are you sure one of the pointers isn't being changed after the allocation?
Yes I'm sure, because I displayed the pointers right after the memory allocation. And I should add one thing: I can run the code on 2 machines, but only one crashes. I don't know, maybe some physical memory issue, but this PC is close to brand new. But what makes me think it's a coding issue is that I already had such problems by the past on totally different codes, not really able to fix them (maybe found some hazardous fixes when tweaking the compilation options, like for optimization).
-Lyu
|
|
|
|
|
lyuabe wrote: Yes I'm sure, because I displayed the pointers right after the memory allocation.
How do you display that ? Post some code.
Cédric Moonen
Software developer
Charting control
|
|
|
|
|
Sorry, the original code is like this (with calloc):
<br />
double *temp_radiale = (double*)calloc(grid->n_rad,sizeof(double));<br />
double *delta_temp_radiale = (double*)calloc(grid->n_rad,sizeof(double));<br />
double *avg_rad_energy = (double*)calloc(grid->n_rad,sizeof(double));<br />
then the code crashed, I guess because when the 3rd calloc tries to access the memory which has already been allocated by the second one, it crashes.
So I tried the following:
<br />
double *temp_radiale = (double*)malloc(grid->n_rad*sizeof(double));<br />
double *delta_temp_radiale = (double*)malloc(grid->n_rad*sizeof(double));<br />
double *avg_rad_energy = (double*)malloc(grid->n_rad*sizeof(double));<br />
<br />
#ifdef _DEBUGOOO<br />
printf("%x %x %x\n",temp_radiale,delta_temp_radiale,avg_rad_energy);<br />
#endif<br />
which actually displays the two identical pointers delta_temp_radiale and avg_rad_energy. But at the end of this subroutine, when I free, it crashes, obviously.
|
|
|
|
|
What happens if you reverse the order of the allocations, like:
double *avg_rad_energy = (double*)malloc(grid->n_rad*sizeof(double));
double *delta_temp_radiale = (double*)malloc(grid->n_rad*sizeof(double));
double *temp_radiale = (double*)malloc(grid->n_rad*sizeof(double));
"Money talks. When my money starts to talk, I get a bill to shut it up." - Frank
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
I REALLY doubt it is a problem with malloc/calloc.
I would think that either grid is NULL/invalid or grid->n_rad is 0/invalid (i.e. large).
[EDIT]
... or that you are using it in a multi-threaded app that has another thread calling malloc/calloc _and_ you have explicitly turned off multi-threaded support for the process heap
[/EDIT]
...cmk
Save the whales - collect the whole set
-- modified at 10:34 Friday 21st July, 2006
|
|
|
|
|
cmk wrote: I REALLY doubt it is a problem with malloc/calloc.
I would think that either grid is NULL/invalid or grid->n_rad is 0/invalid (i.e. large).
Hummm, nope. The grid pointer and n_rad are okay (I can print their value). My app is not (yet) multi-threaded, so there's no chance of a conflict accessing these variables. Although, I will check what you suggest (multithreaded support).
|
|
|
|
|
In this case it looks like something is wrong with the heap. Maybe to heap has been corrupted. While it's possible the machine is at fault it's hard to imaging it would boot with such a serious fault.
Steve
|
|
|
|
|
Stephen Hewitt wrote: In this case it looks like something is wrong with the heap. Maybe to heap has been corrupted.
Yes, maybe, but I have no real idea on how to set a good value, or if I should use RESERVED or VALIDATE. Any explanation about that would be great! 
|
|
|
|
|
Firstly did you try the double * const a? If the pointers are meant to point at the same object for the life time of the pointer but you want to be able to change the object pointed to this is how you should declare the pointer anyway.
Secondly, to check for heap corruption, you could try enabling the page heap for the process. Follow these steps.
1. Download WinDBG from here[^].
2. Install it.
3. From the start menu select “Start->All Programs->Debugging Tools for Windows->Global Flags”.
4. Select the “Verifier” tab.
5. In the “Image: (TAB to refresh)” edit control type the name of your EXE. e.g. For notepad you’d enter “notepad.exe”.
6. Press “TAB”.
7. Tick the “Enable” and “PageHeap” check boxes.
8. Press “Apply” and “OK”.
9. Debug you application. It will run many times slower than normal and consume heaps more memory than is normal – Don’t panic.
When you’ve found the memory error go through the steps again (not steps 1 and 2) but in step 7 uncheck all the tick boxes – This is important or your application will run slow and eat memory forever on your machine (and so will any EXE with the same name).
Steve
Steve
|
|
|
|
|
Out of interest, what are the values of Nb and Nc?
Steve S
Developer for hire
|
|
|
|
|
What's the actual number of allocation, eg. how many doubles do you want?
A very simple change (but not very smart, just to get an insight into what's happening) are to just do one allocation (as the number of doubles are constant)
<br />
double* base=(double*)malloc(N*3*sizeof(double));<br />
double* a=base + 0 * N;<br />
dobule* b=base + 1 * N;<br />
double* c=base + 2 * N;<br />
Why are you using malloc/free instead of new[]/delete[]?
Whenever I've runned into a memory problem, the cause of the problem was often totally unrelated to the symptoms. Eg. your code is probably working but sometimes before coming there, you have a memory error (out of range access, failed allocation).
Good hunting
-- modified at 7:40 Friday 21st July, 2006
|
|
|
|
|
Steve S wrote: Out of interest, what are the values of Nb and Nc?
Nb and Nc are similar. Actually Nb = Nc = grid->n_rad (grid is a class). The real code is:
double *temp_radiale = (double*)calloc(grid->n_rad,sizeof(double));
double *delta_temp_radiale = (double*)calloc(grid->n_rad,sizeof(double));
double *avg_rad_energy = (double*)calloc(grid->n_rad,sizeof(double));
The code runs fine when I change some parameters which actually change the overall allocated memory of my code (although not the n_rad value mentioned above). I'm not too familiar with HEAP and STACK, so could that be such an issue? (I've also tried to increase dramatically these HEAP and STACK values, but nothing changed).
-Lyu
|
|
|
|
|
Jonas Hammarberg wrote: Whenever I've runned into a memory problem, the cause of the problem was often totally unrelated to the symptoms.
Same here.
Steve
|
|
|
|
|
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!
|
|
|
|
|
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
|
|
|
|
|
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   )
|
|
|
|
|
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
|
|
|
|
|
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!
|
|
|
|
|
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
|
|
|
|
|
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...
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
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  ... so debugging is even more complicated.
By the way I have a question about multi-threading, are you familiar with it?
-Lyu ABE
|
|
|
|
|
Somewhat....What's your question?
Steve
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
