Okay. I'm done today
-
I got a stack overflow in my SVG code. It never used to do that before, and I barely changed anything. I just removed a few divisions in some relatively innocuous routines. Furthermore, reverting the changes didn't fix it. There's something else going on. Well, on little embedded devices there's not a whole lot of memory protection. When you stack overflow it clobbers the stack so you can't get even a partial stack trace. Okay. My code is cross platform. I'll fire it up on my PC under MSVC++ Compile errors. Turns out what I thought was a harmless feature add makes MSVC++'s compiler just scream. 100 errors for less than 10 lines of code. I removed the feature. It's a shame too, as it was a real convenience. Got it building. Put together my test code - basically just de-arduino-ing it and then making it spit the graphics as ascii art to the console. No big deal. Run it. No crash. No stack overflow. Which tells me the problem is the one I didn't want to try and solve. Now I need to figure out what's taking all the stack, rather than what is recursing indefinitely. I did move 2KB off the stack but it's still dying on me. This code is non-trivial. It's the SVG parsing code, and took me forever to create it. I tried to keep it light on the stack but apparently it's not light enough. Pruning for stack space in a veritable labyrinth of function calls is not my idea of fun. I have a dentist appointment later today which seems appealing by comparison. :rolleyes:
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
I got a stack overflow in my SVG code. It never used to do that before, and I barely changed anything. I just removed a few divisions in some relatively innocuous routines. Furthermore, reverting the changes didn't fix it. There's something else going on. Well, on little embedded devices there's not a whole lot of memory protection. When you stack overflow it clobbers the stack so you can't get even a partial stack trace. Okay. My code is cross platform. I'll fire it up on my PC under MSVC++ Compile errors. Turns out what I thought was a harmless feature add makes MSVC++'s compiler just scream. 100 errors for less than 10 lines of code. I removed the feature. It's a shame too, as it was a real convenience. Got it building. Put together my test code - basically just de-arduino-ing it and then making it spit the graphics as ascii art to the console. No big deal. Run it. No crash. No stack overflow. Which tells me the problem is the one I didn't want to try and solve. Now I need to figure out what's taking all the stack, rather than what is recursing indefinitely. I did move 2KB off the stack but it's still dying on me. This code is non-trivial. It's the SVG parsing code, and took me forever to create it. I tried to keep it light on the stack but apparently it's not light enough. Pruning for stack space in a veritable labyrinth of function calls is not my idea of fun. I have a dentist appointment later today which seems appealing by comparison. :rolleyes:
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
honey the codewitch wrote:
. It never used to do that before, and I barely changed anything. I just removed a few divisions in some relatively innocuous routines.
lol. Famous last words...
CI/CD = Continuous Impediment/Continuous Despair
-
honey the codewitch wrote:
. It never used to do that before, and I barely changed anything. I just removed a few divisions in some relatively innocuous routines.
lol. Famous last words...
CI/CD = Continuous Impediment/Continuous Despair
Like I said, I reverted the changes and the problem still occurs. I know better than not to verify that.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
I got a stack overflow in my SVG code. It never used to do that before, and I barely changed anything. I just removed a few divisions in some relatively innocuous routines. Furthermore, reverting the changes didn't fix it. There's something else going on. Well, on little embedded devices there's not a whole lot of memory protection. When you stack overflow it clobbers the stack so you can't get even a partial stack trace. Okay. My code is cross platform. I'll fire it up on my PC under MSVC++ Compile errors. Turns out what I thought was a harmless feature add makes MSVC++'s compiler just scream. 100 errors for less than 10 lines of code. I removed the feature. It's a shame too, as it was a real convenience. Got it building. Put together my test code - basically just de-arduino-ing it and then making it spit the graphics as ascii art to the console. No big deal. Run it. No crash. No stack overflow. Which tells me the problem is the one I didn't want to try and solve. Now I need to figure out what's taking all the stack, rather than what is recursing indefinitely. I did move 2KB off the stack but it's still dying on me. This code is non-trivial. It's the SVG parsing code, and took me forever to create it. I tried to keep it light on the stack but apparently it's not light enough. Pruning for stack space in a veritable labyrinth of function calls is not my idea of fun. I have a dentist appointment later today which seems appealing by comparison. :rolleyes:
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
I sympathise. Many years ago I worked on a desktop financial calculator which had 32K of EPROM for all the code and 16K of battery backed RAM for everything else, all the persistent storage and workspace, display buffer, the lot, and the number of times we had late nights reworking the code to save a few bytes here and there so it would fit in the EPROM, or shaving the stack usage so our variables survived ... a very character building time.
-
I got a stack overflow in my SVG code. It never used to do that before, and I barely changed anything. I just removed a few divisions in some relatively innocuous routines. Furthermore, reverting the changes didn't fix it. There's something else going on. Well, on little embedded devices there's not a whole lot of memory protection. When you stack overflow it clobbers the stack so you can't get even a partial stack trace. Okay. My code is cross platform. I'll fire it up on my PC under MSVC++ Compile errors. Turns out what I thought was a harmless feature add makes MSVC++'s compiler just scream. 100 errors for less than 10 lines of code. I removed the feature. It's a shame too, as it was a real convenience. Got it building. Put together my test code - basically just de-arduino-ing it and then making it spit the graphics as ascii art to the console. No big deal. Run it. No crash. No stack overflow. Which tells me the problem is the one I didn't want to try and solve. Now I need to figure out what's taking all the stack, rather than what is recursing indefinitely. I did move 2KB off the stack but it's still dying on me. This code is non-trivial. It's the SVG parsing code, and took me forever to create it. I tried to keep it light on the stack but apparently it's not light enough. Pruning for stack space in a veritable labyrinth of function calls is not my idea of fun. I have a dentist appointment later today which seems appealing by comparison. :rolleyes:
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
I do not know anything about rust, but does rust have infinite stack ?
-
Please explain why RUST would have solved this problem. Honest and curious question. stack issues are common in embedded systems, no matter what development language you choose.
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
