[Vm-dev] [Pharo-users] macOS VM builds with AddressSanitizer/LeakSanitizer

Eliot Miranda eliot.miranda at gmail.com
Fri Jan 25 20:57:26 UTC 2019


Hi Manuel,

On Fri, 25 Jan 2019 at 16:09, Manuel Leuenberger <leuenberger at inf.unibe.ch>
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20190125/3aa8f7d2/attachment-0001.html>


More information about the Vm-dev mailing list