GC Hell
BlitzMax Forums/BlitzMax Programming/GC Hell
| ||
| Any tips for debugging memory leaks in Max? I have a type I can't seem to free without leaking memory. It references and gets referenced by many other types, so it is very hard to make sure all the references are deleted. |
| ||
| Show me an UML classdiagram and I'll tell you the problem. |
| ||
| Sounds like the OO design would need some rework if you have that many references to it that you can't say if all references are removed. Normally, memory leaks are caused by cyclic structures (rings). for example: a references b, b references c and c references a such a ring will never be freed unless you manually break up at least 1 of those 3 references, because they all keep each other alive. In such a case, you need a destroy method (which you most likely need anyway to remove its reference from the handling list / map) which just null-ifies all references stored on the current object. That way you normally do not have any problem. If you have a ring assigned to the object, just make sure that before you null the reference, that you call the destroy method on your "ring reference" as well. |
| ||
| I don't know of any way to debug Max memory leaks other than elbow grease and time. :-/ |
| ||
| Flameduck what the hell are you talking about? lol |
| ||
| I've had this bug for three months. That's how difficult it is to sort this all out. It would be nice if there was a way to get some feedback from the garbage collector, like give it a variable and find out how many references exist to that variable. |
| ||
| UML Class Diagram. A static visualization of the different interactions between your software classes. It is usually used during software design activities, but just as often reverse engineered from code to help identify poor design choices (like for instance the cyclic references Dreamora is on about). |
| ||
| I think someone just wants to show off how smart they think they are. |
| ||
| You're entitled to your ill-informed opinion. But by all means keep sifting through your code for another three months, rather than solving it straight away. See how much I care. |
| ||
| It would be nice if there was a way to get some feedback from the garbage collector, like give it a variable and find out how many references exist to that variable. I've requested this several times, and didn't get any reply. Feel free to add your voice. There's also a workaround ( which might break at any time ) from Dreamora in there. http://www.blitzbasic.com/Community/posts.php?topic=62724#725019 |
| ||
| Flameduck what the hell are you talking about? lol He's still in school. |
| ||
| @FlameDuck: Good and clear design certainly help, sure. On the other hand I really can't understand how people can seriously think that having cyclic references is a bad design per se. I've been hearing that here and there, and to me that's just pure nonsense. And from the moment you have cyclic references AND a garbage collector that cannot handle them gracefully, you have to be very carefull *at the global level*. That is, ensuring there is no memory leak requires knowledge about the whole application. With a full GC that's not true anymore. If an object is not collected, then it is still reachable. If it is not, it will be collected eventually. And that's it. No need to know the whole graph of references, which makes quite a difference. So there is a real concern about memory leaks handling in BlitzMax. That's life and we just have to live with that, but saying otherwise won't help anyone. Being pedantic won't help either. @Leadwerks : There was a thread on the subject recently. You can get the reference count of an object by getting an integer pointer p (not reference) to your object, and use it to address p[-1] (or maybe [-2] etc, just test it). That's a hack but could certainly help you in your debugging. But to be of any use you'd need to be sure at any time which objects are *supposed* to be freed (but are not). |
| ||
| Why, at least for as long as there's no complete garbage collector, isn't Max tracking allocations and spit out a list of those not referenced after the application was run in debug mode. It's dead simple to implement and pretty effective for tracking most leaks and it ususally doesn't need any noticable resources - and even if it would it wouldn't harm as it should obviously be optional / debug only. Another maybe even better way would be to add user definable callbacks/notification for allocation events (alloc, free, add/remove ref, relocate - if the memory manager supports it) - so it would be even possible to easily create runtime memory monitors, track only relevant events etc. |
| ||
| Any way to use this and parse the output after each allocation in debug mode? It won't tell you how many references to an object but you might see if there's a difference. Might help... might not. |
| ||
| He's still in school. Like Halo, you to are entitled to your ignorant uninformed opinion. Being pedantic won't help either. I'm not being pedantic. I'm trying to help. If Halo doesn't want my help, that's fine too. I really couldn't care less whether he bangs his head against the wall for another 3 months. But tracking down a memoryleak without (at least) some indication of how his program is structured is impossible. |
| ||
| That's true, but tracking it with only your nice UML diagram is close to be as foolish, and I dare to hope you realize it. So all in all your answer doesn't seem to be helpfull in anyway to me. It doesn't even appear to try to. Not that I would care if you just don't want to help him mind you, that's something I can very easily understand. But why not just NOT post? If you seriously want me to think you were offering real help, you'll need to be very convincing. And pay me more than one pint of beer. |
| ||
| Okay, I fixed the problem. It wasn't an old existing bug. I recreated an old bug I hadn't seen in a long time, and I hadn't been using the portal system for a while, so I freaked out and thought it was something else I remembered from a long time ago. Whew! |
   |