Nuclear Alpha Blending: A C++ war story
-
To be clear, this is not a programming question. I don't need help with this, it's just something I don't want to do, which I'm sure other C++ developers can relate to. I am not using the STL because this has to run on machines with very little RAM, and with questionably compliant headers. I have a paint routine in my canvas controls that I'm drawing a gradient in. This routine uses alpha-blending between two RGBa8888 or HSVa8888 colors to accommodate creating the gradient. It's relatively simple in practice because my library handles the alpha blending. You just call a blend function and pass it a scaled ratio between 0 and 1. The alpha blending is completely battle tested and used all over the library to do things like anti-alias fonts. The paint routine more or less works as long as I don't call the blend function to create the gradient. As soon as I add the call, I get corrupted data in my incoming serial stream (handled in a separate C++ implementation file) and the app hangs, pretty reliably. It's about the only reliable thing about it. C and C++ developers already know where this is headed. :(( Heap corruption has reared its ugly head. This is probably related to the fact that I am not using the STL to do anything. A lot of times I wish I was but IoT leaves me little of the STL to practically use. My options are: - Rewrite, and maybe prototype using the STL, which at least works on the ESP32 platform. The codebase is pretty small and some of it is reusable. - Instrument my code for heap testing. This is a pain in my backside, particularly if the heap corruption is coming from my graphics library or my data structures library. I doubt it, but you never know. - rearchitect my code so it doesn't need dynamic allocations. This would make it far less efficient and probably overflow the .bss segment on less capable devices with all the statically initialized arrays. Kevin bless IoT development.
Check out my IoT graphics library here: https://honeythecodewitch/gfx
Is it possible to compile the code to run under Windows or Linux? If so could valgrind or Dr. Memory help find the problem?
-
To be clear, this is not a programming question. I don't need help with this, it's just something I don't want to do, which I'm sure other C++ developers can relate to. I am not using the STL because this has to run on machines with very little RAM, and with questionably compliant headers. I have a paint routine in my canvas controls that I'm drawing a gradient in. This routine uses alpha-blending between two RGBa8888 or HSVa8888 colors to accommodate creating the gradient. It's relatively simple in practice because my library handles the alpha blending. You just call a blend function and pass it a scaled ratio between 0 and 1. The alpha blending is completely battle tested and used all over the library to do things like anti-alias fonts. The paint routine more or less works as long as I don't call the blend function to create the gradient. As soon as I add the call, I get corrupted data in my incoming serial stream (handled in a separate C++ implementation file) and the app hangs, pretty reliably. It's about the only reliable thing about it. C and C++ developers already know where this is headed. :(( Heap corruption has reared its ugly head. This is probably related to the fact that I am not using the STL to do anything. A lot of times I wish I was but IoT leaves me little of the STL to practically use. My options are: - Rewrite, and maybe prototype using the STL, which at least works on the ESP32 platform. The codebase is pretty small and some of it is reusable. - Instrument my code for heap testing. This is a pain in my backside, particularly if the heap corruption is coming from my graphics library or my data structures library. I doubt it, but you never know. - rearchitect my code so it doesn't need dynamic allocations. This would make it far less efficient and probably overflow the .bss segment on less capable devices with all the statically initialized arrays. Kevin bless IoT development.
Check out my IoT graphics library here: https://honeythecodewitch/gfx
If you are 110% sure that your allocation causes the issue, then go with STL. This probably will be faster than hunting a bug in your code. The third option is not a valid one unless you are doing some strange stuff.
Advertise here – minimum three posts per day are guaranteed.
-
Is it possible to compile the code to run under Windows or Linux? If so could valgrind or Dr. Memory help find the problem?
A lot of it will. The tricky issue is the display. It's possible to get it running under DirectX because I wrote a display shim for it, but it's slow.
Check out my IoT graphics library here: https://honeythecodewitch/gfx
-
To be clear, this is not a programming question. I don't need help with this, it's just something I don't want to do, which I'm sure other C++ developers can relate to. I am not using the STL because this has to run on machines with very little RAM, and with questionably compliant headers. I have a paint routine in my canvas controls that I'm drawing a gradient in. This routine uses alpha-blending between two RGBa8888 or HSVa8888 colors to accommodate creating the gradient. It's relatively simple in practice because my library handles the alpha blending. You just call a blend function and pass it a scaled ratio between 0 and 1. The alpha blending is completely battle tested and used all over the library to do things like anti-alias fonts. The paint routine more or less works as long as I don't call the blend function to create the gradient. As soon as I add the call, I get corrupted data in my incoming serial stream (handled in a separate C++ implementation file) and the app hangs, pretty reliably. It's about the only reliable thing about it. C and C++ developers already know where this is headed. :(( Heap corruption has reared its ugly head. This is probably related to the fact that I am not using the STL to do anything. A lot of times I wish I was but IoT leaves me little of the STL to practically use. My options are: - Rewrite, and maybe prototype using the STL, which at least works on the ESP32 platform. The codebase is pretty small and some of it is reusable. - Instrument my code for heap testing. This is a pain in my backside, particularly if the heap corruption is coming from my graphics library or my data structures library. I doubt it, but you never know. - rearchitect my code so it doesn't need dynamic allocations. This would make it far less efficient and probably overflow the .bss segment on less capable devices with all the statically initialized arrays. Kevin bless IoT development.
Check out my IoT graphics library here: https://honeythecodewitch/gfx
-
Pardon my ignorance. What is "STL"? I only know STL as a geometry format standard.
"A little time, a little trouble, your better day" Badfinger
The Standard Template Library. Basically the "runtime library" for C++ (not really a runtime lib but serves the same purpose as those do in other languages)
Check out my IoT graphics library here: https://honeythecodewitch/gfx
-
A lot of it will. The tricky issue is the display. It's possible to get it running under DirectX because I wrote a display shim for it, but it's slow.
Check out my IoT graphics library here: https://honeythecodewitch/gfx
honey the codewitch wrote:
but it's slow.
as long as it helps to find the error... ;)
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
-
The Standard Template Library. Basically the "runtime library" for C++ (not really a runtime lib but serves the same purpose as those do in other languages)
Check out my IoT graphics library here: https://honeythecodewitch/gfx
-
The Standard Template Library. Basically the "runtime library" for C++ (not really a runtime lib but serves the same purpose as those do in other languages)
Check out my IoT graphics library here: https://honeythecodewitch/gfx
-
To be clear, this is not a programming question. I don't need help with this, it's just something I don't want to do, which I'm sure other C++ developers can relate to. I am not using the STL because this has to run on machines with very little RAM, and with questionably compliant headers. I have a paint routine in my canvas controls that I'm drawing a gradient in. This routine uses alpha-blending between two RGBa8888 or HSVa8888 colors to accommodate creating the gradient. It's relatively simple in practice because my library handles the alpha blending. You just call a blend function and pass it a scaled ratio between 0 and 1. The alpha blending is completely battle tested and used all over the library to do things like anti-alias fonts. The paint routine more or less works as long as I don't call the blend function to create the gradient. As soon as I add the call, I get corrupted data in my incoming serial stream (handled in a separate C++ implementation file) and the app hangs, pretty reliably. It's about the only reliable thing about it. C and C++ developers already know where this is headed. :(( Heap corruption has reared its ugly head. This is probably related to the fact that I am not using the STL to do anything. A lot of times I wish I was but IoT leaves me little of the STL to practically use. My options are: - Rewrite, and maybe prototype using the STL, which at least works on the ESP32 platform. The codebase is pretty small and some of it is reusable. - Instrument my code for heap testing. This is a pain in my backside, particularly if the heap corruption is coming from my graphics library or my data structures library. I doubt it, but you never know. - rearchitect my code so it doesn't need dynamic allocations. This would make it far less efficient and probably overflow the .bss segment on less capable devices with all the statically initialized arrays. Kevin bless IoT development.
Check out my IoT graphics library here: https://honeythecodewitch/gfx
What do you believe to be the root cause of your problem? It sounds like your code is trampling memory. If so, using statically allocated memory could still result in crashes. This kind of bug is hard to find but must be found and fixed. Could the heap implementation itself have a bug? Could a race condition from multi-threading or work done at interrupt level be corrupting the heap?
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
What do you believe to be the root cause of your problem? It sounds like your code is trampling memory. If so, using statically allocated memory could still result in crashes. This kind of bug is hard to find but must be found and fixed. Could the heap implementation itself have a bug? Could a race condition from multi-threading or work done at interrupt level be corrupting the heap?
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.I doubt it's anything that complicated. I suspect some foolery in either my lifetime management or somehow, somewhere I'm not copying memory correctly. At one point - after I ported some of it to use the STL, I needed to pull pointers out of a vector to pass to a function, but that concerned me due to the potential for the vector reallocating, even though I called reserve() - I don't trust the inner machinations of the STL and it's too much to remember all of its intricacies. Instead I went back to my tried and true new/delete and stashing pointers in my simple_vector class. I don't think that's the problem. However, there's a lot of spinning plates to balance. Incoming serial data can cause a lot of deallocations and reallocations, and while that is NOT happening while my on_paint callbacks are being summoned, it still makes me nervous. In the end I'm thinking of a total rewrite of the firmware to see if I can make it more cohesive. I have some ideas.
Check out my IoT graphics library here: https://honeythecodewitch/gfx
-
I doubt it's anything that complicated. I suspect some foolery in either my lifetime management or somehow, somewhere I'm not copying memory correctly. At one point - after I ported some of it to use the STL, I needed to pull pointers out of a vector to pass to a function, but that concerned me due to the potential for the vector reallocating, even though I called reserve() - I don't trust the inner machinations of the STL and it's too much to remember all of its intricacies. Instead I went back to my tried and true new/delete and stashing pointers in my simple_vector class. I don't think that's the problem. However, there's a lot of spinning plates to balance. Incoming serial data can cause a lot of deallocations and reallocations, and while that is NOT happening while my on_paint callbacks are being summoned, it still makes me nervous. In the end I'm thinking of a total rewrite of the firmware to see if I can make it more cohesive. I have some ideas.
Check out my IoT graphics library here: https://honeythecodewitch/gfx
Time to bring out your rubber duck!
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
Time to bring out your rubber duck!
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.I traced the code to a routine in my graphics library. I think. I've just run it down and am trying to verify (without a debugger LOL) Also without much reliable in the way of spew because I'm already using the serial port for communication. I've half bodged a logging system into it, but everything has to be working right for it to function, and i can't get stack traces out of dumps using this.
Check out my IoT graphics library here: https://honeythecodewitch/gfx
-
To be clear, this is not a programming question. I don't need help with this, it's just something I don't want to do, which I'm sure other C++ developers can relate to. I am not using the STL because this has to run on machines with very little RAM, and with questionably compliant headers. I have a paint routine in my canvas controls that I'm drawing a gradient in. This routine uses alpha-blending between two RGBa8888 or HSVa8888 colors to accommodate creating the gradient. It's relatively simple in practice because my library handles the alpha blending. You just call a blend function and pass it a scaled ratio between 0 and 1. The alpha blending is completely battle tested and used all over the library to do things like anti-alias fonts. The paint routine more or less works as long as I don't call the blend function to create the gradient. As soon as I add the call, I get corrupted data in my incoming serial stream (handled in a separate C++ implementation file) and the app hangs, pretty reliably. It's about the only reliable thing about it. C and C++ developers already know where this is headed. :(( Heap corruption has reared its ugly head. This is probably related to the fact that I am not using the STL to do anything. A lot of times I wish I was but IoT leaves me little of the STL to practically use. My options are: - Rewrite, and maybe prototype using the STL, which at least works on the ESP32 platform. The codebase is pretty small and some of it is reusable. - Instrument my code for heap testing. This is a pain in my backside, particularly if the heap corruption is coming from my graphics library or my data structures library. I doubt it, but you never know. - rearchitect my code so it doesn't need dynamic allocations. This would make it far less efficient and probably overflow the .bss segment on less capable devices with all the statically initialized arrays. Kevin bless IoT development.
Check out my IoT graphics library here: https://honeythecodewitch/gfx
honey the codewitch wrote:
Instrument my code for heap testing.
I never did embedded stuff. But I did use memory leak testing a lot. Just because, even with discipline, I figured I might have missed something. Reducing the testing to libraries with that in place with unit testing (I use that term very loosely - test the entire library and not just units) allows one to simplify the scope and be more sure of the stability. Leak is also used loosely. A leak library can test for actual leaks, overwrites, underwrites, unallocated writes, etc.
