I'm having headaches with something that should be very simple.
This is Stage Two of an MD3 (quake3) model loader.
In Stage One, I allocate a bunch of objects in heap memory (see t3DObject struct below), and I store an array of pointers to them.
Stage Two involves parsing some ".skin" files which are plaintext files, an example of which is found below. The parser's task is to read each line from the plaintext .skin file and search within each line for any matching object names (the array from Stage One). Should we find a match, we are to allocate a Material structure (also posted below) and copy the namestring across from the object struct to the material struct...
Does not sound too hard, does it?

Can I please have some help to identify the cause of the gpf which occurs?



; This holds the information for a material. It may be a texture map or a color.
; Some of these are not used, but I left them.
tMaterialInfo struct
strName db 256 dup (?); The texture name
strFile db 256 dup (?); The texture file name (If this is set it's a texture map)
color db 3 dup (?) ; The color of the object (R, G, B)
textureId dd ? ; The texture ID
uTile REAL4 ? ; u tiling of texture
vTile REAL4 ? ; v tiling of texture
uOffset REAL4 ? ; u offset of texture
vOffset REAL4 ? ; v offset of texture
tMaterialInfo ends

t3DObject struct
numOfVerts dd ? ;The number of verts in the model
numOfFaces dd ? ;The number of faces in the model
numTexVertex dd ? ;The number of texture coordinates
materialID dd ? ;The texture ID to use, which is the index into our texture array
bHasTexture BOOL ? ; This is TRUE if there is a texture map for this object
strName db 64 dup (?) ; The name of the object
pVerts dd ? ;ptr to Vec3 The object's vertices array
pNormals dd ? ;ptr to Vec3 The object's normals array
pTexVerts dd ? ;ptr to Vec2 The texture's UV coordinates array
pFaces dd ? ;ptr to tFace The facesarray information of the object
t3DObject ends


lara_lower.skin

tag_torso,
l_legs,models/players/laracroft/default.bmp
l_belt,models/players/laracroft/default.bmp


I will be happy to post the code which is failing, and/or post the entire thing, if anyone is willing to take the time to help track down this nasty gpf with me... basically the issue seems to be caused by malloc macro, which is odd because I use it frequently elsewhere without problems.In the erroneous code section, the malloc (sizeof tMaterialInfo) fails the third time I do it, and I wind up crashing inside NTDLL !!!
Posted on 2004-12-01 19:34:25 by Homer
:arrow: I enjoy debugging.

Feel free to upload to my website as there are no size limits, or email.
Posted on 2004-12-01 23:47:38 by bitRAKE
OK man you asked for it :)

I'll up everything to your site... we'll go from there.
I'm not simply interested in having someone fix my bugs, I actually want to know how to avoid it in future, so rest assured your time will not be wasted on me.
Posted on 2004-12-02 02:30:50 by Homer