|
Wordle 735 3/6
🟩🟩⬜⬜🟨
🟩🟩🟩⬜⬜
🟩🟩🟩🟩🟩
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
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
|
|
|
|
|
Deterministic 'safe' path in the minefield. 
"In testa che avete, Signor di Ceprano?"
-- Rigoletto
|
|
|
|
|
1) When it's a tick - they aren't insects at all, but the look a lot like them - they are arachnids.
2) When it's in the manual. Then it's a feature. 
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
When a bug isn't really a bug?
When nobody complains about it.
|
|
|
|
|
Well, I suppose then this is potentially not a bug, since I've been the only one complaining so far.
Check out my IoT graphics library here:
https://honeythecodewitch/gfx
|
|
|
|
|
But you're not "nobody". 
I realize this is probably way beyond anything I've ever produced, but maybe my naive thinking can help. Take my line of questioning for whatever it's worth.
What does it take to reproduce the bug? Can you reproduce it consistently? Once you know how to reproduce it, can you come up with a way to end up with the desired results, but avoiding the path that causes the bug to surface? Can you comment out large chunks of code until the bug stops happening (assuming you know how to reproduce it consistently in the first place)? If so, can you then start uncommenting code, little-by-little until it comes up again? When that happens, comment it out once more and keep uncommenting the rest of it until everything's been restored except for the buggy part. Of course if things are chained in such a way that for function A to work, it needs the output of function B, and commenting things out as I'm suggesting might not be an option.
That's my idea anyway. I hate to go in blind, but sometimes if looking at code doesn't yield any results, no matter how long and hard you look at it, removing it and adding it back one bit at a time can be useful.
|
|
|
|
|
That's what I've been doing and why I know it's probably heap corruption.
Check this out, I thought I had isolated it to a section of code. But it wasn't that code. Because undoing a different section of code, that code starts working again. It's like pushing a bubble out of a waterbed. It just keeps moving around.
I've got it now where it functions as i said, on everything but RGB displays, where it completely hangs. I MIGHT be able to work around the hang, but without knowing what is causing this, even getting it to work, it still makes me uneasy.
Check out my IoT graphics library here:
https://honeythecodewitch/gfx
|
|
|
|
|
honey the codewitch wrote: Check this out, I thought I had isolated it to a section of code. But it wasn't that code. Because undoing a different section of code, that code starts working again. It's like pushing a bubble out of a waterbed. It just keeps moving around.
Although that doesn't always happen it should not be a surprise.
When you change the execution flow you are always going to change the data space of the application. That applies to stack, heap, etc.
Those changes can cause an overwrite/underwrite to move in the data space. And thus the system exception will appear and disappear. Could be that it never fails after that or it could just move to a different failure point. Because it really does matter where the bad write goes.
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
Well as you mentioned you could buckle down, create a test environment, and add a memory check library to track it down.
|
|
|
|
|
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;
|
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
ok - that is sound.
But might want to do a check every once in a while just to make sure they don't sneak something in.
|
|
|
|
|
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
|
|
|
|
|
|
I am mindful of this poem (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.
|
|
|
|
|
|
Criminal banner eats fires. (14)
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
|
Criminal CON
banner FLAG
eats RATIONS
fires.
CONFLAGRATIONS
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
