| View previous topic :: View next topic |
| Author |
Message |
mweber1488
Joined: 10 Jun 2008
Posts: 15
|
 Posted: Tue Jun 10, 2008 5:28 pm Post subject: Library unloading priorities |
 |
|
A while back (around revision 280, not sure which off hand) I incorporated derelictIl into my program and it worked great. Then I had stop working on my project to focus on some other pressing needs. I just got back into the project again and updated my derelict sources to revision 304. Upon testing my program, I kept getting a very pesky access violation error. After hunting it down with the help of ddbg, I figured out that the class that handled the derelictIl stuff went out of scope when the gc decided to get rid of it, which was after the library had unloaded and thus caused an access violation when I tried to use ilDeleteImages.
The quick answer is to delete the object once I no longer need it but that doesn't solve the problem completely because if an exception occurs then the delete doesn't get called and we get the same problem as before. To solve that, I have wrapped the ilDeleteImages call with a check to make sure the library is still loaded before being called. While this does work, it leaves me wondering whether or it causes a memory leak or if there is a better way. And scope guarding doesn't seem to solve the exception problem either. |
|
| Back to top |
|
 |
aldacron
Joined: 05 May 2004
Posts: 1322
Location: Seoul, South Korea
|
| Posted: Tue Jun 10, 2008 6:57 pm Post subject: Re: Library unloading priorities |
|
|
| mweber1488 wrote: | | After hunting it down with the help of ddbg, I figured out that the class that handled the derelictIl stuff went out of scope when the gc decided to get rid of it, which was after the library had unloaded and thus caused an access violation when I tried to use ilDeleteImages. |
I'm inferring here that you are calling ilDeleteImages in a class destructor. If that's the case, the simple answer is - don't. There's no guarantee in D that a destructor will ever be run. From the D docs:
| Quote: | | The garbage collector is not guaranteed to run the destructor for all unreferenced objects. Furthermore, the order in which the garbage collector calls destructors for unreferenced objects is not specified. |
Your destructor is getting called during the final GC cleanup, after the module destructors have already run. That's one of the perils of using class destructors in concert with module destructors. Personally, I think the GC cleanup should be run once before the module destructors are called and once after, but no much I can do about it.
| Quote: | | The quick answer is to delete the object once I no longer need it but that doesn't solve the problem completely because if an exception occurs then the delete doesn't get called and we get the same problem as before. To solve that, I have wrapped the ilDeleteImages call with a check to make sure the library is still loaded before being called. While this does work, it leaves me wondering whether or it causes a memory leak or if there is a better way. |
I don't see that there would be a problem with memory leaks. The OS will clean up any memory and system resources used automatically when the app exits. Memory leaks only occur over the lifetime of a program, not after its execution. There are some rare corner cases where system resources could continue to be tied up after exit, but this shouldn't be one of them.
However, in a long running program if any of your objects wind up not having its destructor called by the GC , the resources will never be freed until the app exits and the OS takes care of it. Your concern about leaking memory on exit isn't really an issue. You should be more worried about what happens during execution.
If you are manually deleting your objects when they are no longer needed, then destructors aren't going to be an issue. But you need to be consistent. And any class that contains member classes should delete those instances in its own constructor.
As for cleaning up on exit, I've never liked leaving it for the OS. It may not be necessary, but it has always felt cleaner to handle it myself. In my D programs, I usually have a try-catch-finally (or a scope(exit) if I'm not logging exceptions) in main that calls a cleanup method. This makes sure resources are released before any module descontructors are called and avoids the conflict you are seeing.
_________________
The One With D | The One With Aldacron | D Bits |
|
| Back to top |
|
|
mweber1488
Joined: 10 Jun 2008
Posts: 15
|
| Posted: Wed Jun 11, 2008 9:18 am Post subject: Re: Library unloading priorities |
|
|
| The funny thing is the I generally manually delete all of my objects but this one some how wasn't. But I figured it would ask and get the right answer as to what is going on rather then assume I was right. The thing that annoys me though, is that even though I have delete in the finally block of the try-catch-finally, when the stack unwinds after an exception is thrown, derelict still seems to unload first. |
|
| Back to top |
|
|
aldacron
Joined: 05 May 2004
Posts: 1322
Location: Seoul, South Korea
|
| Posted: Wed Jun 11, 2008 7:31 pm Post subject: Re: Library unloading priorities |
|
|
| mweber1488 wrote: | | The thing that annoys me though, is that even though I have delete in the finally block of the try-catch-finally, when the stack unwinds after an exception is thrown, derelict still seems to unload first. |
Are you sure that's where the problem is occurring? I just can't imagine a case where a module destructor would be called while the program is still running. That's the only way valid Derelict function pointers would become invalid without explicitly nulling them. This problem surfaces after the application's main function has exited and the GC clean up routine is executed.
So if you can verify that the error is happening before main exits, then there must be a different cause. Otherwise, there's an object instance somewhere whose destructor is not being called until the GC clean up phase.
_________________
The One With D | The One With Aldacron | D Bits |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
