13

In this post here I was asking for guidance about this other post here

The problem drug out across Friday and the entire weekend.

Throughout it all, the central question remained: What was causing the infinitely recursive interrupts ?

As of right now, that is now resolved. I counted six contributing factors that were in some way associated with the errant behavior. I was able to narrow that list down to three.

Fixing two of those three stopped the immediate error in question.

The third factor has now shown itself to be a problem of its own right; and here's the thing that really hits home about the difficulty of avoiding chameleon questions: In order to get to the root of the first problem (infinitely recursive ints) you would have had to recognize...

  • That the disappearing received UART bytes were a separate and distinct contributing factor which had to be allowed to continue to malfunction in order to resolve the infinitely recursive interrupts.
  • That the error send routine was hung in an infinite loop (which you couldn't see because of the recursive ints)
  • That the error routine which was going into its own infinite loop was being called bogusly
  • That that bogus error call was the result of the first problem of recursive ints
  • That the UART was wrongly configured for sending in the first place (RTS/CTS thing)
  • That while this was also an infinite loop, it was not causing the first problem
  • That the infinitely recursive ints had to be corrected before you could ever truly see the infinite wait loop on the wrongly configured UART hardware bits

That's beyond the thinking capacity of most individuals I know; including myself in this instance.

Incidentally, this matter was mostly resolved on the vendor's website forums thanks to some amazingly helpful experts with brains far and beyond my own; and so, I ask...

The Question

Is this the kind of stuff that is just plain off limits for Stack Overflow in the first place ? If not, how do you avoid being a chameleon when a suggested fix produces another bug, then another and another ? (In this particular case, six times over)

Lesson Learned: Debug your own code, not others'.

  • 2
    You can't really. Just ride it out, and say you can't when you can't. – Linuxios Feb 26 '13 at 3:30
  • 9
    +1 for recognizing a potentially troublesome issue and asking how to fix it! – Andrew Barber Feb 26 '13 at 3:33
  • 1
    This might indicate the question is Too Localized. – J. C. Salomon Feb 26 '13 at 22:42
  • 1
    Dupe? meta.stackexchange.com/questions/43478/… – BalusC Feb 27 '13 at 21:07
  • 1
    +1 - I think you've described the nature of a common debugging process. Whether or not that makes a good question I think greatly depends on the question. Your particular flow might be beyond what is useful (as you stated), but I've been through a few multi-step processes which proved useful to the asker and possibly to others. – Tim Medora Feb 28 '13 at 2:00
2

I think the 'Chameleon Behavior' or evolution of that type of question could be hard to prevent from the beginning. If it looks like good SO question, and it sounds like a good SO questions, then in fact it might be a good SO question.

However after further evaluation it may be 'too localized' and need to be closed as per the faq here (see too localized section). It could be difficult to find an automated way of doing this and relying on the community to flag posts like this for this condition is a great workflow IMO.

I actually had this happen to a question of mine once and agreed with it being closed: Bound Child Properties of Instance Class causing error with UpdateParameters on a ObjectDataSource It was such a specific edge case that no one would likely be able to help.

If there is any potential to spawn off another question, the recommendation would be to break the question down into a smaller, succinct piece with not such an obscure edge case scenario to be able to present the question again.

  • It looked like a good one, and sounded like a good one. Many have suggested the "too localized" concept. Taking that further, that could be applied to every single embedded systems question. Looking on www.StackExchange.com I found nothing about embedded systems. Is StackOverflow the place for embedded systems ? The bugs get, well, ultra-weird just like mine was. Did I help some guy who will face this same exact problem in 7 months from now ? Probably so. Is the idea of an embedded overflow community worth the time/effort that would be required to build it ? I hope so someday. – User.1 Feb 28 '13 at 1:31

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .