Reply to thread

Message

<blockquote data-quote="DrakeM" data-source="post: 9877807" data-attributes="member: 566442">In all due respect, you might be right but that would imply that somehow the board is using timestamps from my computer or allowing my computer to manipulate them.&nbsp; Either way, that's a terrible design.&nbsp; I find it more likely that something is corrupting timestamps within the board itself and it is an intermittent problem that my particular account is more prone to trigger.&nbsp; If you've ever written any decent amount of code, you've seen this kind of problem dozens of times with a bad or stale pointer using memory it shouldn't that may or may not cause bad effects.&nbsp; To me, this is a classic case of that.&nbsp; I wait to be proven wrong.I'll give you a real life example I was involved with.&nbsp; Customer complained our code failed on his system.&nbsp; We couldn't reproduce the problem so got access to that particular system and started to diagnose it.&nbsp; Turns out that only on that system for whatever reason, a particular memory location would sometimes contain the number 16 instead of 0.&nbsp; We had a wild pointer that used that value (although it shouldn't) and 0 was fine but 16 was bad.&nbsp; We fixed the pointer issue to point to the right place and the bug was solved.&nbsp; I've also had to diagnose issues where code would fail if the command line parameter size went past a certain size.&nbsp; It made no difference whatsoever what the parameters were, just that they went past a certain size thus shifting memory slightly and a wild pointed again picked up a bad value.&nbsp; Maybe &quot;DrakeM&quot; is too short as most other IDs are longer.&nbsp; End of programming lesson.</blockquote>

[QUOTE="DrakeM, post: 9877807, member: 566442"] In all due respect, you might be right but that would imply that somehow the board is using timestamps from my computer or allowing my computer to manipulate them. Either way, that's a terrible design. I find it more likely that something is corrupting timestamps within the board itself and it is an intermittent problem that my particular account is more prone to trigger. If you've ever written any decent amount of code, you've seen this kind of problem dozens of times with a bad or stale pointer using memory it shouldn't that may or may not cause bad effects. To me, this is a classic case of that. I wait to be proven wrong. I'll give you a real life example I was involved with. Customer complained our code failed on his system. We couldn't reproduce the problem so got access to that particular system and started to diagnose it. Turns out that only on that system for whatever reason, a particular memory location would sometimes contain the number 16 instead of 0. We had a wild pointer that used that value (although it shouldn't) and 0 was fine but 16 was bad. We fixed the pointer issue to point to the right place and the bug was solved. I've also had to diagnose issues where code would fail if the command line parameter size went past a certain size. It made no difference whatsoever what the parameters were, just that they went past a certain size thus shifting memory slightly and a wild pointed again picked up a bad value. Maybe "DrakeM" is too short as most other IDs are longer. End of programming lesson. [/QUOTE]

Name

Verification

The blue sky is what color?