i'm developing on a laptop, and when i gave a demo to my friend with a laptop, it ran fine, but when i copied the demo to desktops, it did this: for every, like, 2 to 3 seconds, there would be a hard drive access. eventually, after say, 2 minutes, the demo would produce an illegal operation and quit. is there a way to fix this? is this a diff between laptops and desktops(compilation?), or should i give more info? opengl development laptop: ati rage pro desktop 1: starfighter card (whatever that is) desktop 2: voodoo 2 a2k Edited by - a2k on 7/7/00 11:41:57 PM

Hmmm... actually it should run *better* on a desktop. That''s extremely odd laptops are natorious (sp?) for being worse then desktops. Two things I would check the amount of ram in the desktops vs. the laptops and the virtual memory settings, maybe windows is being forced to do some serious virtual memory actions causing the hd jitter and eventually a crash if it''s that bad!

Try also running your game on a desktop with *NOTHING* running close any tray icons, or other apps...

E-mail me with more question as I''ll probably loose track of this thread but I''ll try to remember to look back!

See ya,
Ben

It sounds like you have a memory leak, and the computer starts to page to disk when it runs out of physical RAM. Look over your code and make sure you''re freeing everything you allocate.

it probably IS a memory leak, but how would i deal with finding/fixing these things? does that garbage collection article suggest what i need, and should i look around for articles such as this one?

a2k

okay, i''m bringing this one back up from the dead.

it turns out that the same problem happens on my laptop now. i noticed that it DOES page to disk, and creates a large swap file as long as my program is running. (i had win explorer up and saw the available disk space count go down). so yes, it is a memory leak, but i don''t know how to deal with this.

also, i found something in my code that could possibly contribute to this disk paging. it may sound really stupid, or it may make me sound really stupid, but i learned GLUT a few months ago, and now, i find out that i didn''t structure my GLUT code properly. the glutDisplayFunc() function is supposed to be the rendering callback function, but instead, (i started months ago) i had put my WHOLE GAME LOOP as the function as my rendering callback function. do you think this would cause the disk paging problem, or is it really some variables in my code?

a2k

Well, I don't know anything about GLUT, but if it is a problem with not deallocating memory, then you should look up _CrtDumpMemoryLeaks() in the MSDN docs (if you're using VC++, I don't know if Borland or anything has an equivalent). This function will dump memory leaks to the debug window, and then you can use _CrtSetDbgBreak() to set a breakpoint on the allocation of the offending memory.

There are some things you need to define, and some required #includes, but that should all be in the docs

Hope this helps!

Edited by - Qoy on July 25, 2000 1:12:11 AM

i''ve detected memory leaks, but i''m still not quite sure as to how i would perform fixing my code to prevent leaks. i mean, i know of leaks due to not "deleting" objects that were created from "new" and i only create 3 objects with the NEW keyword. how else can memory leaks be generated, and how do i fix them? or, where are some documents that cover dealing with memory leaks? more help is greatly appreciated. it''s eatin'' up my hard drive.

a2k

Ahhh, poor soul. The memory leak is a very difficult beast to find.

First, if you''re using MSVC++, run the program in debug mode. When you quit, does the output window show "Memory Leak Detected!". If so, you might have a chance to see exactly what''s leaking. Sometimes the file & line # appear where the un-released resource was allocated. Most times, though, it doesn''t.

If that doesn''t get you anywhere, it''s possible your memory isn''t leaking, but maybe you''re allocating an ever-growing array somewhere, and waiting until the end to delete it all? I had a colleague who wrote an MP3 player, but he never released any of the buffers he used to send data to the sound card until the program closed. So, he''d try to leave it running for a while and the entire computer would just bog down. Then he quit, and everything was released--no leaks! (but really bad design).

If you''re still stuck, get out ye olde windows tools. In NT there''s something called performance monitor. I think there''s also a tool for 95/98, though you may have to install it from your CD-ROM. Run your program and watch the memory and handles (handle leaks are almost worse than memory leaks) allocated to your program. Hopefully you''ll be able to see which routines are running when your memory is growing and be able to track it down.

In order to prevent this in the future, here''s what I do:
- almost never, ever, ever ''new'' anything. I''ll put any kind of wrapper or container around an object before I''m forced to ''new'' it to a pointer.
- if you have to new something, make sure the delete method is symmetric; if you new in a constructor, delete in the destructor. NEVER write a class where one method ''new''s something and the user must remember to call another method so that it gets ''delete''d.
- if you have classes that have poitners to new''d objects, either write or disable the copy constructor and assignment operator.

Hope this helps.

okay, i''ve balanced all my news and deletes, and i''ve fixed it all up, but now i''m having the original problem that i started with this post. The desktop hits an illegal operation after a while, and my laptop doesn''t. so if anyone knows if it was a bad move to put my main loop in the GLUT render callback function, please tell me. i think i''ll post in NeHe, too....

a2k

There are certain api calls that allocate memory as well. Just because you''re paring every new with a delete doesn''t mean you''re code is leak proof. On top of that, because your code is crashing in the middle means that something is probably being allocated in a loop over and over again, without being destroyed.

-BacksideSnap-