Closed mrk-its closed 4 months ago
Thanks, I expected that something would break after a big malloc rewrite; looks like this is it. I'll go through and debug this.
Nothing immediately jumps out at me as incorrect in realloc
; the issue may be subtle.
Could you make a .ll
version of this that I could compile against a different version of malloc
? I've got a bunch of tracing in the SDK that would be very helpful.
Failing that, the output of this recompiled against an SDK with MALLOC_TRACE
set to 1 inmalloc.cc
might be enough, but it's worse than being able to add printing on my end.
Debug build: day05-0cd8b2583aaf17c6.zip
Release build: day05-fa63e06c3e659ee6.zip
It was produced by llvm-mos: 1d7989f29 and sdk: 777e89e
Following rust program day05.zip crashes because of heap memory corruption.
I'm attaching small python script with sequence of
malloc
/realloc
/free
calls logged from above program, looking for block overlaps. It looks that one of therealloc
calls returns region overlapping with other block allocated earlier (probably because of https://github.com/llvm-mos/llvm-mos-sdk/pull/292)Replacing
realloc
withalloc
+memcpy
makes this program working fine. It also works fine on older SDK with previous malloc implementation.