Shop OBEX P1 Docs P2 Docs Learn Events
Learned a very important lesson — Parallax Forums

Learned a very important lesson

Jack3Jack3 Posts: 55
edited 2014-02-15 23:38 in Propeller 1
In debuggin I use the serial terminal heavily.

I was working debugging a module with a timing function in it, all in a repeat loop. That loop was doing a couple functions to get information, and then use the cog timer to get a time value. Cool, right? Well outside the loop there was a tiny error, ... you know a real head banger, DUH moment when you find it..... During the process of finding it, I put in a couple statements to print values so I could figure out what the heck.

After finding the bug, and not realizing I had placed a new one, I just could not figure out why now my data going thru the loop was corroded/corrupt/incorrect/inconsistent. LOL

When you do prints or any other real function in a timer, you goof up the timer and the values returned are junk. Take out those serial terminal statements and lo an behold the program works the way it was supposed to. I swear it was a cat on the keyboard that put that extra character in.

Have a day

Comments

  • Heater.Heater. Posts: 21,230
    edited 2014-02-13 11:26
    I really cannot follow what you did there but this is a common phenomena.

    Insert some debug statements in your code, or use a debugger, and the problem goes away.

    This is known as a "Heisenbug": "http://en.wikipedia.org/wiki/Heisenbug

    I once suffered from an "Inverse Heisenbug". I was so unsure of what I was doing that from the outset I stepped through it with a debugger. It never worked. After two days of hair pulling I just let it run. BINGO my code worked just fine. Turned out the debugger had a bug trying to follow what I was doing. Oh the joys of getting an Intel processor out of "real mode 16 bit mode" to "protected 32 bit mode".
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2014-02-13 14:48
    This is known as a "Heisenbug": "http://en.wikipedia.org/wiki/Heisenbug
    I swear it was a cat on the keyboard that put that extra character in.

    Schrodinger's cat by any chance?
  • T ChapT Chap Posts: 4,223
    edited 2014-02-13 14:59
    Sometimes the opposite is true. I have had code not work at all, then when putting in debug code, it worked... because of the delay introduced by the debug code.
  • Heater.Heater. Posts: 21,230
    edited 2014-02-13 20:59
    Jack3,
    ...data going thru the loop was corroded...
    
    I have heard of "bit rot" before but never "data corrosion". Love it.

    Sounds like it should be used to describe what happens when your program exposes it's data to it's users :)

    Dr_A,
    Schrodinger's cat by any chance?
    
    Pretty much.

    There is another common cause heisenbugs:

    Your program has a bug where by it is accessing memory that it should not. Perhaps you have an incorrectly set pointer. Or you are accessing an array outside it's bounds. Or you are over flowing the stack.

    The "nice" thing about this kind of bug is that the part of the code with the error might work just fine by some chance. But it causes some other code to fail. Often the other code is something you have just written so you waste hours debugging that because it's new and, well, the older code works right?

    Just to make it interesting when you add debug statements everything works fine. Adding those statements moves code around in memory which changes what happens with the incorrect memory access.
  • SRLMSRLM Posts: 5,045
    edited 2014-02-13 21:22
    T Chap wrote: »
    Sometimes the opposite is true. I have had code not work at all, then when putting in debug code, it worked... because of the delay introduced by the debug code.

    I helped uncover a bug in the PropGCC assembler this way: loops wouldn't work unless there was a printf in there (source). In this case it was because the printf was too big to be optimized into the fcache, so it avoided a specific bug with fcache assembly.
  • photomankcphotomankc Posts: 943
    edited 2014-02-14 07:39
    Heater. wrote: »
    Just to make it interesting when you add debug statements everything works fine. Adding those statements moves code around in memory which changes what happens with the incorrect memory access.

    There have been times when I was ready to beat some device into dust with a hammer over those kinds of errors. I still have run-ins with it now and again but these days I know that certain head-scratchers mean that it's time to go back and start very carefully examining timing and memory access. Doesn't make the issue easier to find but often I clean up a lot of other mistakes in that exercise too.
  • prof_brainoprof_braino Posts: 4,313
    edited 2014-02-15 08:57
    photomankc wrote: »
    ...beat some device into dust with a hammer...

    THATS the spirit! Power programming at its finest!
  • photomankcphotomankc Posts: 943
    edited 2014-02-15 23:38
    THATS the spirit! Power programming at its finest!

    Sometimes things need to be..... disciplined.
Sign In or Register to comment.