Home AMX User Forum Duet/Cafe Duet

Duet Memory Leak

Anybody have any tips on finding a memory leak in Duet? Talked to Tech Support and there does not seem to be any way to do a heap dump to try and figure out what objects are orphaned and not getting collected.

Comments

  • a_riot42a_riot42 Posts: 1,624
    JasonS wrote: »
    Anybody have any tips on finding a memory leak in Duet? Talked to Tech Support and there does not seem to be any way to do a heap dump to try and figure out what objects are orphaned and not getting collected.

    Are you try/catching all possible null pointer exceptions? People seem to think they aren't of much consequence but if they add up they can leak memory to trace them. I entered into a Java project where there was a method that built a interface from an XML file, and the text position attribute was wrong the whole way through the XML file, instead of 'center' it was 'middle' or vice versa so every time that attribute was accessed a null pointer exception occurred. They weren't catching the error, as the compiler doesn't enforce it, so they were never seen. Once that error was cleared up all sorts of problems went away including memory leaks. Java's stack trace system uses a lot of resources on its own. Just a thought, YMMV.
    Paul
  • JasonSJasonS Posts: 229
    Thank you for the tip! This is my first duet project so I am a little paranoid about null pointer exceptions. I have noticed some strange behavior where it seems like sometimes they dont show up in telnet depending on the surrounding code. In particular if you have a try catch block that catches a specific exception, the null pointer exception doesn't seem to show 100% of the time. I don't know how bad a practice it is but unless that special case exception is used for a specific reason I have replaced it with a blank catch (Exception). I am really uncomfortable with how easy it seems to be to "lock up" the JVM with these unhandled exceptions.

    I think alot of my issue has been not removing listeners from OBjects before releasing them. I am also spawning and killing 10 Threads at a time to handle ip connections as I iterate thru a database of 200 sites. Kim Burgess's AMX Performance Monitor program has been invaluable in monitoring my Duet memory usage in real time. The two attachments show my before and after utput from AMX Performance Monitor so far. I am still not 100% comfortable with my programs behavior, I think that the garbage collector works in very mysterious ways.
  • a_riot42a_riot42 Posts: 1,624
    JasonS wrote: »
    I have replaced it with a blank catch (Exception).

    This is considered bad form, so I'd suggest not doing it if it can be avoided, and it usually can. Its the equivalent of black tape over the engine light, and if you ignore exceptions and then get a lot of them, things can slow to a crawl and you won't have a clue why. Why torture your future self in this manner when it can be avoided? I typically check for all error states that I can preemptively and than catch any that I can't and do the correct thing. Sometimes there is nothing to be done so just an empty clause and a comment is appropriate, but I try to avoid that as much as possible especially in RTOS, and CPU intensive programs since Java's error checking is such a resource hog.
    Paul
  • JasonSJasonS Posts: 229
    I meant to say "blanket" catch as opposed to the specific Exception I would expect from the statements in the try block. I am still not cmfortable with how everything works in Duet yet, so I'm a little paranoid about "locking up" the JVM. It seems to happen frequently while I am debugging, don't want it to happen in the field.

    I try to catch any null pointer exceptions with "if ( != null)" before I use an Object. At this point in my experience level I would perfer slow operation to none. Hopefully I can improve that as I gain more experience. I am still not completely sure which of the modifications I made improved my Duet memory usage. I am still testing it, so I may break it yet! Thank you for your great pointers!
  • PhreaKPhreaK Posts: 966
    JasonS wrote: »
    I meant to say "blanket" catch
    A.k.a. pokemon exception handling - gotta catch 'em all :)
  • tomktomk Posts: 24
    If you'll forgive me bumping an old thread, I'd like to check this particular point:
    JasonS wrote: »
    Anybody have any tips on finding a memory leak in Duet? Talked to Tech Support and there does not seem to be any way to do a heap dump

    Can anyone confirm that this is true? I'm debugging a sticky issue with long-term crashes at the moment and would love to get some heap dumps, even if it's fiddly to do.
Sign In or Register to comment.