Invisible wrote:
> It burns! IT BURNS!! >_<
> 
> I especially like the claims of "every time we added debug code, the bug 
> went away". Surely it is impossible to work under such conditions...

Heisenbugs are always lots of fun. ;)

-- 
~Mike

Post a reply to this message

Invisible schrieb:
> It burns! IT BURNS!! >_<
> 
> I especially like the claims of "every time we added debug code, the bug 
> went away". Surely it is impossible to work under such conditions...

Well, I tell you that's pure reality. Last project I was working on, 
"let's just ship the device with debug output X enabled by default" was 
quite a common suggestion during troubleshooting. We managed to keep it 
a joke though - the customer would not have been amused.

And some issues we did indeed fix using the "if you're falling through a 
hole, don't do it" kind of approach, because the errors occurred so 
infrequently that we just had no chance of ever finding the root cause.


Yeah, it's kind of fun developing software for devices where 
occasionally the only way to get any helpful debug information out of 
the thing is by switching an LED on or off, and errors might just as 
well be hardware-related.

Post a reply to this message

Invisible schrieb:
> It certainly makes me realise that I prefer safe languages over 
> efficient ones any day of the week. :-P

You can get such issues with "safe" languages, too: All you need is some 
race conditions that kick in when performance is particularly good, but 
don't if performance is bogged down a deal by debug output.

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> I especially like the claims of "every time we added debug code, the bug 
> went away". Surely it is impossible to work under such conditions...

  That was a relatively common problem in C and C++ years ago, but nowadays
especially C++ compilers have got much better at debugging such things. For
example Visual C++, when compiling in debug mode, will add bounds checks to
all STL code and IIRC raw array accesses (although there are limits to the
latter, as it's quite difficult to check bounds when pointer arithmetic is
being performed). gcc has a precompiler constant which, when defined, turns
on similar checks to all STL code. Then you can use valgrind to catch the
rest.

  The only situation nowadays where you might end up having such heisenbugs
in C++ which are not caught by the compiler even in debug mode is if you
use dirty raw pointer arithmetic hacks, which is something you seldom really
have to do in clean good-quality code, not even if you aim for maximum
efficiency.

-- 
                                                          - Warp

Post a reply to this message

>> I especially like the claims of "every time we added debug code, the 
>> bug went away". Surely it is impossible to work under such conditions...
> 
> Well, I tell you that's pure reality.

> Yeah, it's kind of fun developing software for devices where 
> occasionally the only way to get any helpful debug information out of 
> the thing is by switching an LED on or off, and errors might just as 
> well be hardware-related.

Wouldn't this make it scientifically impossible to deliver a working 
product?

Post a reply to this message

>> It certainly makes me realise that I prefer safe languages over 
>> efficient ones any day of the week. :-P
> 
> You can get such issues with "safe" languages, too: All you need is some 
> race conditions that kick in when performance is particularly good, but 
> don't if performance is bogged down a deal by debug output.

Safe languages don't permit race conditions in the first place.

Post a reply to this message

Warp wrote:
> Invisible <voi### [at] devnull> wrote:
>> I especially like the claims of "every time we added debug code, the bug 
>> went away". Surely it is impossible to work under such conditions...
> 
>   That was a relatively common problem in C and C++ years ago, but nowadays
> especially C++ compilers have got much better at debugging such things. For
> example Visual C++, when compiling in debug mode, will add bounds checks to
> all STL code and IIRC raw array accesses (although there are limits to the
> latter, as it's quite difficult to check bounds when pointer arithmetic is
> being performed). gcc has a precompiler constant which, when defined, turns
> on similar checks to all STL code. Then you can use valgrind to catch the
> rest.
> 
>   The only situation nowadays where you might end up having such heisenbugs
> in C++ which are not caught by the compiler even in debug mode is if you
> use dirty raw pointer arithmetic hacks, which is something you seldom really
> have to do in clean good-quality code, not even if you aim for maximum
> efficiency.

Maybe you're right, I don't know. I just find it makes me kind of 
nervous working with something which can break just because you changed 
the order of a few statements in a way which, conceptually, shouldn't 
change anything.

(Notice that guy who said he couldn't just add a new integer field to a 
data structure because it would break a few thousand other functions? 
Does that sound like good abstraction you to?)

Still, I guess that's why I'm not a games developer...

I was also puzzled when I looked at Gentoo and discovered just how many 
C programs break horribly just because they were written for IA-32 and 
got recompiled for AMD64.

Post a reply to this message

> (Notice that guy who said he couldn't just add a new integer field to a 
> data structure because it would break a few thousand other functions? Does 
> that sound like good abstraction you to?)
>
> Still, I guess that's why I'm not a games developer...

It's not because it's a game, it's because it's being made for profit. 
Writing any software as a hobby is very different than writing it to try and 
make money.

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> Safe languages don't permit race conditions in the first place.

  And then you wonder why safe languages are so slow.

-- 
                                                          - Warp

Post a reply to this message

scott wrote:
>> (Notice that guy who said he couldn't just add a new integer field to 
>> a data structure because it would break a few thousand other 
>> functions? Does that sound like good abstraction you to?)
>>
>> Still, I guess that's why I'm not a games developer...
> 
> It's not because it's a game, it's because it's being made for profit. 
> Writing any software as a hobby is very different than writing it to try 
> and make money.

 From what I've seen, only games programmers go to the extremes of using 
obscure and elaborate low-level hackery to squeeze every last 
femtosecond of performance out of the machine. Other programmers usually 
don't have such ardent performance limits to worry about. (Usually.)

Which is not to say that all codebases that aren't games are beautifully 
written... just that games typically have ludicrous performance 
requirements and insane release schedules.

Post a reply to this message