memory allocation nightmare

[berthelot samuel]

Hi,
I'm trying to develop an application for modeling 3D objects from
Bezier patches, but I have a memory allocation problem. Here are my
structures:

typedef struct _vector3 {
union
{
struct
{
float x, y, z;
};
float v[3];
};
}vector3;

typedef struct _vertex {
vector3 pos;
vector3 normal;
float r, g, b;
}vertex;

typedef struct _tri {
vertex vertices[3];
vector3 normal;
}tri;

typedef struct _patch {
vector3 matrix_cp[4][4]; //16 control points of the patch
vertex patch_vertices[POINTS_ON_CURVE][POINTS_ON_CURVE]; //list of
vertices of the patch
tri* elmt; //list of triangles of the patch
int triCount; //number of triangles on the patch
}patch;

Here is the line I use to allocate the memory for elmt:

g_myPatch->elmt = malloc(((POINTS_ON_CURVE - 1) * (POINTS_ON_CURVE -
1) * 2) * sizeof(tri));

Up to 30 for POINTS_ON_CURVE the program works fine, but beyond this
value, it crashes at the line above. I wonder if it could be related
to the awkward attribute
vertex patch_vertices[POINTS_ON_CURVE][POINTS_ON_CURVE]; of the patch
structure. But I need a 2D array, so I can't avoid it.

Does anybody know where does this problem come from ?
Thx
Sam

[Malcolm]

"berthelot samuel" <sa**************@voila.fr> wrote in message

Here is the line I use to allocate the memory for elmt:

g_myPatch->elmt = malloc(((POINTS_ON_CURVE - 1) *
(POINTS_ON_CURVE -1) * 2) * sizeof(tri));

Up to 30 for POINTS_ON_CURVE the program works fine, but > beyond this value, it crashes at the line above. I wonder if it could be related to the awkward attribute
vertex patch_vertices[POINTS_ON_CURVE]
[POINTS_ON_CURVE]; of the patch
structure. But I need a 2D array, so I can't avoid it.

Does anybody know where does this problem come from ?

I presume POINTS_ON_CURVE is a constant. A call to malloc() shouldn't crash
(though it may return 0), so if it does it indicates memory corruption.
Allocating an array of (N-1) * (N-1) * 2 is just asking for a bounds overrun
error somewhere in your code. I would change temporarily to N * N * 2 and
see if the crash goes away, probably to be replaced by incorrect results.
Then you need to trawl through the code looking for the error, remembering
that you have reduced the array size by an amount proportional to the square
of POINTS_ON_CURVE.
The other thing to check is that you haven't put any structures on the
stack. An array of 30*30 is 900 elements, too big for many platforms to
handle.

[Chris Torek]

In article <news:ca**************************@posting.google. com>
berthelot samuel <sa**************@voila.fr> writes:

typedef struct _vector3 {
Names beginning with underscores are, well, "iffy" at best. You
can use some in some scopes, but others are always reserved, and
there is no reason to write "_vector3" here. Structure tag names
live in a separate name space, so it is OK to write:

typedef struct S S;
struct S { ... };

(assuming you really want to use the typedefs in the first place;
see any of my earlier postings on the subject for more details).

With that out of the way, let me move on to the contents of
"struct _vector3 {":
union
{
struct
{
float x, y, z;
};
float v[3];
};
}
Here the structure contains no members, but does declare a union
that has no tag. That union contains one member named "v", which
is an array of size 3 of element-type "float", and also declares
another struct with no tag.

These are not legal in C. (They are valid GNUC and Plan-9-C
constructs, but neither of those compilers defines the Standard C
language. I happen to think they *ought* to have been put into
C99, but apparently they were not, so what I think is not really
relevant. :-) )

To rewrite this in Standard C, steering clear of dogdy names like
"_vector3", and to keep the typedef but mark it for human-factors
reasons, you might use something like this:

typedef struct vector3 VECTOR3;
struct vector3 {
union {
struct {
float x, y, z;
} s;
float v[3];
} u;
};

Of course, now in order to access the "v" array or "s" struct member
of a struct vector3 object, you have to write out the intermediate
names:

VECTOR3 vec;
...
vec.u.v[i] = some_value;
...
vec.u.s.z = some_value;
...

Finally, I should note here that -- while it is likely to work on
most systems -- the C Standards only *guarantee* that you can
retrieve things from vec.u.s if you have stored them via vec.u.s,
and retrieve things from vec.u.v if you have stored them that way.
One can also make a technical argument that vec.u.v[0] and vec.u.s.x
must necessarily be the same object, and thus be cross-accessible
as it were, but a compiler is free to pretend that the structure
had been written as, e.g.:

struct {
float x;
float pad1;
float y;
float pad2;
float z;
float pad3;
}

In other words, a compiler might insert padding between the x, y,
and z members, so that the v[] array -- which *must not* contain
internal padding -- does not overlay all three of the structure
members. (I know of no compilers that are annoying enough to do
this to the programmer, but the Standard permits it.)

It might therefore be wise to avoid the entire union trick, and
just use an array of size 3 as the only element of the structure.
You can then "#define" indices into the array to denote the X, Y,
and Z axes:

typedef struct vector3 VECTOR3;
struct vector3 {
float v[3];
};
#define VEC3_X 0
#define VEC3_Y 1
#define VEC3_Z 2
...
VECTOR3 vec;
...
vec.v[VEC3_X] = x_value;
vec.v[VEC3_Y] = y_value;
vec.v[VEC3_Z] = z_value;
typedef struct _vertex {
vector3 pos;
vector3 normal;
float r, g, b;
}vertex;

typedef struct _tri {
vertex vertices[3];
vector3 normal;
}tri;
Again, I would recommend avoiding the leading underscores.
typedef struct _patch {
vector3 matrix_cp[4][4]; //16 control points of the patch
vertex patch_vertices[POINTS_ON_CURVE][POINTS_ON_CURVE]; //list of
vertices of the patch
Note that your news software has split your comment into two lines,
so that it is now a syntax error. This is one problem with C99's
"//" comments.
tri* elmt; //list of triangles of the patch
int triCount; //number of triangles on the patch
}patch;

Here is the line I use to allocate the memory for elmt:

g_myPatch->elmt = malloc(((POINTS_ON_CURVE - 1) * (POINTS_ON_CURVE -
1) * 2) * sizeof(tri));
This call looks OK, provided POINTS_ON_CURVE is at least 2, although
you might want to use the "comp.lang.c tested" variant:

g_myPatch->elmt = malloc(n * sizeof *g_myPatch->elmt);

(where n here is twice the square of one less than POINTS_ON_CURVE,
as above).
Up to 30 for POINTS_ON_CURVE the program works fine, but beyond this
value, it crashes at the line above. I wonder if it could be related
to the awkward attribute
vertex patch_vertices[POINTS_ON_CURVE][POINTS_ON_CURVE]; of the patch
structure. But I need a 2D array, so I can't avoid it.

Does anybody know where does this problem come from ?

As Malcolm suggested elsethread, you might be running into stack
limits -- 31*31 is 961, and a "vertex" consists of two "vector3"s
and three "float"s. A "float" is typically four bytes, and a
"vector3" will typically be 12 or 16 bytes, so the usual case is
either 2*12 + 3*4 = 24 + 12 = 36, or perhaps 2*16 + 3*4 = 32 + 12
= 44 bytes. There may also be four bytes of padding following the
"b" member of a "vertex", raising these numbers to 40 and 48 bytes
respectively. If there are 961 of these "vertex" array elements
in a "patch", and each one is 48 bytes, that requires 46128 bytes
just for the patch_vertices member.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[berthelot samuel]

Hi Chris,
Thank you for your relevant advice.
It seems that my structure uses a lot of memory indeed. But what can I
do to overcome this ? I can't really change my structures now...
Has anyone got a genius idea ?
cheers,
Sam
Chris Torek <no****@torek.net> wrote in message news:<c5*********@news4.newsguy.com>...

In article <news:ca**************************@posting.google. com>
berthelot samuel <sa**************@voila.fr> writes:

typedef struct _vector3 {

Names beginning with underscores are, well, "iffy" at best. You
can use some in some scopes, but others are always reserved, and
there is no reason to write "_vector3" here. Structure tag names
live in a separate name space, so it is OK to write:

typedef struct S S;
struct S { ... };

(assuming you really want to use the typedefs in the first place;
see any of my earlier postings on the subject for more details).

With that out of the way, let me move on to the contents of
"struct _vector3 {":

union
{
struct
{
float x, y, z;
};
float v[3];
};
}

