Re: Malloc code
- From: David Wilkinson <no-reply@xxxxxxxxxxxx>
- Date: Mon, 31 Dec 2007 05:57:28 -0500
Robby wrote:
Hello to both Davids! Thankyou for replying!//etc
David Wil. , your right I can just free it in main since the pointer to that allocation is passed back to main. Sorry!
2. This code may be clearer than before, but it is full of functions that do nothing but call other functions, functions that have no external effect, and local variables that are assigned but not used.
Since I wanted to be represent as precice as possible the code in my actual project, I included all the functions involved, but they do include other code which is not pertinant to my problem... I just included them in case they would some how be the source of the problem which I now doubt it very much!.... so thats why they are there. I mean you can just ignore them. If you wish I can start a new post called "Malloc code 2" and exclude these functions and some other non relevent stuff.
David Web. BAD_POINTER should of been atleast set to 0 in its innitialization, but the only reason I included :
if(pCL_B==NULL)
{BAD_POINTER=1;}
in my code is to show that I am aware that I should check if the pointer is valid. But for testing purposes with the debuger, I can see if the bointer is null by simply hovering my cursor over pCL_B as it displays its value! So for now its not of a great concern. The urgent concern is to understand why I read junk in the for loop of the TCP_LOAD_MCB_X function. The code sample that was posted is far from what will actually be done as a final product. I understand your concern and I appreciate you pointing it out and its also good constructive critisism for me or anyone else that reads this post. (for beginers like me that is!).
You have most probably noticed that I was using an array called "xxx[12]" in TCP_LOAD_MCB_X and I am assigning the values to the items of the strucutre like this:
pMCB1[i].ENDOFCHAR = 2;
and then re-assigning the value of ENDOFCHAR to an item in the xxx array like so:
xxx[k]= pMCB1[i].ENDOFCHAR; k++;
This is because the watch window in my compiler is not able to read the contents of "pMCB1[i].ENDOFCHAR". This is a known issue to them and are currently working on it. Therefore in my code (as you have probably noticed) I assign the value to the structure's item and then to assure that it really was assigned I check it via the xxx[] array. As soon as the compiler's company come up with a fix, I will remove the xxx array in its entirety. I know its sad, but I have no choice! So this is why I do this in my code.
k=0; pMCB1[i].ENDOFCHAR = 2; xxx[k]= pMCB1[i].ENDOFCHAR; k++;
So when the TCP_LOAD_MCB_X function is finished assigning all the items in every structure, I return the malloc pointer, since it was reccomended to me that we must not loose the pointer.
Then I pass it back into the FETCH() function. In this function I declare another array called xxx[] for the same reason I did in the TCP_LOAD_MCB_X function.
I also do another malloc which assigns its pointer to pCL_B. Then I try to read every item of the structures that were previously assigned in the TCP_LOAD_MCB_X function.
So if I put:
pt[i].ENDOFCHAR;
in the watch window, my compiler cannot directly display its contents. Therefore I assign every item of the structure to an item of the array called xxx[]. And this is why I have this in the fetch() function:
for(i=0;i<11;i++)
{
xxx[0]= pt[i].ENDOFCHAR;
xxx[1]= pt[i].A2;
xxx[2]= pt[i].A1;
xxx[3]= pt[i].A0;
xxx[4]= pt[i].LEADING_PIX;
xxx[5]= pt[i].TRAILING_PIX;
xxx[6]= pt[i].CHARSPACING;
xxx[7]= pt[i].CHAR_TRSP;
xxx[8]= pt[i].mCHAR_BCOLOR;
xxx[9]= pt[i].lCHAR_BCOLOR;
xxx[10]= pt[i].mTEXT_COLOR;
xxx[11]= pt[i].mTEXT_COLOR;
} //<<< Break point here!
Putting a break point in the for loop shown above permits me to see a series of 12 values contained in every structure. But some of the series are good and some are not (Junk!)
When i = 0, I read: (error,4,6,8,10,12,14,16,18,20,22,24)
When i = 1, I read: (2,4,6,8,10,12,14,16,18,20,22,24)
When i = 2, I read: (2,4,6,8,10,12,14,16,18,20,22,24)
When i = 3, I read: (2,4,6,8,10,12,14,16,18,20,22,24)
When i = 4, I read: (2,4,6,8,10,12,14,16,18,20,22,24)
When i = 5, I read: (2,,4,6,8,30,128, 164,0,18,20,22,24) <<< wrong data!
When i = 6, I read: (2,4,6,8,10,12,14,16,18,20,22,24)
When i = 7, I read: (2,4,6,8,10,12,14,16,18,20,22,24)
When i = 8, I read: (2,11,232,8,14,16,14,16,18,20,22,24) << wrong data!
When i = 9, I read: (2,4,6,8,10,12,14,16,18,20,22,24)
When i = 10, I read: (2,4,6,8,10,12,14,16,18,20,22,24)
When I should read:
When i = 0, I read: (2,4,6,8,10,12,14,16,18,20,22,24)
When i = 1, I read: (2,4,6,8,10,12,14,16,18,20,22,24)
When i = 2, I read: (2,4,6,8,10,12,14,16,18,20,22,24)
When i = 3, I read: (2,4,6,8,10,12,14,16,18,20,22,24)
When i = 4, I read: (2,4,6,8,10,12,14,16,18,20,22,24)
When i = 5, I read: (2,4,6,8,10,12,14,16,18,20,22,24)
When i = 6, I read: (2,4,6,8,10,12,14,16,18,20,22,24)
When i = 7, I read: (2,4,6,8,10,12,14,16,18,20,22,24)
When i = 8, I read: (2,4,6,8,10,12,14,16,18,20,22,24)
When i = 9, I read: (2,4,6,8,10,12,14,16,18,20,22,24)
When i = 10, I read: (2,4,6,8,10,12,14,16,18,20,22,24)
and oops! I just tried something!
for(i=0;i<12;i++) instead of: for(i=0;i<11;i++)
and what the hell is the 176 doing there!
pMCB1 = malloc(176*(sizeof(struct MCB)));
//This allocates 2.112 KBytes, I only have 1.5Kbytes!
it should be:
pMCB1 = malloc(11*(sizeof(struct MCB)));
!!!!!!!!!!and it works!
That's it folks, I need a vacation!
C requires a vigilant mind and I am too tired! An infinate thankyou for your support, I must admit, what gave it away was:
Robby:
I am glad that you have resolved your issue, if indeed you have. If your problem was that you were assigning too much memory, why did did malloc() not return NULL?
Some general comments:
1. Once again, if you must top-post, please trim previous replies. One advantage of bottom-posting is that it virtually forces you to do some trimming.
2. I did notice that there were several hard coded constants in your code (11, 12, 15, 16, 176) and wondered what their purpose was. You could have gotten rid of the particular problem you had by doing
#define NMAX 11 /* or 12 ? */
pMCB1 = malloc(NMAX*(sizeof(struct MCB)));
for (i=0; i<NMAX; i++)
3. Although I did guess that xxx was being used only for debugging purposes, it would have been nice if this had been indicated in the code:
int xxx[12]; /* for debugging only */
By the way, you should be able to get the same diagnostic effect by doing
int* xxx;
for (i=0; i<NMAX; i++)
{
xxx = (int*)(pMCB1 + i);
// ...
}
4. You say you left the redundant functions in the code because you thought they might be the cause of the problem. Why not take them out yourself and find out? It is *your* job to simplify the code as much as possible before you dump it on the newsgroup. It is also much more convenient if you can combine the code into a single file, so that responders can easily insert it into a vc project.
5. There are other redundant features/variables in your code that serve no purpose at all, in particular BAD_POINTER and pCL_B. It is possible that the latter actually causes the problem by contributing to the memory exhaustion; if so, taking it out will tell you something.
6. I understand that you are using some embedded compiler, but this is a vc group. It would be god if you were to try your code in vc, and see if the problem is still there. If not, it is unlikely that anybody here can help you with it; but if so, this may be a big clue.
Good luck!
--
David Wilkinson
Visual C++ MVP
.
- References:
- Malloc code
- From: Robby
- RE: Malloc code
- From: Robby
- Re: Malloc code
- From: David Wilkinson
- Re: Malloc code
- From: Robby
- Malloc code
- Prev by Date: Re: Double-Checked Locking pattern issue
- Next by Date: Re: Malloc code
- Previous by thread: Re: Malloc code
- Next by thread: Re: Malloc code
- Index(es):
Relevant Pages
|