Re: [Pharo-users] macOS VM builds with AddressSanitizer/LeakSanitizer

Hi Manuel,

On Fri, 25 Jan 2019 at 16:09, Manuel Leuenberger <[hidden email]> wrote:

Hi,

Anybody has experience building the VM (pharo.cog.spur) on macOS with custom compiler and flags?

Well, I have experience building with flags I chose, yes.

 

I am observing a memory leak on macOS Sierra/Pharo 7/GToolkit. I cannot precisely locate the issue, e.g. I cannot reliably reproduce the problem. So I tried to use AddressSanitizer/LeakSanitizer with custom debug builds of the VM and libMoz2D (used by GToolkit). As building on Linux is easier than on macOS, I got myself some help from a colleague and we managed to build those two artifacts on Linux by sprinkling "-g3 -O0 -fsanitize=leak -fsanitize-memory-track-origins" into the CFLAGS wherever they appear or are picked up. This works fine on Debian 9 with "CC=clang-6.0 CXX=clang++-6.0 ./mvm -d" and some on-the-fly patches for other breaking things.

Unfortunately, I cannot reproduce the problem on Linux, so it seems to be platform specific. Even more so, I seem to be the only one observing the issue. Other GToolkit users do not report this issue. As these kind of issues are freaking me out, I cannot let go and need to learn what causes them. So, here I am, trying to build the VM on macOS Sierra and miserably failing to include the sanitizer tags with Clang and giving me those tasty leak reports on VM shutdown.

The leak is not observable in the image memory, i.e. the image size reported by the VM is not growing, I am suspecting FFI, possibly in Moz2D, to leak.
The FFI registry in the VM also does not report many or large surviving objects, so I would assume the problem to be either on the plugin or VM side.

Right.  If memory is allocated as a side effect of an FFI call and not freed then there will be a memory leak in the C heap.

 

My two concrete questions are:
1. Is it even feasible to detect leaks with this approach? E.g., how does the VM behave on shutdown? Will the leaks show up in the report or will they not be covered, as the VM actually frees everything before shutting down?

Yes it is feasible.  The VM exits via the standard route (exit(3); see the Objective-C method ioExitWithErrorCode: in platforms/iOS//vm/Common/Classes/sqSqueakMainApplication.m).  So if a leak checker registers itself with ataxia its exit function will run.

2. How do I swap compiler and inject flags on macOS builds? On Linux it was fairly easily done by replacing some variables. But on macOS, Xcode seems to like to mess with me. I got myself Clang-6.0 on macOS from MacPorts, the same as version as I took on Linux. I can build the VM with this, but it there is no leak report on VM shutdown. Anybody has an idea how to debug the build?

 

First of all you don't want to swap compiler.  You simply want to link with we error checking.  clang is the standard compiler and you can bet that it supports leak checking.  It has served as the de facto gcc on Mac OS X for a few releases yet.  Second, flags are specified in {build.macos64x64,build.macos32x86}/common/Makefile.flags, and can be modified by supplying CFLAGS= on the command line.  If you use the debug build you won't need to disable optimization as it already is.  Have you read {build.macos64x64,build.macos32x86}/HowToBuild?  It should help.

Bonus question: Can the VM provide an inspectable view of all the allocated memory to the image? That would be perfect. I think Luke Gorrie does some magic like this in his Studio for core dumps etc.

 

I'm not aware of any such tools for our VM, but I would think it would be possible to port Luke Gorrie's work, provided the license is amenable.  Have you got pointers to Luke's work?

Cheers,
Manuel

HTH.  Good luck, and please report back.