Here the structure contains no members, but does declare a union
that has no tag. That union contains one member named "v", which
is an array of size 3 of element-type "float", and also declares
another struct with no tag.

These are not legal in C. (They are valid GNUC and Plan-9-C
constructs, but neither of those compilers defines the Standard C
language. I happen to think they *ought* to have been put into
C99, but apparently they were not, so what I think is not really
relevant. :-) )

To rewrite this in Standard C, steering clear of dogdy names like
"_vector3", and to keep the typedef but mark it for human-factors
reasons, you might use something like this:

typedef struct vector3 VECTOR3;
struct vector3 {
union {
struct {
float x, y, z;
} s;
float v[3];
} u;
};

Of course, now in order to access the "v" array or "s" struct member
of a struct vector3 object, you have to write out the intermediate
names:

VECTOR3 vec;
...
vec.u.v[i] = some_value;
...
vec.u.s.z = some_value;
...

Finally, I should note here that -- while it is likely to work on
most systems -- the C Standards only *guarantee* that you can
retrieve things from vec.u.s if you have stored them via vec.u.s,
and retrieve things from vec.u.v if you have stored them that way.
One can also make a technical argument that vec.u.v[0] and vec.u.s.x
must necessarily be the same object, and thus be cross-accessible
as it were, but a compiler is free to pretend that the structure
had been written as, e.g.:

struct {
float x;
float pad1;
float y;
float pad2;
float z;
float pad3;
}

In other words, a compiler might insert padding between the x, y,
and z members, so that the v[] array -- which *must not* contain
internal padding -- does not overlay all three of the structure
members. (I know of no compilers that are annoying enough to do
this to the programmer, but the Standard permits it.)

It might therefore be wise to avoid the entire union trick, and
just use an array of size 3 as the only element of the structure.
You can then "#define" indices into the array to denote the X, Y,
and Z axes:

typedef struct vector3 VECTOR3;
struct vector3 {
float v[3];
};
#define VEC3_X 0
#define VEC3_Y 1
#define VEC3_Z 2
...
VECTOR3 vec;
...
vec.v[VEC3_X] = x_value;
vec.v[VEC3_Y] = y_value;
vec.v[VEC3_Z] = z_value;

typedef struct _vertex {
vector3 pos;
vector3 normal;
float r, g, b;
}vertex;

typedef struct _tri {
vertex vertices[3];
vector3 normal;
}tri;

Again, I would recommend avoiding the leading underscores.

typedef struct _patch {
vector3 matrix_cp[4][4]; //16 control points of the patch
vertex patch_vertices[POINTS_ON_CURVE][POINTS_ON_CURVE]; //list of
vertices of the patch

Note that your news software has split your comment into two lines,
so that it is now a syntax error. This is one problem with C99's
"//" comments.

tri* elmt; //list of triangles of the patch
int triCount; //number of triangles on the patch
}patch;

Here is the line I use to allocate the memory for elmt:

g_myPatch->elmt = malloc(((POINTS_ON_CURVE - 1) * (POINTS_ON_CURVE -
1) * 2) * sizeof(tri));

This call looks OK, provided POINTS_ON_CURVE is at least 2, although
you might want to use the "comp.lang.c tested" variant:

g_myPatch->elmt = malloc(n * sizeof *g_myPatch->elmt);

(where n here is twice the square of one less than POINTS_ON_CURVE,
as above).

Up to 30 for POINTS_ON_CURVE the program works fine, but beyond this
value, it crashes at the line above. I wonder if it could be related
to the awkward attribute
vertex patch_vertices[POINTS_ON_CURVE][POINTS_ON_CURVE]; of the patch
structure. But I need a 2D array, so I can't avoid it.

Does anybody know where does this problem come from ?

As Malcolm suggested elsethread, you might be running into stack
limits -- 31*31 is 961, and a "vertex" consists of two "vector3"s
and three "float"s. A "float" is typically four bytes, and a
"vector3" will typically be 12 or 16 bytes, so the usual case is
either 2*12 + 3*4 = 24 + 12 = 36, or perhaps 2*16 + 3*4 = 32 + 12
= 44 bytes. There may also be four bytes of padding following the
"b" member of a "vertex", raising these numbers to 40 and 48 bytes
respectively. If there are 961 of these "vertex" array elements
in a "patch", and each one is 48 bytes, that requires 46128 bytes
just for the patch_vertices member.

[Rob Thorpe]

