- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- 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
ten thousand and frist
Admin
comment index out of bounds
Admin
nice WTF. if it wasn't a protected memory runtime, it even has the potential to completely brick the device by overwriting OS critical systems. I've destroyed at least one machine that way, in the dim past :)
Admin
The code, as presented, will never execute at all if no END record is found. Perhaps "==" on the second line should be "!=".
The code, as presented, will copy to one fixed memory location, 'memoryPtr'. That variable is never changed.
The code, as presented, will copy repeatedly from one fixed location 'recordPtr'. That variable is never changed.
Admin
When I reread it, the article was updated so that the loop makes sense ;) We don't know what memory_ptr points to, but if it was at all based on what was copied from other headers, it could still go all over the place.
Admin
Well, sort of. You're presuming that "END" means "the last record." But, yes, the dereferenced things claiming to be pointers-to-pointers are probably just pointers.
Seems to me that the basic color of the fishiness presented here is red, and that it's distinctly herringy. The only crashes we are told of (although there is an implication that there are other causes) appear as segfaults when the loop exits on the 10,001st iteration. This would imply that (a) nothing terminal has happened in the previous 10,000 iterations and (b) whatever calls this code doesn't handle an exit of zero very well.
There's basically nowhere near enough information presented here to shed any real light on what's going wrong. All we can say for certain is that (a) it's nothing to do with C++, because the code presented is vanilla C and (b) the messaging format (stupid though it very likely is) is remarkably resilient, if it can withstand 10,000 iterations and still not crash. I'm guessing that there's a circular reference somewhere in there, but really, who knows?
Admin
Given the title, I was thinking to regular expressions...
Admin
header->recordType held for moderation.
Admin
They pondered "the mystery for some time" before deciding to search the codebase? Seems like that would have been one of the obvious first things to do.
Admin
After cutting through all the branding, it turns out they're running everything on a $200 pico cluster, flashed with code originally built to run model trains and legos.
Admin
They pondered before searching for 10000. For a log message saying 10001, that's not an immediately obvious insight.
Admin
I'd be interested to understand why that line was only sometimes written to the log.
Admin
Simple fix! Just make sure the file never gets corrupted! Actually changing the code is way too risky and would involve QA needing to retest. Better not to change, just layer on another layer of Hack.
Admin
With all the random memory corruption, it's likely that the log function itself sometimes got clobbered.
Admin
Gah! I wish I could unknow this code!
Admin
Ok, what I want to know is, what error message do you put into the log? Run for the hills? Bow to your new overlords? The world is coming to an end?
Admin
somehow this made me think of a scene in the movie "the Andromeda strain": when the computer overloaded from too much information coming in too fast it gave a "601" error message.
Admin
Actually, given the only real fact that we know about this problem -- it apparently shows up as a mysterious log of the number "10001" -- it is incredibly unlikely that the log function itself got clobbered.
Try again.
Admin
It doesn't even need a memcopy. It should just cast the location to a record pointer and access it that way. Why doesn't it just start at the end and copy backwards?
Admin
Karl, funnily enough anything base 10 + 1 is a convention of a limit being hit. It is standard to look for the number of items within your limit plus one to provide a hint of if the limit has been exceeded.
Admin
The only part of this program that really surprises me is this statement:
I'm surprised the compiler would let the programmer get away with this.
Admin
I hate to get all Hindley-Milner on you, but in the absence of other ML information, I think it's reasonable to assume that recordPtr is, for no particularly sensible reason, a pointer to a pointer (presumably to char). There's no particular reason why you shouldn't advance a pointer to char by "recordSize", is there? And likewise, there's no particular reason why you shouldn't advance a dereferenced char** in the same way.,
Here's a hint. The compiler lets the programmer get away with this because the code is legitimate. Given, of course, a reasonable assumption for the types involved. Now, if "recordPtr" is, in fact, a moveable reference to a long int, otherwise represented as long long &&, then, hey! You have a point here. After all, it's C++[/b} we're talking about, innit?
Or maybe we're not. In fact, definitely, we're not. I'm sorry, but the real WTF here is the article itself. The diagnosis is stupid, the solution is stupid, and why on earth anybody should think that [b]checksums are relevant to the solution is so incredibly stupid that I wonder why the idea was even floated amongst the team that "solved" the "problem," let alone Ellis and friends who mangled it into a totally incomprehensible WTF article.
Pointers sure are difficult, aren't they? Joel was right.
Admin
The compiler assumes you know what you are doing. True unmanaged languages are like that.
All you have to do is write the code correctly to start out with!
Admin
this reminds me of a story: a bug in a new version of software used by the telephone company made servers crash the second time they received a "recovered from a crash" message from another server...causing cascading failures all over the country! no calls were dropped, but it took a long time for calls to go through. the bug was a faulty "return" statement that ended the wrong loop...but the Government didn't understand the explanation, ASSUMED is was hackers, and formed a special task force...read "the hacker crackdown" for the full story.
Admin
Key word there is "sometimes". Sometimes the message is logged; sometimes it isn't. Thus, I was offering a possible explanation for that apparent difference, in response to a previous post. Seems that in your rush to be snarky, your reading comprehension suffered a bit.
Of course, if I knew the proper markup for quoting other posts, my meaning would have perhaps been more obvious. But then, it seems rather appropriate for a site called Daily WTF to be lacking documentation of its interfaces...
Admin
Sorry, but you're still just firing random guesses into the ionosphere. Yes, I can read, and yes, I can comprehend what I read. And yes, I too read the bit where there are apparently cases where a "mysterious" crash occurs, but the log message does not appear.
This means nothing. We are not given any indication of what went wrong in the other cases. It is not even a given that the other cases even touch the code in question.
Assuming that the code, as presented, is trashing something in the logging function -- when it is clearly robust enough to iterate through 10,000+ cycles in a significant number of cases -- is pretty much worse than guesswork.
Still, I think you, me, and several earlier commenters can all agree on one thing: in the only failure cases here identified, the code logs "10001" and immediately exits with a zero. Once it does this, the pointer shenanigans are mostly irrelevant (although not entirely, because there's an absent side-effect on the last iteration. The various pointers will be out-by-one-adjustment, because the other half of the loop did not occur).
The only interesting question in this WTF is, what happens when the function as described returns a zero? And, regrettably, we are not told.
Admin
It doesn't work as intended. Line:
Should be (assuming sizeof *recordPtr is 1):
Admin
Probably *recordPtr += ... was in original code without asterisk: recordPtr += ... And also, one should add HEADER_SIZE (assuming sizeof *recordPtr is 1)
Admin
The real problem here isn't the file format, it's the fact that it doesn't keep track of how much data was read from the file and check the pointer against that, and instead relies on an arbitrary record limit. Even if the file format is changed, that still needs to be fixed.
Admin
Actually, if you haven't figured this out yet (and don't take my word for it, read the comments from others above):
The real problem here is that this is over-anonymized crap.
There may indeed be many things wrong with this code. But it was (originally) misrepresented, and I think it's still misrepresented. And even assuming that it is 100% correctly represented, pretty much all of the "conclusions" are utter garbage.
Oh well. meta-WTFs are all the rage these days.