Today I did the impossible.
-
My SVG code was failing where an if() was testing true when there's no way it should have been. Within the 2nd line of the routine. Attempts to put debug spew, or otherwise in any way change the binary size of that routine would cause my device to enter a boot loop after flashing the firmware. Hooking up a JTAG debugger didn't help either. Weirdly it did not fail in the same place in the code, but blew up a few lines later and crashed the debugger. 4 slightly different codebases on 3 different platforms calling this code and 3 were failing. One was working. The one that was working really shouldn't have. The other 3 were failing as above. Today I found the problem. My stack was too heavy. There was just too much data on it, so I moved everything to the heap and presto. I fixed this completely blind.
To err is human. Fortune favors the monsters.
I don't know if it was me or VS. I wrote some tree building and balancing code. Got it working perfectly, so I wanted to increase the tree depth be increasing the input (random names). When I got to about ~60 (~60 depths of recursions, don't recall the actual number but using 60 as close enough) the program just terminated. No error codes, no warnings about stack size limits, nothing. I thought I created an error with my input, so retried again. Same result. Then light bulb came on about stack sizes, but there was no documented limits of VS that could find at the time (about 20 years ago). When I reduced the use of the stack (less tree depth) until it worked perfectly again. It was probably just memory limit. I was using 64 bit mode (I think). Go figure.
"A little time, a little trouble, your better day" Badfinger
-
I tried to track down a screenshot for you of VS debugger sitting inside an if() where it couldn't have possibly landed based on the watch pinned right beside it. It bugged me enough I dug at it a long while before figuring out how it happened even after just changing the code to make it work "right". These are "fun". In my case, it was based on string comparison to ''. The problem ended up being an unprintable character in the string. Finally found it by pasting the "empty" value into notepad++ with "show all the things" turned on. String.IsNullOrWhitespace() for the win... but I don't think that existed then so I can still claim awesomeness. lol.
I learned of “zero width space” through a similar frustration. It seems hackers like to use it to make fake urls that are convincing. E.g, microsoft.co[zero width space]m
-
I learned of “zero width space” through a similar frustration. It seems hackers like to use it to make fake urls that are convincing. E.g, microsoft.co[zero width space]m
Mine ended up just being a bit of line noise having ended up in a string that should've been empty. For any given setup it was meant to be flexible, not necessarily caring which sensor ended up plugged in where or if any particular one was there at all aside some "core" functionality ones. The rest was more a capture/log/present sort of deal with analytics to be done across what someone else decided mattered. This bit of presentation, made sense to me to just iterate and if something was there, add it to the list of possibly presentable stuff. Since it was logged regardless, I could basically "replay" it to the presentation to figure out why something was going boom. If you like the zero width space thing with URLs, you'll love this: Bit flips in domain names - a new attack vector? - IT Security[^]
-
I try not to hate anything but Python is an exception
In a closed society where everybody's guilty, the only crime is getting caught. In a world of thieves, the only final sin is stupidity. - Hunter S Thompson - RIP
It destroys me the cool stable diffusion stuff is most all python. I've poked and prodded and bent and banged around a bit. Playing with the guts would be way more fun if it wasn't written in nonsense I didn't have to divert focus to remember to stop hitting ; and pay attention to my CRLFs.
-
I tried to track down a screenshot for you of VS debugger sitting inside an if() where it couldn't have possibly landed based on the watch pinned right beside it. It bugged me enough I dug at it a long while before figuring out how it happened even after just changing the code to make it work "right". These are "fun". In my case, it was based on string comparison to ''. The problem ended up being an unprintable character in the string. Finally found it by pasting the "empty" value into notepad++ with "show all the things" turned on. String.IsNullOrWhitespace() for the win... but I don't think that existed then so I can still claim awesomeness. lol.
I once had VS debugger say a condition was false when the C++ code continued like it was true. Turned out the VS debugger was using unsigned pointer comparison, whereas the code was using signed pointer comparison. Debugger was technically more correct since signed pointers don't really make sense...
-
I once had VS debugger say a condition was false when the C++ code continued like it was true. Turned out the VS debugger was using unsigned pointer comparison, whereas the code was using signed pointer comparison. Debugger was technically more correct since signed pointers don't really make sense...
-
Ok, that's cool. Can see where someone mis-Types as signed without thinking. I doubt my ability to stomach the long haul doing c/c++. So. Much. Stuff. Does endian-ness ever matter to you?
jochance wrote:
Does endian-ness ever matter to you?
No, normally the compiler handles endian for you. The only time you have to check endian is when you're doing network programming, and then you just call a function to convert to network-endian from native endian or vice versa. Shouldn't even be using signed pointers, that's normally handled for you too... it was me messing up the code.
jochance wrote:
So. Much. Stuff.
Yea, C++ got a lot, but if you learn it, you learn 80% of all the other languages. I'd recommend C# as a first language or for regular use, though.
-
jochance wrote:
Does endian-ness ever matter to you?
No, normally the compiler handles endian for you. The only time you have to check endian is when you're doing network programming, and then you just call a function to convert to network-endian from native endian or vice versa. Shouldn't even be using signed pointers, that's normally handled for you too... it was me messing up the code.
jochance wrote:
So. Much. Stuff.
Yea, C++ got a lot, but if you learn it, you learn 80% of all the other languages. I'd recommend C# as a first language or for regular use, though.
-
My SVG code was failing where an if() was testing true when there's no way it should have been. Within the 2nd line of the routine. Attempts to put debug spew, or otherwise in any way change the binary size of that routine would cause my device to enter a boot loop after flashing the firmware. Hooking up a JTAG debugger didn't help either. Weirdly it did not fail in the same place in the code, but blew up a few lines later and crashed the debugger. 4 slightly different codebases on 3 different platforms calling this code and 3 were failing. One was working. The one that was working really shouldn't have. The other 3 were failing as above. Today I found the problem. My stack was too heavy. There was just too much data on it, so I moved everything to the heap and presto. I fixed this completely blind.
To err is human. Fortune favors the monsters.
“If you’ve done five impossible things this morning, why not round it off with breakfast at Milliways, the restaurant at the end of the universe!”
-
My SVG code was failing where an if() was testing true when there's no way it should have been. Within the 2nd line of the routine. Attempts to put debug spew, or otherwise in any way change the binary size of that routine would cause my device to enter a boot loop after flashing the firmware. Hooking up a JTAG debugger didn't help either. Weirdly it did not fail in the same place in the code, but blew up a few lines later and crashed the debugger. 4 slightly different codebases on 3 different platforms calling this code and 3 were failing. One was working. The one that was working really shouldn't have. The other 3 were failing as above. Today I found the problem. My stack was too heavy. There was just too much data on it, so I moved everything to the heap and presto. I fixed this completely blind.
To err is human. Fortune favors the monsters.
I'm reminded of this comic: it works and I don't know why \ it doesn't work and I don't know why
-
My SVG code was failing where an if() was testing true when there's no way it should have been. Within the 2nd line of the routine. Attempts to put debug spew, or otherwise in any way change the binary size of that routine would cause my device to enter a boot loop after flashing the firmware. Hooking up a JTAG debugger didn't help either. Weirdly it did not fail in the same place in the code, but blew up a few lines later and crashed the debugger. 4 slightly different codebases on 3 different platforms calling this code and 3 were failing. One was working. The one that was working really shouldn't have. The other 3 were failing as above. Today I found the problem. My stack was too heavy. There was just too much data on it, so I moved everything to the heap and presto. I fixed this completely blind.
To err is human. Fortune favors the monsters.
-
My SVG code was failing where an if() was testing true when there's no way it should have been. Within the 2nd line of the routine. Attempts to put debug spew, or otherwise in any way change the binary size of that routine would cause my device to enter a boot loop after flashing the firmware. Hooking up a JTAG debugger didn't help either. Weirdly it did not fail in the same place in the code, but blew up a few lines later and crashed the debugger. 4 slightly different codebases on 3 different platforms calling this code and 3 were failing. One was working. The one that was working really shouldn't have. The other 3 were failing as above. Today I found the problem. My stack was too heavy. There was just too much data on it, so I moved everything to the heap and presto. I fixed this completely blind.
To err is human. Fortune favors the monsters.
honey the codewitch wrote:
I fixed this completely blind.
That's happened to me more than once. I have a Heisen-bug that seems intractible. Every attempt at debugging it moves or changes it in some way. I give up, refactor/rework, and presto - figure out the original problem. The decision at that point is whether to fix the original code or use the reworked version.
Software Zen:
delete this; -
I tried to track down a screenshot for you of VS debugger sitting inside an if() where it couldn't have possibly landed based on the watch pinned right beside it. It bugged me enough I dug at it a long while before figuring out how it happened even after just changing the code to make it work "right". These are "fun". In my case, it was based on string comparison to ''. The problem ended up being an unprintable character in the string. Finally found it by pasting the "empty" value into notepad++ with "show all the things" turned on. String.IsNullOrWhitespace() for the win... but I don't think that existed then so I can still claim awesomeness. lol.
Down memory lane we go ... In my case we were using a GIS-system that included encryption of username and password in connection strings for SQL Server ... They had implemented a variant of Ceasar chipher of their own design ... Unfortunately 'n' and 'm' ended up being replaced with a zero-width-character in Windows Latin1 ... and having that at the end of the connection string turned out to be a rather bad idea as the full string seldom was marked in copy-n-paste :sigh: Why 'n'/'m' was such a bad choice? Their default username was "admin" and the password was "Solen" (besides, passwords was case-ignorant). and ... their system assumed that "USER ID" and "PASSWORD" allways was encrypted ... and up we pops again :-)
-
honey the codewitch wrote:
Today I did the impossible used my years of experience which allowed me to make some educated guesses about a problem, one of those guesses was accurate, and prompted a change that help fix the problem.
For some reason I believe this is more probable. :)
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment "Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst "I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
-
You can't buy experience.
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment "Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst "I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
-
Down memory lane we go ... In my case we were using a GIS-system that included encryption of username and password in connection strings for SQL Server ... They had implemented a variant of Ceasar chipher of their own design ... Unfortunately 'n' and 'm' ended up being replaced with a zero-width-character in Windows Latin1 ... and having that at the end of the connection string turned out to be a rather bad idea as the full string seldom was marked in copy-n-paste :sigh: Why 'n'/'m' was such a bad choice? Their default username was "admin" and the password was "Solen" (besides, passwords was case-ignorant). and ... their system assumed that "USER ID" and "PASSWORD" allways was encrypted ... and up we pops again :-)