sa**************@voila.fr (berthelot samuel) wrote in message news:<ca**************************@posting.google. com>...

Hi,
I'm trying to develop an application for modeling 3D objects from
Bezier patches, but I have a memory allocation problem. Here are my
structures:

typedef struct _vector3 {
union
{
struct
{
float x, y, z;
};
float v[3];
};
}vector3;

typedef struct _vertex {
vector3 pos;
vector3 normal;
float r, g, b;
}vertex;

typedef struct _tri {
vertex vertices[3];
vector3 normal;
}tri;

typedef struct _patch {
vector3 matrix_cp[4][4]; //16 control points of the patch
vertex patch_vertices[POINTS_ON_CURVE][POINTS_ON_CURVE]; //list of
vertices of the patch
tri* elmt; //list of triangles of the patch
int triCount; //number of triangles on the patch
}patch;

Here is the line I use to allocate the memory for elmt:

g_myPatch->elmt = malloc(((POINTS_ON_CURVE - 1) * (POINTS_ON_CURVE -
1) * 2) * sizeof(tri));

Up to 30 for POINTS_ON_CURVE the program works fine, but beyond this
value, it crashes at the line above. I wonder if it could be related
to the awkward attribute
vertex patch_vertices[POINTS_ON_CURVE][POINTS_ON_CURVE]; of the patch
structure. But I need a 2D array, so I can't avoid it.

Does anybody know where does this problem come from ?
Thx
Sam

Also, in addition to what others have said:
Once you screw up dynamic allocation it stays screwed up. Your
mistake could be somewhere else completely. It may only manifest
itself here.

[Rakesh]

berthelot samuel wrote:

