How well do you know your bugs?

bohrbug: a good, solid, bug.  named for the Bohr model of atomic structure.
bohrbugs do not change their behavior and are relatively easily detected.

hindenbug: a bug with catastrophic behavior.

heisenbug: a software bug that seems to disappear when one attempts to study it.


programmer notices that the code should never have worked in the first place.

mandelbug: a bug whose causes are so complex as to defy remediation, or one
which demonstrates seemingly chaotic or even non-deterministic behavior.


I hope you find these as amusing as I did.

Regards,
A.D.B.

Post a reply to this message

> How well do you know your bugs?
>
> bohrbug: a good, solid, bug.  named for the Bohr model of atomic structure.
> bohrbugs do not change their behavior and are relatively easily detected.
>
> hindenbug: a bug with catastrophic behavior.
>
> heisenbug: a software bug that seems to disappear when one attempts to study it.
>

> programmer notices that the code should never have worked in the first place.
>
> mandelbug: a bug whose causes are so complex as to defy remediation, or one
> which demonstrates seemingly chaotic or even non-deterministic behavior.
>
>
> I hope you find these as amusing as I did.
>
> Regards,
> A.D.B.
>
I might steal a few of those.

-- 
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/*    flabreque    */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/*        @        */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/*   gmail.com     */}camera{orthographic location<6,1.25,-6>look_at a }

Post a reply to this message

On 23/07/2014 07:14 AM, Anthony D. Baye wrote:
> I hope you find these as amusing as I did.

I see somebody's been reading the hacker jargon file, then...

We had a catastrophic heisenbug the other week. When you run the 
application, if you click on one of the settings on the configuration 
page, it actually *runs* the action being configured, rather than just 
changing the setting. Utterly mystified as to how such a bizarre thing 
could even be remotely possible, we waded through the code. No hint of 
what might cause such a thing. So we ran a debug build of the program... 
and the bug vanished.

Much poking, and it turns out that if you run the version of the 
software produced by the automated build system, the bug is completely 
repeatable. If you build the software (in debug or release mode) 
yourself, it works perfectly. What the actual hell??

When we actually found the root cause, it was truly horrifying. It seems 
that the automated code obfuscation system we run our code through is 
BREAKING OUR CODE!!! O_O The "solution" was to turn off code obfuscation 
in certain parts of the program. I say "solution" since this obviously 
isn't a solution at all; the fact that this event occurred at all proves 
that the obfuscater is defective, and that another bug like this could 
occur AT ANY MOMENT. It's also provably impossible to test for, since 
the obfuscater is also rewriting our tests, and it might rewrite the 
test case correctly but the production code incorrectly. So... yeah, 
pretty worrying, actually.

Also: Technically it's not a bug unless it's in Hemiptera.

Post a reply to this message

Am 23.07.2014 22:30, schrieb Orchid Win7 v1:

> When we actually found the root cause, it was truly horrifying. It seems
> that the automated code obfuscation system we run our code through is
> BREAKING OUR CODE!!!

OUCH!

> Also: Technically it's not a bug unless it's in Hemiptera.

... unless it's a dog.

Post a reply to this message

Orchid Win7 v1 <voi### [at] devnull> wrote:
> automated code obfuscation system we run our code through

I think this is the real WTF.

-- 
                                                          - Warp

Post a reply to this message

Am 24.07.2014 07:06, schrieb Warp:
> Orchid Win7 v1 <voi### [at] devnull> wrote:
>> automated code obfuscation system we run our code through
>
> I think this is the real WTF.

I guess you don't want to obfuscate a large codebase manually. Not only 
because it is a lot of work, but also because there is a high risk of 
breaking the code...

... oh, wait...

Post a reply to this message

On 24/07/2014 06:06 AM, Warp wrote:
> Orchid Win7 v1<voi### [at] devnull>  wrote:
>> automated code obfuscation system we run our code through
>
> I think this is the real WTF.

The idea is to make it less trivial to reverse-engineer our code and 
steal all our secrets.

