Author Topic: why would this cause a crash?  (Read 1735 times)

0 Members and 1 Guest are viewing this topic.

Offline Bobboau

  • Just a MODern kinda guy
    Just MODerately cool
    And MODest too
  • 213
why would this cause a crash?
i'm makeing my own POF loader, for... my own, twisted emusement...:nervous:
anyway,
why won't this get past the first obj2?

if I make the buffer a static sized array it works flawlessly, but I wanted it to be dynamicaly alocated
(becase I can't be sure what the largest data chunk size would be)
note the

memcpy
debug_string.Format
MessageBox

is how I'm telling if it is loading things properly and will be removed once it's working

Code: [Select]

int ID = '    ';
subobject = 0;
int SIZE;
char *buffer;
CString debug_string;
char id_str[5] = "    ";

MessageBox(NULL, "made it into the loader", "!", MB_OK);

FILE *pof_file=fopen(filename, "rb");

fread(&id, sizeof(int), 1, pof_file);
fread(&size, sizeof(int), 1, pof_file);

memcpy(&id_str, &id, 4);
debug_string.Format("id %s ver %d", id_str, size);
MessageBox(NULL, debug_string, "!", MB_OK);


while(!feof(pof_file)){
fread(&ID, sizeof(int), 1, pof_file);
fread(&SIZE, sizeof(int), 1, pof_file);

memcpy(&id_str, &ID, 4);
debug_string.Format("id %s size %d", id_str, SIZE);
MessageBox(NULL, debug_string, "!", MB_OK);

buffer = new char[SIZE];
fread(&buffer, sizeof(char), SIZE, pof_file);
}


for the time I'm makeing it staticly sized so I can move on.
Bobboau, bringing you products that work... in theory
learn to use PCS
creator of the ProXimus Procedural Texture and Effect Generator
My latest build of PCS2, get it while it's hot!
PCS 2.0.3


DEUTERONOMY 22:11
Thou shalt not wear a garment of diverse sorts, [as] of woollen and linen together

 

Offline RandomTiger

  • Senior Member
  • 211
why would this cause a crash?
* You should check to make sure 'fopen' is not failing, if it does it will probably crash because you will be trying to read with a null file pointer.

* You should also check that new doesnt fail. If your machine is short on memory (not likely these days) it could fail, returning a null pointer which would crash when you use it.

* Make sure you delete 'buffer' when you are finished with it or you will get a memory leak.

* Make sure you 'fclose' your file or it will remain open and next time you run the program because you have no check on 'fopen' it will crash

Also Im sure your memcpy's are wrong.

And your final 'fread' code looks a bit funny. Look at the function definition for fread:
Code: [Select]

size_t fread(void* ptr, size_t size, size_t nobj, FILE* stream);

It requires a pointer (void *, compatible with char *) to the buffer to store data in and you are giving it the address of the pointer to the buffer. In effect you are giving it a pointer to a pointer to the data.

That means that it would be overwriting memory again. Which can sometimes cause a crash or sometimes not. It just depends on what happens to be running in the memory you scrub.

This site my be of some use http://www.iota-six.co.uk/c/36_file_s.htm

If you're using visual C make a debug build and when it crashes use the debugger to see what values all your variables have and that will show you where your problems lie.
« Last Edit: January 02, 2003, 08:59:42 am by 848 »

  

Offline Bobboau

  • Just a MODern kinda guy
    Just MODerately cool
    And MODest too
  • 213
why would this cause a crash?
1: it's not failing, I have been able to get at most of the data within the POF file

2: I'm fairly sure this is were the problem is, for some reason it seems to be returning NULL (and thus is failing), I defanantly am not running out of ram, and if I have the buffer set staticly (char *buffer[some big number I can't remember off the top of my head]) it works  :wtf:

3: it get's deleted further down from this section

4: it does get closed

I don't think fread was letting me use *char

as you may see I was just copying the raw byte data and useing some 'fun' pointer math to load the data into some variables, it's been working so far, right down to the OBJ2 BSP data (it get's a little harry in the realy tight parts with the tmapped polys), so I think it's working

anyway, is there a good explaination on how to use new and things that it doesn't like,

I've also been getting some odd errors with some other arrays were they won't let me set them staticly, thus I have to use new
Bobboau, bringing you products that work... in theory
learn to use PCS
creator of the ProXimus Procedural Texture and Effect Generator
My latest build of PCS2, get it while it's hot!
PCS 2.0.3


DEUTERONOMY 22:11
Thou shalt not wear a garment of diverse sorts, [as] of woollen and linen together

 

Offline mikhael

  • Back to skool
  • 211
  • Fnord!
    • http://www.google.com/search?q=404error.com
why would this cause a crash?
roughly:

Code: [Select]

uint32 *ptr_someInt; // declare a uint32 pointer
ptr_someInt = new uint32; // allocate memory for a uint32 and stuff the address into ptr_someInt


"new" just returns a pointer of the appropriate type to a chunk of memory off the heap. So for an array of character arrays (an example that I am working with right now:

Code: [Select]

int numrows=9;  // arbitrary nonstatic rvalue
char ***_grid; // pointer to an array of pointers/arrays
// allocate an array of char pointers
// exactly numrows wide
_grid=new char**[numrows];


if you're needing to create an object instance, you pass your constructor arguments:
Code: [Select]

SOME_OBJECT* thing;
 // allocates a SOME_OBJ, calling the
// constructor that matches the supplied args
thing = new SOME_OBJ(foo, bar, baz);


new returns a NULL pointer on a failure, so you should check for that before you use it. Don't forget to clean up after yourself with 'delete'.

Like I said, that's rough, but servicible.
« Last Edit: January 02, 2003, 11:43:11 pm by 440 »
[I am not really here. This post is entirely a figment of your imagination.]