When a bug isn't really a bug?
-
Some MS controls leave "artifacts" when they change from one state to another. I have to do certain things (that look like "rituals") to make them go away. I consider that an MS "bug". It's also where I wind up putting the most comments. But it is deterministic ... you just have to determine what is required to fix it.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
Gerry Schmitz wrote:
rituals
Having delved into COM, the words 'arcane' and 'obscene' both come to mind.
Software Zen:
delete this; -
Gerry Schmitz wrote:
rituals
Having delved into COM, the words 'arcane' and 'obscene' both come to mind.
Software Zen:
delete this;I was more tempted by "cargo cult programming"[^]
Mircea
-
honey the codewitch wrote:
I will get the same sequence of As and Bs every time, on every machine with the same chip.
I am not a great fan of absolutes. Especially if one starts relying on them. No doubt that is true for some cases. But although I know almost nothing about embedded I do know that they have been adding more complexity over time. So seems likely that some chips either do or will start managing threads in a less deterministic way. Although you will probably be able to shop for devices where either that is true or not true.
jschell wrote:
I am not a great fan of absolutes. Especially if one starts relying on them.
Long ago I coined the adage: "Only a novice thinks computers are deterministic machines".
Mircea
-
Hrmmm. I have some code with suspected heap corruption. I've pored over it and can't find anything. However, the modifications I've made to the codebase in an attempt to run it down have actually yielded a copy that works reliably on several devices - devices that don't use a display with an "RGB interface" bus. On any display with an RGB interface bus the device hangs as soon as it receives serial data and rebuilds the display with it. Complete hard freeze, requiring a reflash or hard reset. I might be able to work around this by switching out my lcd_init.h with something like LovyanGFX to do my last mile display communication. However, lcd_init.h has never caused me problems before. I suspect that even if switching it out "fixes" the problem, it will have more buried the bug than actually fixed it. Now here's the thing with IoT, esp when you aren't using I/O bound multithreading or anything complicated to effect the following: Every time I boot, if i call malloc and print that pointer I get back as a hex integer to the console, it will be the same value every single time (as long as the requested size is the same). If I create a thread on each core, and spit out "A" on one, and "B" on the other, I will get the same sequence of As and Bs every time, on every machine with the same chip. That makes it very much unlike development on a PC. There aren't fiddly bits in the background making things non-deterministic. The bottom line is, if I bury this bug well enough, for all practical purposes I have "fixed" it. I hate this, but I know it to be true. I don't want to use what I know to be true to move forward on this project. Burying the bug just doesn't sit right with me. But it's an option. I wouldn't be the first to do it. Far from it. Times like this call for a little Aesop Rock
Got an angel on my left shoulder, a devil on the polar Got a mug a frigid, got a mug a solar, sliiidde over The recipe's designed to plug the appetite for continuity By stitching togetherness theme congruents (beautifully) I peel back hearts and lodge greed physics in the chambers Cauterize the wound and heads like "Gimme gimme something major" Road side prophetic, ascend well (well) Enveloped in a mummy ribbon system Blistering in a wishing well BIG BANG!
I don't expect most people to understand that, but he and I communicate, even if he doesn't know it.
Check out my IoT graphics library here: https://honeythecodewitch/gfx
It's a feature!
-
Hrmmm. I have some code with suspected heap corruption. I've pored over it and can't find anything. However, the modifications I've made to the codebase in an attempt to run it down have actually yielded a copy that works reliably on several devices - devices that don't use a display with an "RGB interface" bus. On any display with an RGB interface bus the device hangs as soon as it receives serial data and rebuilds the display with it. Complete hard freeze, requiring a reflash or hard reset. I might be able to work around this by switching out my lcd_init.h with something like LovyanGFX to do my last mile display communication. However, lcd_init.h has never caused me problems before. I suspect that even if switching it out "fixes" the problem, it will have more buried the bug than actually fixed it. Now here's the thing with IoT, esp when you aren't using I/O bound multithreading or anything complicated to effect the following: Every time I boot, if i call malloc and print that pointer I get back as a hex integer to the console, it will be the same value every single time (as long as the requested size is the same). If I create a thread on each core, and spit out "A" on one, and "B" on the other, I will get the same sequence of As and Bs every time, on every machine with the same chip. That makes it very much unlike development on a PC. There aren't fiddly bits in the background making things non-deterministic. The bottom line is, if I bury this bug well enough, for all practical purposes I have "fixed" it. I hate this, but I know it to be true. I don't want to use what I know to be true to move forward on this project. Burying the bug just doesn't sit right with me. But it's an option. I wouldn't be the first to do it. Far from it. Times like this call for a little Aesop Rock
Got an angel on my left shoulder, a devil on the polar Got a mug a frigid, got a mug a solar, sliiidde over The recipe's designed to plug the appetite for continuity By stitching togetherness theme congruents (beautifully) I peel back hearts and lodge greed physics in the chambers Cauterize the wound and heads like "Gimme gimme something major" Road side prophetic, ascend well (well) Enveloped in a mummy ribbon system Blistering in a wishing well BIG BANG!
I don't expect most people to understand that, but he and I communicate, even if he doesn't know it.
Check out my IoT graphics library here: https://honeythecodewitch/gfx
I am mindful of this poem ([https://www.gnu.org/fun/jokes/last.bug.txt\](https://www.gnu.org/fun/jokes/last.bug.txt)):
Quote:
THE LAST BUG by Lou Ellen Davis "But you're out of your mind," They said with a shrug. "The customer's happy; What's one little bug?" But he was determined. The others went home. He spread out the program, Deserted, alone. The cleaning men came, The whole room was cluttered With memory-dumps, punch cards. "I'm close," he muttered. The mumbling got louder, Simple deduction, "I've got it, it's right, Just change one instruction." It still wasn't perfect, As year followed year, And strangers would comment, "Is that guy still here?" He died at the console, Of hunger and thirst. Next day he was buried, Face down, nine-edge first. And the last bug in sight, An ant passing by, Saluted his tombstone, And whispered, "Nice try."
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
-
I am mindful of this poem ([https://www.gnu.org/fun/jokes/last.bug.txt\](https://www.gnu.org/fun/jokes/last.bug.txt)):
Quote:
THE LAST BUG by Lou Ellen Davis "But you're out of your mind," They said with a shrug. "The customer's happy; What's one little bug?" But he was determined. The others went home. He spread out the program, Deserted, alone. The cleaning men came, The whole room was cluttered With memory-dumps, punch cards. "I'm close," he muttered. The mumbling got louder, Simple deduction, "I've got it, it's right, Just change one instruction." It still wasn't perfect, As year followed year, And strangers would comment, "Is that guy still here?" He died at the console, Of hunger and thirst. Next day he was buried, Face down, nine-edge first. And the last bug in sight, An ant passing by, Saluted his tombstone, And whispered, "Nice try."
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
Haha, that reminds me of this song: Cake - The Distance - YouTube[^]
Check out my IoT graphics library here: https://honeythecodewitch/gfx
-
When I said every machine, I meant every machine I am targeting, and this all holds true for those.
Check out my IoT graphics library here: https://honeythecodewitch/gfx
-
It does. But if that bad write doesn't actually cause an issue, and the app can be tested to work under those conditions, with that particular firmware, is it worth releasing? not for anything mission critical - it's a tool to monitor your PC's temps and usage. Sort of a philosophical question if anything.
Check out my IoT graphics library here: https://honeythecodewitch/gfx
honey the codewitch wrote:
with that particular firmware, is it worth releasing?
Perhaps in your situation (as per your other point about deterministic threads.) If you can be assured of the data flow then the error is going to be there but not be impacting anything. When I worked in C/C++ I knew the data flow was not predictable. So I could not have left that in any of those systems.
-
honey the codewitch wrote:
with that particular firmware, is it worth releasing?
Perhaps in your situation (as per your other point about deterministic threads.) If you can be assured of the data flow then the error is going to be there but not be impacting anything. When I worked in C/C++ I knew the data flow was not predictable. So I could not have left that in any of those systems.
I've decided not to release it. It's silly, but I decided to make my standard such that it must at least work on the device I embedded in my PC's chassis. Currently it does not. That's one of the problem devices. I have some ideas on how to tip toe around this issue, but it involves static allocation. I've already tried lazy dynamic allocation, both with releasing/recreating and recycling. Neither method seems to work with my UIX library. I think if i make several static controls things might be okay, although I'd be hard pressed to understand why. Right now it's just a hunch.
Check out my IoT graphics library here: https://honeythecodewitch/gfx
-
I've decided not to release it. It's silly, but I decided to make my standard such that it must at least work on the device I embedded in my PC's chassis. Currently it does not. That's one of the problem devices. I have some ideas on how to tip toe around this issue, but it involves static allocation. I've already tried lazy dynamic allocation, both with releasing/recreating and recycling. Neither method seems to work with my UIX library. I think if i make several static controls things might be okay, although I'd be hard pressed to understand why. Right now it's just a hunch.
Check out my IoT graphics library here: https://honeythecodewitch/gfx
