I have started to integrate some Rust code into an existing C++ project, and that Rust code also depends on some C calls to another entity. The whole mess together triggers a nasty memory bug. I will just get some vague details since that debug itself is not completely on-topic, but I get "malloc_consolidate(): invalid chunk size" near the top of my call stack in an unrelated thread to my own stuff, which traditionally smells like some code couldn't stay in its lane and overran a buffer.
While playing around with this, I had run valgrind, which exposed some leaks in my code, but it would only ever show the call stack up to my calls into the widestring crate; it would never show me where in my actual source files with a file and line number. Nothing I did could improve that situation with valgrind. I saw a few threads over the past few years where people had a similar experience with valgrind and none of the solutions worked. I also created a bespoke build from the head in git for valgrind and nothing really improved. I eventually tried heaptrack, which did it right the first time and took me right to the stuff I was creating/allocating and not freeing.
Valgrind isn't finding any issues like a buffer overrun or a double free despite a suspicious call stack diving down into memory allocation. I'd like to try something else from the level of my Rust code; I do have a test front end I can use. Is there something I can leverage to get some more confidence in the code up to my layer here? Can I replace malloc with electric fence? I'm not familiar with how llvm might complicate this.