Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: What is the funniest bug you encountered?

news.ycombinator.com

Post reply on HN
Print view View original

41–50 of 66 posts

Re: Ask HN: What is the funniest bug you encountered?

#41

Post by AstralStorm »

AnimalMuppet wrote: post #37
tgb wrote: post #26

Earlier quoted context omitted.

Love the bug and it's been a while since I've done anything in C++, but isn't your description slightly wrong? There would be one instance per .cpp file that #include'd Foo.h, not one per getInstance() call. I don't think that "inline by default" is an accurate description of what would happen, and I have to imagine that if inline-ing a function caused different behavior, then that would be considered a compiler bug.…

No, inlining replaces it at the place of call. Every call, even if there's multiple of them in the same file. The idea is that, by putting the implementation in the .h file, you're signaling that you don't want to pay the overhead of the function call. (Same thing with the "inline" keyword.) Now, if your function is sufficiently complicated, the compiler may choose to not inline it anyway (with the definition of "suf…

Now, C++ explicitly allows shouting yourself in the foot for performance reasons and for interesting features. You might actually want to have such code to programmatically create such static fields.

In a template tracking usage of the class is a common case. Another fine one would be to count separate instantiations. (How many times the function was used not inlined vs inlined.) Etc.

Re: Ask HN: What is the funniest bug you encountered?

#42

Post by lj3 »

I once worked on a retail time management game. The doors of your store would open and then close when the customers came in. After a while, the doors would just start swinging open and closed all the time, like the store was being visited by a vengeful ghost. We never did figure out what caused that.

This next bug (in the same game) we purposefully left in and it became an easter egg. A big part of the game was being able to customize your store with different retail stands and tables to put your merchandise on. If you edited your store layout while customers were in the store, you could trap them. The path finding code we wrote for the customers required a valid point of entry and a valid point of exit to the store. As soon as you trapped the customer, the lack of valid path to an exit had an unusual effect on the character animation. The character movement and animation speed would increase up to 2x, which made the customer look like it was freaking out. It also negatively effected the customer "happiness" state. A store's reputation score was based on the average customer happiness level over a particular time period. A trapped customer could absolutely destroy that score. I've seen it drop from 2000+ to 0 in seconds. As with the other bug, we never did figure out why this was happening.

Re: Ask HN: What is the funniest bug you encountered?

#44

Post by FigBug »

AnimalMuppet wrote: post #37
tgb wrote: post #26

Earlier quoted context omitted.

Love the bug and it's been a while since I've done anything in C++, but isn't your description slightly wrong? There would be one instance per .cpp file that #include'd Foo.h, not one per getInstance() call. I don't think that "inline by default" is an accurate description of what would happen, and I have to imagine that if inline-ing a function caused different behavior, then that would be considered a compiler bug.…

No, inlining replaces it at the place of call. Every call, even if there's multiple of them in the same file. The idea is that, by putting the implementation in the .h file, you're signaling that you don't want to pay the overhead of the function call. (Same thing with the "inline" keyword.) Now, if your function is sufficiently complicated, the compiler may choose to not inline it anyway (with the definition of "suf…

> A static local variable in an extern inline function always refers to the same object. > 7.1.2/4 - C++98/C++14 (n3797)

(functions are by default extern, so, unless you specifically mark your function as static, this applies to that function)

What the OP did should be fine and not cause an issues. The only way it could cause issues if they also made the function static.

Re: Ask HN: What is the funniest bug you encountered?

#45

Post by AnimalMuppet »

FigBug wrote: post #44
AnimalMuppet wrote: post #37

Earlier quoted context omitted.

No, inlining replaces it at the place of call. Every call, even if there's multiple of them in the same file. The idea is that, by putting the implementation in the .h file, you're signaling that you don't want to pay the overhead of the function call. (Same thing with the "inline" keyword.) Now, if your function is sufficiently complicated, the compiler may choose to not inline it anyway (with the definition of "suf…

> A static local variable in an extern inline function always refers to the same object. > 7.1.2/4 - C++98/C++14 (n3797) (functions are by default extern, so, unless you specifically mark your function as static, this applies to that function) What the OP did should be fine and not cause an issues. The only way it could cause issues if they also made the function static.

Clarification: Are member functions by default extern?

If so, then it's a compiler bug, and I figured it out because the compiler did what I naively expected, rather than what the standard said.

Re: Ask HN: What is the funniest bug you encountered?

#46

Post by locopati »

While testing Adobe Pagemaker 5.5 for the Power Mac (a version built specifically to take advantage of the new Apple hardware), I discovered a specific set of steps that would overwrite video memory and turn the screen into the kind of static fuzz you'd see in a television tuned to no channel (back when that was possible).

Re: Ask HN: What is the funniest bug you encountered?

#48

Post by AnimalMuppet »

AstralStorm wrote: post #38
AnimalMuppet wrote: post #12

An embedded system written in C++ had a Singleton. The Singleton pattern means that you have one instance, which has to live somewhere. This implementation had the instance as a static variable in the getInstance() method, e.g.: Foo* getInstance() { static Foo; return foo; } This is perfectly valid. Unfortunately, getInstance() was implemented in Foo.h, not in Foo.cpp. But in C++, functions in header files are inline…

Ahh the fabled Multiton pattern. The similar ones are: Making the singletons in shared objects, each one gets it's own. Adding a destroyInstance method.

I've actually used a destroyInstance method, for testing. But if you do that, first, nobody can hang on to the pointer they get from getInstance, ever, anywhere in the entire code base. And second, the instance has to be a pointer (so that destroyInstance can delete it), and destroyInstance has to NULL the pointer. Then getInstance has to create a new instance if the pointer is NULL.

It can be done, but if anybody ever calls destroyInstance in production code, well, I question their approach...

Re: Ask HN: What is the funniest bug you encountered?

#49

Post by dragonwriter »

I once worked tech support in a Fortune 500 enterprise software company where I got a support call that traced back to a syntax error causing a crash in the Perl install script of our flagship product.

Only “funny” because it's a phenomenally expensive product with on paper substantial QA/QC, and yet somehow it got into release with an install script that was guaranteed to fail.

Post reply on HN