• Prime Mover (unregistered)

    If you've got leaky logs like that you really ought to see a doctor about it.

  • my name is missing (unregistered)

    How do people get jobs writing code in such a dumb manner? Also how do people stay hired who fail to understand exactly what their code is doing? Even worse how do people not look at their code to see if it even makes sense.

  • MaxiTB (unregistered)

    Techically this not a memory leak (failing to correctly release alloced memory), just plain fill up memory :-)

  • (nodebb) in reply to MaxiTB

    It's what I call a "logical" leak, where the memory won't be released, as opposed to a "physical" leak, where it can't be released because the program no longer knows where it is. Physical leaks are difficult in GC languages like Java, but they do nothing to prevent logical leaks.

    One clbuttic example of a logical leak is a cache of unbounded size (never a good start) that includes results separated and searched-for by date, where yesterday's entries won't ever be either searched for or purged. If the program runs over multiple days, the cache will just grow and grow.

  • (nodebb)

    For years, Carla's company had a Java application with a memory leak.

    So, are they saying that "For years," nobody questioned that there are no physical log files? Or, is the "solution" to this problem writing the file as part of a clean exit?

  • Nony Mouse (unregistered) in reply to Bananafish

    They probably are getting log file written, because Log4j lets you log to multiple areas. The problem here is that the programmer added a new logging destination here which was a StringWriter so the logs are being written directly into memory as well as to everywhere else the Logger is supposed to be writing them to.

    This has the smell of someone adding some debugging code to see what the log is writing out in the debugger and then not cleaning it up afterwards.

  • Hasseman (unregistered) in reply to my name is missing

    The demand of "programmer" are so high that self "educated" people easily get well paid work (HPC's). Today's low code framework just makes it worse.

  • (nodebb) in reply to Bananafish

    nobody questioned that there are no physical log files?

    Who says there were no physical log files? Adding a log appender doesn't remove the ones that are already there.

  • (nodebb) in reply to Nony Mouse

    This has the smell of someone adding some debugging code to see what the log is writing out in the debugger and then not cleaning it up afterwards.

    That's probably it. Writing loads of debug logs to files on disk can have a performance penalty so writing them to memory and then flushing them to disk afterwards might help.

  • (nodebb) in reply to MaxiTB

    Most certainly a poor design with unbounded (until failure) memory consumption ... Not not a leak in any way shape or form....(not even a "logical one").

  • (nodebb) in reply to Jeremy Pereira

    I just presumed this was the only logging. I mean, the name of this site does end with WTF!

    Addendum 2022-02-10 12:17:

    Carla was assigned a task to go track down some of those untrackable issues. The first thing she discovered was that when she changed the logging level from its production settings to "DEBUG" mode, the application crashed in minutes instead of days. That piece of information sent Carla looking at the logging code to see what was happening.

    OKOKOKOKOKOKOKOK -- this does imply that there are physical logs and that Carla was trying to get them to dump more info. Surprised at myself for making that jump.

  • (nodebb) in reply to Nony Mouse

    This has the smell of someone adding some debugging code to see what the log is writing out in the debugger and then not cleaning it up afterwards.

    Could be, sure. But I wouldn't do that so it's not the first place I went to.

  • Marsupilami (unregistered)

    You can tell they really knew what they were doing, invoking WriterAppender.activateOptions() which, as the Javadoc states, "Does nothing."

  • Airdrik (unregistered) in reply to Marsupilami

    Which actually suggests they may have had some idea what they were doing while reinforcing that the state of the code was for debugging and was accidentally checked in without realizing it. The activateOptions() does do things when called on some Appender classes; so maybe they'd set it up with a file appender originally, then they switched to the string appender while debugging and didn't bother to remove that call (along with the rest of the garbage they didn't clean up)

  • Erk (unregistered)

    Well, I have three things to say:

    1. If you want buffered output... use BufferedWriters or BufferedOutputStreams
    2. Congratulations on making a GC-ing language "leak" memory
    3. Visual VM!
  • (nodebb) in reply to TheCPUWizard

    Not not a leak in any way shape or form....(not even a "logical one").

    Given that nobody knew it was there, I'd say that it meets the definition of a logical leak, one the program won't clean up (but by implication serves no purpose).

    Maybe it served a purpose once (the debugging thing sounds like a good guess), but since everyone who ever knew either left or forgot, that purpose doesn't really count any more. Even in the debugging case, making the thing have unbounded size isn't a good idea. At least impose an upper bound on how big the appended-to string is allowed to get.

  • SG (unregistered) in reply to Steve_The_Cynic

    Call it an illogical leak.

  • (nodebb) in reply to SG

    That works, too.

  • I dunno LOL ¯\(°_o)/¯ (unregistered) in reply to my name is missing

    Because the people who hire them are clueless.

    Because the people who manage them are clueless.

    Because clueless people don't do code reviews, and if they did, they would stop because it would reveal how clueless they are.

  • Airdrik (unregistered) in reply to SG

    I think 'logical leak' works: The logic (as illogical as it may seem) shows that a permanent, live reference consumes an ever-increasing, unbounded amount of memory that is never released. Worth categorizing with physical leaks as a memory leak (of unknown/surprising origin) due to the symptom of consuming an ever-increasing amount of memory that is never released (as opposed to normal/expected memory consumption due to the amount of data that needs to be processed or maintained in memory as part of normal or even abnormal operation) (i.e. would someone who is generally familiar with the app be able to attribute the increase in memory to an expected behavior or not).

  • (nodebb) in reply to I dunno LOL ¯\(°_o)/¯

    Because clueless people don't do code reviews, and if they did, they would stop because it would reveal how clueless they are.

    Not necessary. I recently tracked down an issue that was caused by code along the lines of

    int compoundAction(handle_type handle, /* ... */) {
    int errorCode;
    // ...
    errorCode = firstAction(handle, /* ... */);
    errorCode = secondAction(handle, /* ... */);
    errorCode = thirdAction(handle, /* ... */);
    return errorCode;
}

    Some function that was not the last returned a non-zero error code. As a consequence the handle was left in an inconsistent state, but the function return an error code, that said "this is fine". As a result, in another part of the code a really cryptic error message was emitted. Sometimes.

    The code had passed through code review formally. So, obviously, nobody really took a closer look, because, yes, the issue was as obvious as in the anonymized example.

  • nunya business (unregistered) in reply to Steve_The_Cynic

    Physical leaks are difficult in GC languages like Java

    On the contrary, they're the norm! A GC doesn't eliminate memory leaks; it turns every no-longer-used allocation into one. That's basically the only way a generational GC can work at all: leak as much memory as possible for as long as possible, then clean it up once the mess becomes too big to ignore any longer.

  • (nodebb) in reply to nunya business

    I say thay physical leaks are difficult because the garbage collector is part of your program, even if you don't write it yourself, and it will clean the stuff up. That displaces things into a sort of "secondary" logical leak, where the GC accumulates stuff, but at least it does have a condition for cleaning things up.

  • nasch (unregistered) in reply to Steve_The_Cynic

    I don't think a physical memory leak is even possible in Java.

  • (nodebb) in reply to nasch

    That's why I described it as "difficult". You might encounter a bug in the GC, I suppose, but outside of that, I agree, physical leaks don't sound possible. It might be possible, because of a missing call to a "close your state" function, and the same lack in the last-ditch finalize() thing, to leak some other resource, but not the object's memory.

  • Gumpy Gus (unregistered) in reply to MaxiTB

    So the code eventually would crash and nobody ever thought of looking at the crash info or periodically doing a "ps" or starting up a memory grapher? Sheesh.

  • Foo (unregistered)

    Well, it's a static initializer, so it shouldn't be even called more than once. Except you're some weird class-unloading-reloading going on. The only wtf is doing something out of bounds of the class (accessing the Root-Logger from the Application). Atleast without seeing the rest of it.

  • Foo (unregistered)

    woops, missread something, it's really using a in-memory buffer to store the whole log. Ok ok. That's just... unfathomable, sorry.

  • (nodebb) in reply to I dunno LOL ¯\(°_o)/¯

    Because the people who hire them are clueless. Because the people who manage them are clueless. Because clueless people don't do code reviews, and if they did, they would stop because it would reveal how clueless they are.

    If they are smart enough to estimate the depth of their cluelessness, they will feel intimidated by "the nail that sticks up" and go on a campaign to ensure the office competence stays within about a standard deviation of their incompetence.

  • xtrenlabs (unregistered)
    Comment held for moderation.
  • Xav_ (unregistered) in reply to Nony Mouse
    Comment held for moderation.
  • David Mårtensson (unregistered) in reply to my name is missing

    People stay hired because most higher ups really do not understand the work being done and therefore cannot really verify the quality and secondly, at least in large parts of the world, there is not really an abundance of good developers.

    In Sweden they currently estimate that there is lacking around 40 000 developer now and its growing.

    And sometimes even a bad dev can be better than no dev.

    A program you need to restart every night, if it still does the work during the day, it still does the work.

    Many bank systems still needs a reset every week just because no one have managed to really identify which combination of the 10 000 different cobol programs they depend on that are actually aggregating crap and cause problems when a new week starts up unless everything is reset to some known state.

    Other examples, World of Warcraft used to restart the servers every Wednesday even if there was no patch, later they had solved it. Another game I currently play a lot recommends restart of the server every 6 hours to keep it stable.

  • Kini (unregistered)

    So it could be said the nightly reboot was for log rotation purposes :)

Leave a comment on “Leaky Logs”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article