Enginuity memory problem?
I am using the Enginuity engine. In an otherwise blank CTask, I create an std::list. In Start(), I resize it to 800.
When the program exits, it crashes. The error is an access violation at IMMObject::Release() (on the first line, RefCount--
This weird problem is driving me CRAZY. It only happens when the list gets big (like from adding elements one at a time).
Any ideas?
Thanks,
Flammicidia
1) Is the object being released somewhere else?
2) Is your listr of tasks a CTask* list? If not, then when the CTask goes out of scope, it will also delete the mmObject, creating an invalid pointer when the manager tries to release it
2) Is your listr of tasks a CTask* list? If not, then when the CTask goes out of scope, it will also delete the mmObject, creating an invalid pointer when the manager tries to release it
The list is a list of ints. I resize it in the Start() of the same CTask in which it is declared privately.
Why would it being released elsewhere matter, if none of my other objects have this problem, and it is size-dependant?
I'm not sure exactly what your #2 means. In the kernel, my tasks are stored in this: std::list< CMMPointer < ITask > >. It's worked for everthing else so far, but I haven't had any data structures this large yet, either (except in the graphics system, and perhaps the sound, but DirectX handled that).
--Flammicidia
EDIT: typo
[edited by - Flammicidia on January 18, 2004 5:42:18 AM]
Why would it being released elsewhere matter, if none of my other objects have this problem, and it is size-dependant?
I'm not sure exactly what your #2 means. In the kernel, my tasks are stored in this: std::list< CMMPointer < ITask > >. It's worked for everthing else so far, but I haven't had any data structures this large yet, either (except in the graphics system, and perhaps the sound, but DirectX handled that).
--Flammicidia
EDIT: typo
[edited by - Flammicidia on January 18, 2004 5:42:18 AM]
To me, the error you are getting tells me that you have already released the object that is being referenced. Believe me, my implementation of the MM has seen this problem; kinda irritating because I assumed that the MM was intended to stop this sort of thing.
Basically I see that the pointer is invalid - but to check further and eliminate the problem as being in the CTask object - does this problem happen if you have the list as 10, or a low number like that? Is the task deallocating it''s resources? I usually have an Init() / Destroy() method for most of my objects that allocate memory and lists. Are any MMobject pointers within the task being referenced elsewhere? If you forget to call Addref() everytime you hold the pointer it can cause problems later. Are you calling a ''new'' on every MMObject you create? If you create one in the body of the class eg:
Basically I see that the pointer is invalid - but to check further and eliminate the problem as being in the CTask object - does this problem happen if you have the list as 10, or a low number like that? Is the task deallocating it''s resources? I usually have an Init() / Destroy() method for most of my objects that allocate memory and lists. Are any MMobject pointers within the task being referenced elsewhere? If you forget to call Addref() everytime you hold the pointer it can cause problems later. Are you calling a ''new'' on every MMObject you create? If you create one in the body of the class eg:
class CRandom : public MMObject{ ... blah!};class CTest{ CRandom m_Problem; // problems will occur when the CTest object is deleted as the MMObject CRandom is also deleted when it goes out of scope CRandom *m_ImOK; // This will be ok as you have to call a new to create it, satisfying the reference counting of the MMObject};
Thanks for your reply.
No, there are no mm objects in the task. It only happens for high numbers. 500 worked, but 800 did not when I resized the list. Unless the list is being managed without my knowledge, it... well, is not managed.
--Flammicidia
No, there are no mm objects in the task. It only happens for high numbers. 500 worked, but 800 did not when I resized the list. Unless the list is being managed without my knowledge, it... well, is not managed.
--Flammicidia
Are you releasing the list before the CTask closes down?
edit: eg: m_Mylist.claer();
Incidentally, may I ask why you need an 800 preallocated list?
[edited by - downgraded on January 18, 2004 5:54:23 AM]
edit: eg: m_Mylist.claer();
Incidentally, may I ask why you need an 800 preallocated list?
[edited by - downgraded on January 18, 2004 5:54:23 AM]
I tried that just after my post in the tasks destructor. No luck.
Actually, I don''t need it preallocated. The error happened as the program was running normally, but I simplified it for debugging. When I comment out the resizing or lower the number, it exits normally.
I''m using the array to store moving particles - actually, it probably never gets up to even 500 running normally (when the error still happens).
--Flammicidia
Actually, I don''t need it preallocated. The error happened as the program was running normally, but I simplified it for debugging. When I comment out the resizing or lower the number, it exits normally.
I''m using the array to store moving particles - actually, it probably never gets up to even 500 running normally (when the error still happens).
--Flammicidia
Do you actually have to resize the list?
Can you not just push a new item onto it and free when needed?
Can you not just push a new item onto it and free when needed?
heh - then do you really need to call a resize beforehand? The list will automatically allocate the memory needed for the next item.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement