mirror of
https://github.com/ArduPilot/ardupilot.git
synced 2026-10-09 08:54:05 +08:00
Thomas Watson
d11a4356d3
This currently does not work, in particular resulting in scripting raising an internal error on stop because it doesn't think all the memory is freed because the allocated counter doesn't start out at zero because the zero on allocation behavior is broken. Cygwin has some support for overriding `malloc` (https://cygwin.com/faq/faq.html#faq.programming.own-malloc), but when this is attempted some logic in the runtime detects this case then forwards all allocator calls (`free`/`calloc`/etc.) to the user provided allocation functions. If only `malloc` is overridden, the other functions just call themselves recursively until the stack overflows. There is no supported way to use the original Cygwin allocator while overriding `malloc`, but we do not want to include our own allocator just for Cygwin. Fortunately, in some sense, there is an unsupported way, and our goal can be achieved by overwriting an internal pointer with our `malloc` implementation after the Cygwin runtime logic checks and believes that no overwrite has occurred, thereby never enabling the redirection and allowing non-`malloc` functions to still work. Our version then calls `calloc` to do the allocation and zeroing. Note that the old wrap of `_malloc_r` was faulty as that symbol is no longer used by newlib; it's just `#define`d to `malloc` these days. Tested that at least the scripting issue is fixed by failing to replicate it, plus tracing execution with `gdb` to confirm that our wrapper function is executed and does its job. The correct solution is to not make ArduPilot call `malloc` at all. We still cannot safely change the semantics to make it returned zeroed memory. This is quite the hack!