gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

DS development > [Fixed]Strange Behaviour ...HELP

#71755 - ishraam - Tue Feb 14, 2006 7:15 am

Hi,

I've just had a strange problem : my app crashes because of a SEG FAULT caused by a "for(...)" whose max limit has been changed by... the hardware I guess (not me anyway!).

Just have a look at this (IT USES GBFS):
Code:

void Mesh::LoadFromFile()
{
[...]
for( uint32 curVert = 0; curVert < this->numVertices; curVert ++)
   {
      readstr(oneline);
      sscanf(oneline, "%f %f %f %f %f", &x, &y, &z, &u, &v);
      
      iprintf(" d/%d)",curVert+1,numVertices);
      vertices[curVert].position   = AL_Vector3(x,y,z);      
      vertices[curVert].tex      = AL_TexCoord(u,v);    
      vertices[curVert].normal   = AL_Vector3(0.f,1.f,0.f);
   }
 
       return;
}

When curVert is equal to this->numVertices, this->numVertices value get totally f**ed up. And of course > seg fault.

I noticed that with enough "iprintf(...);" in this function, there's no problem anymore.
So I thought "damn do I need a volatile or what ?". So I tried, but no difference.

Do you have any idea of what's the problem ???

EDIT :

I've played some more with the code.
Declaring "numVertices" as an int instead of a uint32 had no effect.

BUT, after having removed all of the "iprintf(...)" that were close to GL functions, the problem disappeared.
When I say "close to GL functions", I mean any other member function like a DrawNormals() that would have a simple
Code:
"iprintf("yo");"

would cause the same error (in the same LoadFromFile() function!!)...

Event though the problem is "gone", I still cannot understand all this.
And I definitely wanna understand, so here again :

Do you have any idea of what's the problem ???

EDIT ..AGAIN:

Daaamn!

I can't even add a member function to load a texture. It causes the same problem (and without any "iprintf(...)" around > so I guess that's not related) : the member variable "numVertices" of my "Mesh" class gets changed during the loop.

That's driving me crazy!

Last edited by ishraam on Wed Feb 15, 2006 8:48 am; edited 2 times in total

#71800 - ishraam - Tue Feb 14, 2006 4:19 pm

Just to make things clear and short : The problem is still there.

If anyone has an idea as of why the value of this member variable "numVertices" gets changed, I'd be glad to hear(read) it ^_^.

I don't know if this might be related to GBFS, but it's the only piece of code where I'm using it.

If you have a little time, here is the whole project.
[url]
http://alexandre.trog.free.fr/DS_workspace/AL_Project.zip
[/url]

It's in : AL_Mesh.cpp, func: AL_Mesh::LoadFromFile(const char *)

Note that it runs better on real hardware.

#71868 - duencil - Wed Feb 15, 2006 12:29 am

You might need to add range checking to your readstr function to prevent buffer overflows.

#71890 - HyperHacker - Wed Feb 15, 2006 4:22 am

Yep, usually when you get weirdness like certain functions messing up unrelated things, it's caused by memory corruption.

#71913 - ishraam - Wed Feb 15, 2006 8:45 am

I just checked a few things, (and implemented my file classes btw).

You were right : it looks like I modified the World.txt (provided in libnds examples) without noticing. So the number of polys were wrong, the app tried to grab junk data, hence the memory corruption.


Thank you for your time, and help : I really appreciate it ^_^.
I'm sorry to have bother you for something this stupid.

For some reason I was kinda persuaded that it was related to something specific to the NDS...

(I'd better stop coding past 4 am ... Looks like my mind is totally fucked up at that time of the day -_-)