#Realloc Problem
7 messages in this thread
Hi Jonas,
Does IPAS3 have a problem with using realloc?
The reason I ask is that I'm trying to dynamically expand arrays and structures
as
more triangles are generated. When performing reallocs on structures I define
inside my code, there's no problem. However, when I try and use realloc on
XVData and XFData structures, I get memory protection faults.
Here's a sample of the code I'm using:
XVData *vertdata;
int pmax;
int psize;
…
/* allocate memory for vertex assignment table */
pmax = 1000;
psize = 0;
vertdata = malloc(pmax * sizeof(XVData));
if (vertdata == NULL){
sprintf(message, "Abort! Insufficient memory for vertices.");
gfx_prompt(message);
return 0;
}
…
/* allocate more memory for the vertex assignment table */
for (i = 0; i < vsize; i++) {
++psize;
if(psize > pmax){
/* table not big enough, expand it */
pmax = pmax + 100;
vertdata = realloc(vertdata, pmax * sizeof(XVData));
if (vertdata == NULL){
sprintf(message, "Abort! Insufficient memory for vertices.");
gfx_prompt(message);
return 0;
}
}
Is this problem caused by the structure residing in far memory or is it
something
else? Should I be using farrealloc? As always, any help would be appreciated.
BTW, What's the status of the MESH_SELECTED question I posted?
Thanks,
Danny…
From Danny
OK, so you can't set the flags variable of a mesh object….
Can you determine whether an object is selected? When I try to access
'idata.item.m.flags', all I
get is zero. Does this mean that you can't access the flags at all?
If that's the case, how can one determine whether objects in the editor are
selected or not? I
would like to be able to perform an operation on selected objects only.
Something like:
if( idata.type == 0 ){
if( idata.item.m.flags == MESH_SELECTED ){
do something;
}else{
ignore this object;
}
}
——————–
Answered by QA.
I don't know about setting the flags. If I have time I could try it – I mean
setting the flags myself
(if selected, set flag to 1). Another work around could be getting something
else in the ItemData
structure and using it as a flag for selected objects. He could get the index
of an object and
save this in an array, or he could get the name and save it in an array of
char*s or something.
There would be some additional overhead, but I don't think it would be that big
of a deal.
/Jim
Hi Danny,
I was wondering at what point you actually get the memory protection fault.
Does it occur
withing the realloc function, or somewhere inside 3D Studio?
Ciao,
Grant
I found a bug a while ago where using either "realloc" to grow a buffer, or by
simply freeing a buffer and allocating a larger one right after ( free() and
malloc()) the malloc function would get mangled trying to figure the heap and
crash. This was pretty consistent. My work around was to allocate the largest
possible buffer, free it and then go on with business. This works ok for small
buffers (up to, say, 200k). If a very large buffer is required, I would talk to
PharLap directly and bypass the malloc() function all together. I also suggest
if you do lots of small mallocs (very inefficient, by the way), get your own
malloc function and don't trust the one in Metaware's run time library. I
didn't investigate any further and I can't tell if the bug is in malloc() or in
the heap allocation at init time. I also haven't done any testing with the new
IPAS3 stuff. I simply kept my practice of malloc(big), free(big),
malloc(needed) or talking straight to PharLap.
Hi Grant,
I get the memory protection fault when I execute a pxp_draw_item(). If I
remove the realloc on XVData & XFData, everthing works OK. Executing reallocs
on two of my own structures doesn't cause a problem.
BTW, I'm using the shipping version of the toolkit that was distributed by
Chris Allis.
Regards,
Danny…
<realloc on XVDATA leads to protection fault>
I am mystified. realloc() is just a front end to malloc(), free(),
and memmove(). Maybe you should write your own realloc?
Wanna try something for me? Set your linker maxdata to something
really large, say 5 megs, and see if the problem clears up. I
strongly suspect that neither Metaware or Watcom were meant to run
with a maxdata of 0, it works okay for a while, but maybe the realloc
rubs the memory allocators the wrong way.
I'll give the maxdata suggestion a try and get back to you.