• Moogle (unregistered)

    Probabilistic log levels ...

    ... welp, I'm done. This site is done. We're all done. There is no need to submit any further WTFs, there's no coming back from this; we've reached Peak Stupidity. There is nothing more to see or do. Thank you all for participating so actively in The Daily WTF, and good luck to you all.

  • Edd (unregistered)

    Now waiting for Schrödinger's log file

  • Debra (unregistered)

    "mv" could point to "member volatile"... which really does make sense in the context of this entry's WTFery. "We're having problems with stuff" - "Oh just throw some volatile on there, will be fine".

  • eyalnesher (unregistered)

    The only thing more random than the output of LogLess is the thought process of whoever wrote this code.

  • Steve (unregistered) in reply to Moogle

    I can only admire your confidence that we've hit the rock bottom!

  • Steve (unregistered)

    Was the author of the code a logs-half-full or a logs-half-empty sort of person?

  • Jonathan (unregistered)

    While the LogLess here is a clear WTF, it's not totally unprecedented if you've worked with Microsoft's Azure Application Insights.

    Because one pays for the amount recorded in Azure, it by default uses adaptive sampling where if a particular log message is "spamming" the logs, then it only logs a percentage of those. This is not a WTF in my opinion, if you have a fleet of application servers and your database goes offline, the fact the 200,000 log messages became 2000 log messages is probably fine.

    The difference between today's DailyWTF and AppInsights though is the one is done carefully by being per log message, while the other is totally random.

  • Prime Mover (unregistered)

    Hear about the C programmer who had diarrhoea? He applied a probabilistic / stochastic process to his logs to make only 50% of them appear.

  • Beliar (unregistered)

    Do I understand that correctly, if the setting in the cache is not initialized the code

    1. Inserts the setting into the the cache, using the given key.
    2. Sets the entry in the map with the given key to the setting.
    3. Sets the entry in the map with the given key to the setting (again, but with the data field changed).

    ?

  • Brian (unregistered)
    “It’s a simple typo,” Valencia thought. “Anyone could have done that.”

    Ha. Reminds me of one of my favorite stories - I was working on an embedded military device, designed by folks who were mostly familiar with Ada, but this project was going to be done in C. But because this was a safety-critical device, and C makes it so easy to shoot yourself in the foot, the coding standard prohibited many "dangerous" language features, including pointers. Thus, every single function used pass-by-value semantics, no matter whether the parameters were primitives or large structures. And they wondered why they were having so much trouble hitting their performance targets...

    Apparently I, the snot-nosed kid fresh out of college, was the first one to question this policy. Fortunately this led to a softening of the rules from "no pointers, period" to "no dynamic memory allocation", and we got the thing running much faster.

  • Foo AKA Fooo (unregistered) in reply to Beliar

    You do.

    The sad thing is that std::map's operator[] already creates the element if it didn't exist and returns a reference to it. So you only need one map indexing, for checking, creating and updating. If you're not comfortable with that, two accesses are understandable, but the other two are totally redundant.

    But we don't know if he used std::map at all. Maybe he used a mvMap so inserting 3 times increases the chances that the randomized insertion works.

  • Andrew (unregistered)

    Without a doubt, this is the funniest I've seen in a long time. I love it! Though, perhaps this function name over LogLess(): MaybeLog()?

  • Pseudo code improvement (unregistered)

    // always use powers of 2 for storage capacity, it's more efficient maxLogEntries = 65_536

    function adaptativeLogLess ( msg ) { // always check the actual file, some irresponsible guy may change it in our back nbWritten = read(logFile).count("\n")

    if (random(maxLogEntries) > nbWritten) { log(msg) } else { log('Debugging log size issue: ' + msg) } }

  • (nodebb)

    I'm wondering if the probabilistic logging is legal in states/ countries which prohibit gambling.

  • Somebody Somewhere (unregistered) in reply to Brian

    Oh, is it MISRA? I think I remember that early versions of the MISRA standard absolutely forbade pointers in embedded C, which was utterly ridiculous. It was later relaxed to a ban on dynamic memory allocation.

  • Angela Anuszewski (google) in reply to Brian

    This sounds familiar. I had a Java developer literally screaming at me because our customer doesn't allow exceptions without their approval.

  • ooOOooGa (unregistered)

    The probabilistic logging level is certainly the most stupid. But my favorite of the three is the writeCache function. It just shows the incompetence better. Harvey knows enough programming to write valid syntax, but doesn't have the knowledge or skill to actually understand what the code is supposed to be doing.

    I see and write algorithms like that when dealing with database upsert functions in model objects. The function signature gets the data to be set - including a natural key value. The function then has to search by the natural key for existing data. If found, update the entry by primary key. If not found, create a new entry with the data provided.

    But Harvey just copied that type of thinking into a Map object without any thought given into how a database is different than a Map.

  • mushroom farm (unregistered)

    "needless to say"? in my experience, the fact that this code got rewritten at all is TRWTF

  • Your Mammas name (unregistered) in reply to Brian

    "Apparently I, the snot-nosed kid fresh out of college, was the first one to question this policy." - the people still working there remembered what had happened to the others who had previously questioned that policy.

  • (nodebb) in reply to Moogle

    we've reached Peak Stupidity.

    With SSPLL, you log everything, make the random selections in your head, and no code change required.

    (I'll get me coat)

  • (nodebb)

    I could have used a random filter on logging this past week ... in an Elasticsearch cluster, it was filling up 80GB of the root partition with Java exceptions because the programmer had pointed his messages at the wrong index, and the pipeline for the wrong index assumed certain fields would exist. So each of the many hundreds of thousands of messages being cached to Elasticsearch would generate a java exception of at least 2K in the container log.

  • I dunno LOL ¯\(°_o)/¯ (unregistered) in reply to Somebody Somewhere

    I had to deal with some embedded C code written by people who probably just couldn't grok pointers. Array indexes were passed around and subroutines were full of vertical walls of stuff like "globalthing.element[entryNumber].blahblahblah[indexblah1][indexblah2].field_n = foo_n", instead of passing a pointer/reference to "&globalthing.element[entryNumber].blahblahblah[indexblah1][indexblah2]" and having the subroutine just deal with the innermost struct. They apparently had no concept that the subroutine shouldn't need to know about the layout of where and how all the blahs are stored. Remember the DRY principle, folks. The code smell? Probably gym socks.

    And then there was the time where a guy unironically did something incomprehensible using 0[array] because apparently he had never heard of offsetof. It took me a couple of hours to untangle that into something sane.

    It's not that pointers are dangerous, it's the idiots who don't know why they are dangerous and when they aren't that are dangerous.

  • Foo AKA Fooo (unregistered) in reply to Mr. TA

    Violating data retention laws and gambling laws at one, that must be a frist!

  • linepro (unregistered)

    Hopeless()?

  • Kevin Conroy (unregistered)

    ....... harvey ... No!!!!

    We used your logger for the flight controls of the UAV operation!

  • Sole Purpose Of Visit (unregistered)

    Well, there's always the possibility of a circular log. If logging is your thing. Price it out at, say, $10 per MB, and pick your poison.

    Sensible logging used to be a thing, back when disks were ~10MB or so. Choose what you want to log (don't just blat everything at it in all circumstances). Filter that log periodically. (Or use a circular log, see above.)

    What with today's logging "frameworks," all of that good sense appears to have gone the way of the dodo, except that in this case the logging isn't eaten .... simply randomly culled.

    I used to find logs useful. I have to be honest here. For the last couple of decades or so, I've wondered why we bother.

  • Fizzlecist (unregistered) in reply to Andrew

    To be fair it does what it says on the tin

  • grrr (unregistered)

    With everything else here, does it matter that ToString function doesn't work for space characters?

  • Worf (unregistered) in reply to Angela Anuszewski

    So what happened if your app needs to throw an exception? Does it send an email to the boss asking if it can throw a divide by zero exception? What happens if the boss says no? What happens if there's an exception while asking for approval to send an exception? What happens in the meantime - does it stop working until the exception is approved? Exception-inception!

  • Old timer (unregistered) in reply to Brian

    I was working on an embedded military device,

    ..And I work with junior embedded device programmers who assume that passing large structures by reference will be more efficient than passing by value. Which it would be for some compiler, on some architecture, where indirection was less costly than dynamic register allocation.

  • Olivier (unregistered) in reply to Jonathan

    Unix syslog has been reducing the number of logs for ages: if the same message is repeated to often, only the number of repetitions get logged. But if it is different messages, they must be logged individually.

    In today WTF'ery, the randomization is applied to each message, regardless if it is important or not, repeated or not, so it could let through a message about printer out of paper, but remove a message about the database machine getting out of disk space.

    Wow! Simply wow!

  • Irish Girl (unregistered)

    I personally like how the cache entries in a cache map have to have a "cache_" prefix.

  • Álvaro González (github)

    Is it "log less" or "logless"?

  • WTFGuy (unregistered)

    @Irish Girl ref

    I personally like how the cache entries in a cache map have to have a "cache_" prefix.

    I'm going to bet the the global thingy called mvCache actually holds multiple different disjoint sets of entries. So this particular WriteCache() function prepends "cache_" to disambiguate from a different WriteData() function that prepends "file_not_found_" to its keys stored in the same global mvCache object.

    Or at least that's the "future-proofing" thinking that Harvey applied when he created this monstrosity.

    Theory 2: We all like code that gives meaningful descriptive names to variables, classes, & methods. Maybe he just likes giving meaningful descriptive names to map keys. Idgit.

  • Finally (unregistered)

    Dropping random logs is pure genius, finally the code on this site made me say "WTF".

  • (nodebb)

    thanks for info

    Addendum 2023-07-31 09:20: Are you tired of sifting through countless this online casinos with disappointing experiences? Look no further! I've stumbled upon a gem - a top-notch online casino that promises nothing short of excitement and quality gaming. From a vast selection of games to seamless user interface, this casino ticks all the right boxes.

  • ginawyllie (github)
    Comment held for moderation.

Leave a comment on “Put a Dent in Your Logfiles”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article