typedef struct _patch {
vector3 matrix_cp[4][4]; //16 control points of the patch
vertex patch_vertices[POINTS_ON_CURVE][POINTS_ON_CURVE]; //list of
vertices of the patch
tri* elmt; //list of triangles of the patch

Plz avoid using pointers at all costs, instead it would be nice to any
of the STLs ( vector , list , linkedlist whatever suits your application
) . That would lota headache and would make you focus on the problem
at hand, instead of getting diverted .

--
Rakesh Kumar
** Remove nospamplz from my email address if you need to drop me an
email **

[Peter Pichler]

"Rakesh" <dr******************@yahoo.com> wrote in message
news:40841411$1@darkstar...

Plz avoid using pointers at all costs,
He who is afraid of pointers should not write C.
instead it would be nice to any
of the STLs ( vector , list , linkedlist whatever suits your application

Ah, you don't. I see.

Peter

[Keith Thompson]

Rakesh <dr******************@yahoo.com> writes:

berthelot samuel wrote:

typedef struct _patch {
vector3 matrix_cp[4][4]; //16 control points of the patch
vertex patch_vertices[POINTS_ON_CURVE][POINTS_ON_CURVE]; //list of
vertices of the patch
tri* elmt; //list of triangles of the patch

Plz avoid using pointers at all costs, instead it would be nice to any
of the STLs ( vector , list , linkedlist whatever suits your
application ) . That would lota headache and would make you focus on
the problem at hand, instead of getting diverted .

That would probably be good advice in comp.lang.c++.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"

[berthelot samuel]

Hi,
I'm having serious trouble with memory allocation (again).
I've solved the problem mentioned above through changing my structures
(no more redundancies). However there's still something wrong as when
I'm trying to allocate memory for more than one patch, things get
screwed up. Here are my new structures:

#define POINTS_ON_CURVE 50
#define PATCH_SIZE POINTS_ON_CURVE * POINTS_ON_CURVE

typedef struct _vector3 {
union
{
struct
{
float x, y, z;
};
float v[3];
};
}vector3;

typedef struct _vertex {
int id;
vector3 pos;
vector3 normal;
float r, g, b;
float u, v;
}vertex;

typedef struct _tri {
int id;
int vertices[3]; //vertices ids
vector3 normal;
}tri;

typedef struct _cp {
vector3 elmt[4][4]; //16 control points of the patch
}cp;

typedef struct _patch {
int id;
vertex* vertices; //list of vertices ofthe patch
tri* triList; //list of triangles of the patch
cp* cpList; //list of control points
int triCount; //number of triangles on the patch
int vertexCount; //number of vertices on the patch
}patch;

typedef struct _object {
int patchCount; //number of patches of the object
patch *patch; //list of patches of the object
}object;
//an object made of surface patches
object* g_myObject;

//a single patch
patch* g_myPatch;
Here I allocate the memory for one patch and then for an object made
of 4 patches:

/*
* Allocate memory for g_myPatch and assign control points - used for
* single patch only
*/

g_myPatch = malloc(sizeof(patch));
g_myPatch->vertices = malloc (PATCH_SIZE * sizeof(vertex));
g_myPatch->triCount = (POINTS_ON_CURVE - 1) * (POINTS_ON_CURVE - 1) *
2;
g_myPatch->triList = malloc(g_myPatch->triCount * sizeof(tri));
g_myPatch->cpList = malloc(sizeof(cp));

g_myPatch->cpList->elmt = malloc(16 * sizeof(vector3));

g_myPatch->cpList->elmt[0][0] = g_controlPoint11;
g_myPatch->cpList->elmt[0][1] = g_controlPoint12;
g_myPatch->cpList->elmt[0][2] = g_controlPoint13;
g_myPatch->cpList->elmt[0][3] = g_controlPoint14;

g_myPatch->cpList->elmt[1][0] = g_controlPoint21;
g_myPatch->cpList->elmt[1][1] = g_controlPoint22;
g_myPatch->cpList->elmt[1][2] = g_controlPoint23;
g_myPatch->cpList->elmt[1][3] = g_controlPoint24;

g_myPatch->cpList->elmt[2][0] = g_controlPoint31;
g_myPatch->cpList->elmt[2][1] = g_controlPoint32;
g_myPatch->cpList->elmt[2][2] = g_controlPoint33;
g_myPatch->cpList->elmt[2][3] = g_controlPoint34;

g_myPatch->cpList->elmt[3][0] = g_controlPoint41;
g_myPatch->cpList->elmt[3][1] = g_controlPoint42;
g_myPatch->cpList->elmt[3][2] = g_controlPoint43;
g_myPatch->cpList->elmt[3][3] = g_controlPoint44;

/*
* Allocate memory for g_myObject and assign patches and control
points
*/

g_myObject = malloc(sizeof(object));
g_myObject->patchCount = 2;
g_myObject->patch = malloc(g_myObject->patchCount * sizeof(patch));
Note that g_controlPoint11…. are of type vector3.

Here comes the problem. After 3 iterations, the value of
g_myObject->patchCount is changed by the value of
g_myObject->patch[i].triCount (722) and therefore everything gets
screwed up.

for (i = 0; i < g_myObject->patchCount; i ++)
{
g_myObject->patch[i].vertices = malloc (PATCH_SIZE *
sizeof(vertex));
g_myObject->patch[i].triCount = (POINTS_ON_CURVE - 1) *
(POINTS_ON_CURVE - 1) * 2;
g_myObject->patch[i].triList = malloc(g_myObject->patch[i].triCount
* sizeof(tri));
g_myObject->patch[i].cpList = malloc(sizeof(cp));
}

So my questions is: Where am I doing something wrong !?!?!?
I thought that it could come from my structure _cp, so I've tried to
change it from that:

typedef struct _cp {
vector3 elmt[4][4]; //16 control points of the patch
}cp;

to that:

typedef struct _cp {
vector3 ** elmt; //16 control points of the patch
}cp;

but then the line g_myPatch->cpList->elmt[0][0] = g_controlPoint11;
doesn't work any more. Why?

I know this problem is pretty long so thank you to those of you who
read that until the end of it.
Can you help?
Thx
Sam.

Keith Thompson <ks***@mib.org> wrote in message news:<ln************@nuthaus.mib.org>...

Rakesh <dr******************@yahoo.com> writes:

berthelot samuel wrote:

typedef struct _patch {
vector3 matrix_cp[4][4]; //16 control points of the patch
vertex patch_vertices[POINTS_ON_CURVE][POINTS_ON_CURVE]; //list of
vertices of the patch
tri* elmt; //list of triangles of the patch

Plz avoid using pointers at all costs, instead it would be nice to any
of the STLs ( vector , list , linkedlist whatever suits your
application ) . That would lota headache and would make you focus on
the problem at hand, instead of getting diverted .

That would probably be good advice in comp.lang.c++.

[Barry Schwarz]

On 22 Apr 2004 05:34:54 -0700, sa**************@voila.fr (berthelot
samuel) wrote:

Hi,
I'm having serious trouble with memory allocation (again).
You don't even get that far. Your first typedef is illegal. How can
you execute if it doesn't compile?

Additionally, why are you declaring a struct which consist of nothing
more than a single union? A struct with a single member is usually a
sign of poor design.
I've solved the problem mentioned above through changing my structures
(no more redundancies). However there's still something wrong as when
Make up your mind. Either you have solved the memory allocation
problem (the only one mentioned above) or you are having problems
again.
I'm trying to allocate memory for more than one patch, things get
screwed up. Here are my new structures:
Please post compilable code.

#define POINTS_ON_CURVE 50
#define PATCH_SIZE POINTS_ON_CURVE * POINTS_ON_CURVE

typedef struct _vector3 {
union
{
struct
{
float x, y, z;
};
float v[3];
};
}vector3;

snip 150 lines of incomplete and incomprehensible code.
<<Remove the del for email>>

[berthelot samuel]

Hi,
You sound like you are taking the piss at me ! relax man.
When I said I had solved the problem mentioned above I was obviously
talking about the first thread in the list, read more carefully next
time!
I don't know if my structure are poorly designed, but what I know is
that neither gcc nor visual c++ ever complained about my structures.
Without the memory allocation problem, my program runs fine...

now to get back to my problem, here is the code and only the code that
screws up

Now I don't do any memory allocations before the ones that are
responsible for the crash, therefore there must be definitely
something wrong in this few lines. First my structures:

#define POINTS_ON_CURVE 50
#define PATCH_SIZE POINTS_ON_CURVE * POINTS_ON_CURVE

typedef struct _vertex {
int id;
vector3 pos;
vector3 normal;
float r, g, b;
float u, v;
}vertex;

typedef struct _tri {
int id;
int vertices[3]; //vertices ids
vector3 normal;
}tri;

typedef struct _cp {
vector3** elmt; //16 control points of the patch
}cp;

typedef struct _patch {
int id;
vertex* vertices; //list of vertices of the patch
tri* triList; //list of triangles of the patch
cp* cpList; //list of control points
int triCount; //number of triangles on the patch
int vertexCount; //number of vertices on the patch
}patch;

typedef struct _object {
int patchCount; //number of patches of the object
patch *patch; //list of patches of the object
}object;

//an object made of surface patches
object* g_myObject;
Now the set of memory allocations:

/*
*Allocate memory for g_myObject and assign patches and control points
*/

g_myObject = malloc(sizeof(object));
g_myObject->patchCount = 4;
g_myObject->patch = malloc(g_myObject->patchCount * sizeof(patch));

for (i = 0; i < g_myObject->patchCount; i ++)
{
g_myObject->patch[i].vertices = malloc (PATCH_SIZE * sizeof(vertex));

g_myObject->patch[i].triCount = (POINTS_ON_CURVE - 1) *
(POINTS_ON_CURVE - 1) * 2;

g_myObject->patch[i].triList =
malloc(g_myObject->patch[i].triCount * sizeof(tri));

g_myObject->patch[i].cpList = malloc(sizeof(cp));

g_myObject->patch[i].cpList->elmt = (vector3**)malloc(4 *
sizeof(vector3));

for (j = 0; j < 4; j ++)
g_myObject->patch[i].cpList->elmt[j] = (vector3*)malloc(4 *
sizeof(vector3));

}

In the first for loop, when i=2, after it executes the third line, the
value of < g_myObject->patchCount changed suddenly from 4 to 4802 (the
value of g_myObject->patch[i].triCount) for no reason !!!

Please if someone is really good at C programming could you help on
this, because I'm desperate :(
Thx
Sam


Barry Schwarz <sc******@deloz.net> wrote in message news:<c6**********@216.39.135.79>...

On 22 Apr 2004 05:34:54 -0700, sa**************@voila.fr (berthelot
samuel) wrote:

Hi,
I'm having serious trouble with memory allocation (again).

You don't even get that far. Your first typedef is illegal. How can
you execute if it doesn't compile?

Additionally, why are you declaring a struct which consist of nothing
more than a single union? A struct with a single member is usually a
sign of poor design.

I've solved the problem mentioned above through changing my structures
(no more redundancies). However there's still something wrong as when

Make up your mind. Either you have solved the memory allocation
problem (the only one mentioned above) or you are having problems
again.

I'm trying to allocate memory for more than one patch, things get
screwed up. Here are my new structures:

Please post compilable code.

#define POINTS_ON_CURVE 50
#define PATCH_SIZE POINTS_ON_CURVE * POINTS_ON_CURVE

typedef struct _vector3 {
union
{
struct
{
float x, y, z;
};

float v[3];

};
}vector3;

snip 150 lines of incomplete and incomprehensible code.
<<Remove the del for email>>

[CBFalconer]

berthelot samuel wrote:

You sound like you are taking the piss at me ! relax man.
When I said I had solved the problem mentioned above I was obviously
talking about the first thread in the list, read more carefully next
time!
I don't know if my structure are poorly designed, but what I know is
that neither gcc nor visual c++ ever complained about my structures.
Without the memory allocation problem, my program runs fine...

You don't appear to really want help, since you insist on
top-posting, fail to snip, and fail to post compilable code.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[berthelot samuel]

Hi,
what is top-posting ?
I can't post compilable code since it would be way too big. Moreover
I've put the minimum code I could, so that it is understandable.
If I did not want help, I would not even be writting this message.
What's wrong with you guys ? You all had a very bad week or what ? I'm
just struggling with this problem and I was asking for help. If you
don't want to help, just don't read my messages...

CBFalconer <cb********@yahoo.com> wrote in message news:<40***************@yahoo.com>...

berthelot samuel wrote:

You sound like you are taking the piss at me ! relax man.
When I said I had solved the problem mentioned above I was obviously
talking about the first thread in the list, read more carefully next
time!
I don't know if my structure are poorly designed, but what I know is
that neither gcc nor visual c++ ever complained about my structures.
Without the memory allocation problem, my program runs fine...

You don't appear to really want help, since you insist on
top-posting, fail to snip, and fail to post compilable code.

[Alberto Giménez]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

El 24 Apr 2004 02:34:31 -0700, berthelot samuel escribió:

Hi,
what is top-posting ?

A: Because it changes the order you read a conversation
Q: Why is top-posting so annoying?
A: Top-posting
Q: What is the most annoying thing in newsgroups?

I think it was something like this :)
- --
Alberto Giménez, SimManiac en el IRC
http://www.almorranasozial.es.vg
GNU/Linux Debian Woody 3.0 GnuPG ID: 0x3BAABDE1
Linux registered user #290801
Don't compare Linux with Windows. There's no colour (except blue).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQFAilpj0keCtzuqveERAvNtAJ99K10hbypy1lI50Tsfy2 vUfBqlCwCgk6V4
7DvYoTYNkrrkkrw6xHF6upY=
=gVOW
-----END PGP SIGNATURE-----

[Mark McIntyre]

On 24 Apr 2004 02:34:31 -0700, in comp.lang.c , sa**************@voila.fr
(berthelot samuel) wrote:

Hi,
what is top-posting ?
answered already by someone else
I can't post compilable code since it would be way too big. Moreover
I've put the minimum code I could, so that it is understandable.
Unfortunately your code is too incomplete. It relies on undefined types and
other stuff, any of which could be the source of the leak. It seems most
likely however that you've stuffed something too big into one of your
mallocs.
If I did not want help, I would not even be writting this message.

People aren't paid to help round here, they do it for fun. Its no fun being
helpful if people are rude to you.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

[Rob Thorpe]

sa**************@voila.fr (berthelot samuel) wrote in message news:<ca**************************@posting.google. com>...

Hi,
what is top-posting ?
I can't post compilable code since it would be way too big. Moreover
I've put the minimum code I could, so that it is understandable.
If I did not want help, I would not even be writting this message.
What's wrong with you guys ? You all had a very bad week or what ? I'm
just struggling with this problem and I was asking for help. If you
don't want to help, just don't read my messages...
I can't follow the code you've posted very well either.

Try downloading a memory allocation debugger, such as electric fence
and using it on your code.

CBFalconer <cb********@yahoo.com> wrote in message news:<40***************@yahoo.com>...

berthelot samuel wrote:

You sound like you are taking the piss at me ! relax man.
When I said I had solved the problem mentioned above I was obviously
talking about the first thread in the list, read more carefully next
time!
I don't know if my structure are poorly designed, but what I know is
that neither gcc nor visual c++ ever complained about my structures.
Without the memory allocation problem, my program runs fine...

You don't appear to really want help, since you insist on
top-posting, fail to snip, and fail to post compilable code.