- Feature Articles
- CodeSOD
- Error'd
- Forums
-
Other Articles
- Random Article
- Other Series
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
If you've got leaky logs like that you really ought to see a doctor about it.
Admin
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.
Admin
Techically this not a memory leak (failing to correctly release alloced memory), just plain fill up memory :-)
Admin
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.
Admin
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?
Admin
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.
Admin
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.
Admin
Who says there were no physical log files? Adding a log appender doesn't remove the ones that are already there.
Admin
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.
Admin
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").
Admin
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:
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.
Admin
Could be, sure. But I wouldn't do that so it's not the first place I went to.
Admin
You can tell they really knew what they were doing, invoking WriterAppender.activateOptions() which, as the Javadoc states, "Does nothing."
Admin
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)
Admin
Well, I have three things to say:
Admin
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.
Admin
Call it an illogical leak.
Admin
That works, too.
Admin
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.
Admin
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).
Admin
Not necessary. I recently tracked down an issue that was caused by code along the lines of
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.
Admin
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.
Admin
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.
Admin
I don't think a physical memory leak is even possible in Java.
Admin
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.
Admin
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.
Admin
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.
Admin
woops, missread something, it's really using a in-memory buffer to store the whole log. Ok ok. That's just... unfathomable, sorry.
Admin
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.
Admin
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.
Admin
So it could be said the nightly reboot was for log rotation purposes :)