...which is interesting, really. We make software for idiots. Idiots 
generally aren't the type of people you'd expect to be 
reverse-engineering computer software. Our software doesn't *do* 
anything particularly complicated; it just puts a user-friendly GUI in 
front of a bunch of existing tools. That might *sound* easy, but it's 
actually surprisingly time-consuming.

Really, if you want to copy our product, it would be quicker to look at 
what it does and write your own one from scratch than to try to figure 
out how ours works internally. The most likely scenario is somebody 
wanting to reverse-engineer our stuff just to disable the license checks.

All the obfuscater actually does is to take every class and rename all 
it's methods to A(), B(), C(), etc. And insert lots of complicated flow 
control into the method's actual code. It appears in this instance, it 
accidentally (!!) renamed two events to the same thing. Oops...

Post a reply to this message

On 24/07/2014 08:02 AM, clipka wrote:
> I guess you don't want to obfuscate a large codebase manually. Not only
> because it is a lot of work, but also because there is a high risk of
> breaking the code...
>
> ... oh, wait...

BOOM!

Post a reply to this message

Am 24.07.2014 09:07, schrieb Orchid Win7 v1:
> On 24/07/2014 06:06 AM, Warp wrote:
>> Orchid Win7 v1<voi### [at] devnull>  wrote:
>>> automated code obfuscation system we run our code through
>>
>> I think this is the real WTF.
>
> The idea is to make it less trivial to reverse-engineer our code and
> steal all our secrets.
...
> Really, if you want to copy our product, it would be quicker to look at
> what it does and write your own one from scratch than to try to figure
> out how ours works internally. The most likely scenario is somebody
> wanting to reverse-engineer our stuff just to disable the license checks.

That, most probably.

> All the obfuscater actually does is to take every class and rename all
> it's methods to A(), B(), C(), etc. And insert lots of complicated flow
> control into the method's actual code. It appears in this instance, it
> accidentally (!!) renamed two events to the same thing. Oops...

I guess it's plenty of fun to wade through obfuscated code to figure out 
exactly how the hell the 'fuscator fucked it up...

Post a reply to this message

On 24/07/2014 09:07, Orchid Win7 v1 wrote:
> On 24/07/2014 06:06 AM, Warp wrote:
>> Orchid Win7 v1<voi### [at] devnull>  wrote:
>>> automated code obfuscation system we run our code through
>>
>> I think this is the real WTF.
> 
> The idea is to make it less trivial to reverse-engineer our code and
> steal all our secrets.
> 

So, you are on the poor-side of companies. Richer companies have a
full-time team with lawyers to track and sue such events.


> ...which is interesting, really. We make software for idiots. Idiots
> generally aren't the type of people you'd expect to be
> reverse-engineering computer software. Our software doesn't *do*
> anything particularly complicated; it just puts a user-friendly GUI in
> front of a bunch of existing tools. That might *sound* easy, but it's
> actually surprisingly time-consuming.
> 
> Really, if you want to copy our product, it would be quicker to look at
> what it does and write your own one from scratch than to try to figure
> out how ours works internally. The most likely scenario is somebody
> wanting to reverse-engineer our stuff just to disable the license checks.
> 
> All the obfuscater actually does is to take every class and rename all
> it's methods to A(), B(), C(), etc. And insert lots of complicated flow
> control into the method's actual code. It appears in this instance, it
> accidentally (!!) renamed two events to the same thing. Oops...

Maybe interpreted language is not the right choice if you want to
protect your code. That's where compiled language have an advantage: the
compilation with full optimisation is already an obfuscation. There is
decompiler... like there is deobfuscater. And they are pretty smart on
small code.

It's one of the three Java issues (Java is about sharing... keeping
secret is not sharing, so the choice of the language for your project
was an error), at least for secretive software. But that's another story.

-- 
IQ of crossposters with FU: 100 / (number of groups)
IQ of crossposters without FU: 100 / (1 + number of groups)
IQ of multiposters: 100 / ( (number of groups) * (number of groups))

Post a reply to this message