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

Eliot Miranda eliot.miranda at gmail.com
Fri Jan 25 20:58:33 UTC 2019


On Fri, Jan 25, 2019 at 12:57 PM Eliot Miranda <eliot.miranda at gmail.com>
wrote:

> 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.
>

that should read "with atexit" of course.  Thank you autocorrect.


> 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.
>


-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20190125/6eb555a2/attachment.html>


More information about the Vm-dev mailing list