Ever pushed a bubble around a waterbed?
-
Yeah, it probably does. But as a starting point, you could run under valgrind, with lots of stack, to see if it detects anything it thinks is not kosher (which might be everything you're doing from it's point of view :( ) GNU libc allows you to hook various system calls : [Hooks for Malloc (The GNU C Library)](https://www.gnu.org/software/libc/manual/html\_node/Hooks-for-Malloc.html) Maybe that can help? or the Previous link on that page re heap consistency checking?
"A little song, a little dance, a little seltzer down your pants" Chuckles the clown
It looks like valgrind has a utility that hooks for you. However, it also looks like valgrind requires linux to build, so I'm doing it but it's more work than I originally hoped.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
It looks like valgrind has a utility that hooks for you. However, it also looks like valgrind requires linux to build, so I'm doing it but it's more work than I originally hoped.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
valgrind should be an installable package.
"A little song, a little dance, a little seltzer down your pants" Chuckles the clown
maybe it was. I built it from the sources.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
Some of my code is causing heap corruption. I don't know what code, but I suspect it's my SVG code. The issue is that it works sometimes. But if I look at it funny it starts crashing, and my stack trace keeps pointing me to different places depending on the seemingly unrelated changes I make in main(). Sometimes it points me to some font rendering code. Sometimes it points me to a seemingly innocuous assign to a local variable in my SVG parser code. It's maddening. It doesn't reproduce on the PC, at least 64-bit. I haven't tried 32 because trying to get 32-bit executables built on a windows machine these days I think requires a VM? I tried running Deleaker against it, not sure if it would pick up heap corruption - it either doesn't, or it isn't coming up on the PC. Unfortunately, much of this code is derived in many places from work that wasn't mine to begin with, and so instrumenting it to detect heap corruption if I have to wrap all malloc/reallocs etc will cause me real pain. I don't know what to do. Maybe this would rear its head if I had kilobytes instead of gigabytes of RAM? but i wouldn't even know how to set that up on a PC without altering my code to use a custom constrained heap. I'm so frustrated I've put it down, but it's gnawing at me, because it's definitely blocking any attempt I make at releasing. I wish these little IoT devices had good memory protection. It just now occurred to me to try this on an ARM and hope i can reproduce it. Maybe I'll get a better stack trace. Who knows? :confused:
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:
I haven't tried 32 because trying to get 32-bit executables built on a windows machine these days I think requires a VM?
Not if you're using older versions of Visual Studio. We have a couple products still maintained using Visual Studio 2008 that build for 32 bit.
Software Zen:
delete this; -
honey the codewitch wrote:
I haven't tried 32 because trying to get 32-bit executables built on a windows machine these days I think requires a VM?
Not if you're using older versions of Visual Studio. We have a couple products still maintained using Visual Studio 2008 that build for 32 bit.
Software Zen:
delete this;We build a part of our application called "DriverHost" as 32-bits in VS2022 and .NET 8.
-
Some of my code is causing heap corruption. I don't know what code, but I suspect it's my SVG code. The issue is that it works sometimes. But if I look at it funny it starts crashing, and my stack trace keeps pointing me to different places depending on the seemingly unrelated changes I make in main(). Sometimes it points me to some font rendering code. Sometimes it points me to a seemingly innocuous assign to a local variable in my SVG parser code. It's maddening. It doesn't reproduce on the PC, at least 64-bit. I haven't tried 32 because trying to get 32-bit executables built on a windows machine these days I think requires a VM? I tried running Deleaker against it, not sure if it would pick up heap corruption - it either doesn't, or it isn't coming up on the PC. Unfortunately, much of this code is derived in many places from work that wasn't mine to begin with, and so instrumenting it to detect heap corruption if I have to wrap all malloc/reallocs etc will cause me real pain. I don't know what to do. Maybe this would rear its head if I had kilobytes instead of gigabytes of RAM? but i wouldn't even know how to set that up on a PC without altering my code to use a custom constrained heap. I'm so frustrated I've put it down, but it's gnawing at me, because it's definitely blocking any attempt I make at releasing. I wish these little IoT devices had good memory protection. It just now occurred to me to try this on an ARM and hope i can reproduce it. Maybe I'll get a better stack trace. Who knows? :confused:
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
You can enable Address Sanitizer on Visual Studio to find memory issues such as corruptions or overruns.
-
honey the codewitch wrote:
I haven't tried 32 because trying to get 32-bit executables built on a windows machine these days I think requires a VM?
Not if you're using older versions of Visual Studio. We have a couple products still maintained using Visual Studio 2008 that build for 32 bit.
Software Zen:
delete this;That won't work. Whatever the MSVC was able to compile back then, it wasn't C++. It was "C++-ish"
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
That won't work. Whatever the MSVC was able to compile back then, it wasn't C++. It was "C++-ish"
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
It served our purposes at the time; after all it made Mr. Object (one of my coworkers) happy :-D. The fact that we're still using VS2008 to maintain these products is a reflection on how engineering management here is hardware-centric and it makes them lose their sphincter control when we mention changing tools.
Software Zen:
delete this; -
It served our purposes at the time; after all it made Mr. Object (one of my coworkers) happy :-D. The fact that we're still using VS2008 to maintain these products is a reflection on how engineering management here is hardware-centric and it makes them lose their sphincter control when we mention changing tools.
Software Zen:
delete this;I'm sure wored/works for you. My code won't compile with anything less than GCC within the last 7 years or so, or VS2022. It took microsoft that long to get their crap together. Is it really that hard to make stdint.h? And fix their template syntax madness?
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
Some of my code is causing heap corruption. I don't know what code, but I suspect it's my SVG code. The issue is that it works sometimes. But if I look at it funny it starts crashing, and my stack trace keeps pointing me to different places depending on the seemingly unrelated changes I make in main(). Sometimes it points me to some font rendering code. Sometimes it points me to a seemingly innocuous assign to a local variable in my SVG parser code. It's maddening. It doesn't reproduce on the PC, at least 64-bit. I haven't tried 32 because trying to get 32-bit executables built on a windows machine these days I think requires a VM? I tried running Deleaker against it, not sure if it would pick up heap corruption - it either doesn't, or it isn't coming up on the PC. Unfortunately, much of this code is derived in many places from work that wasn't mine to begin with, and so instrumenting it to detect heap corruption if I have to wrap all malloc/reallocs etc will cause me real pain. I don't know what to do. Maybe this would rear its head if I had kilobytes instead of gigabytes of RAM? but i wouldn't even know how to set that up on a PC without altering my code to use a custom constrained heap. I'm so frustrated I've put it down, but it's gnawing at me, because it's definitely blocking any attempt I make at releasing. I wish these little IoT devices had good memory protection. It just now occurred to me to try this on an ARM and hope i can reproduce it. Maybe I'll get a better stack trace. Who knows? :confused:
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 doesn't reproduce on the PC, at least 64-bit. I haven't tried 32 because trying to get 32-bit executables built on a windows machine these days I think requires a VM?
VS 2022 allows building for ARM, ARM64, x86, and x64. I don't remember if all compilers are installed by default, but they definitely may be installed from the installer. Your confusion may arise because VS 2022, unlike the earlier editions, is a 64-bit application.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
-
I'm sure wored/works for you. My code won't compile with anything less than GCC within the last 7 years or so, or VS2022. It took microsoft that long to get their crap together. Is it really that hard to make stdint.h? And fix their template syntax madness?
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
We build 32 bit executables and dlls in VS2022 from C++ source. We still have to support 32 bit applications.
-
We build 32 bit executables and dlls in VS2022 from C++ source. We still have to support 32 bit applications.
Yeah, for some reason when I was looking through installed targeting packs I didn't see x86 for some reason. It's there. I just missed it the first time.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix