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

Mon Jan 28 10:45:18 UTC 2019

Hm, something is still not working. I compiled pharo.cog.spur and libMoz2D with clang-7.0 and '-fsanitize=address -fsanitize-recover=address -mllvm -asan-stack=0 -mllvm -asan-globals=0 -fno-omit-frame-pointer -g3' or '-fsanitize=leak -fno-omit-frame-pointer -g3', and then run it with 'ASAN_OPTIONS=detect_leaks=1 PharoDebug.app/Contents/MacOS/Pharo Pharo.image'. This gives me the leak reports on shutdown, but I cannot view any Bloc element, I always get a primitive failed error in 

BlExternalForm >> primCreateManualSurfaceWidth: width height: height rowPitch: rowPitch depth: depth isMSB: isMSB
	<primitive: 'primitiveCreateManualSurface' module: 'SqueakFFIPrims'>
	self primitiveFailed

How can I debug this?

I do not get stderr that would give me any hints what failed exactly. So, did the primitive fail during execution or was it not found at all? I looked into the TravisCI build and compiled with 'ARCH="macos64x64" FLAVOR="pharo.cog.spur" ./mvm -d', but that did not change anything. I noticed that the SqueakFFIPrims plugin defines primitiveCreateManualSurface on all architectures, but how do I ensure and check that the built VM actually includes this primitive? Am I missing another flag or env variable?

Cheers,
Manuel

> On 26 Jan 2019, at 18:09, Manuel Leuenberger <leuenberger at inf.unibe.ch> wrote:
> 
> Hi all,
> 
> Thanks for all the hints, I finally got that thing flying!
> 
> Building with MacPorts clang-6.0 and editing flags finally worked when I found all the places (OFLAGS and LDFLAGS took a while to figure out). Building with Apple clang gave me "leak detection not supported", so that one is probably too old for what I want to do. Now I still have to trigger the leak I am after. I will provide a bug report in the leaking component and I will report the diff on flags I had to make, they might be useful for others. It was pretty dirty, e.g. I had to symlink some objects in the MacPorts AddressSanitizer installation as some binaries were linked with wrong paths, ew.
> 
> Again, thanks for encouraging me by telling me that I should be possible, I was already close to giving up. This Xcode env is a beast I try to avoid, too opaque to me.
> 
> Below is an example report, with the symbolizer it even tells you the source location, pretty handy. I guess this is not really a leak, but expected behavior for FFI.
> 
> Cheers,
> Manuel
> 
> 
> =================================================================
> ==12156==ERROR: LeakSanitizer: detected memory leaks
> 
> Direct leak of 9080 byte(s) in 15 object(s) allocated from:
>     #0 0x10a2cb2cc in wrap_malloc (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x592cc)
>     #1 0x10a091410 in primitiveFFIAllocate (Pharo:x86_64+0x100315410)
>     #2 0x1137369b7  (<unknown module>)
>     #3 0x109d7e56c in interpret gcc3x-cointerp.c:2754
>     #4 0x109f7dc29 in -[sqSqueakMainApplication runSqueak] sqSqueakMainApplication.m:201
>     #5 0x7fffc93786fc in __NSFirePerformWithOrder (Foundation:x86_64+0xd76fc)
>     #6 0x7fffc78cfc56 in __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ (CoreFoundation:x86_64h+0xa6c56)
>     #7 0x7fffc78cfbc6 in __CFRunLoopDoObservers (CoreFoundation:x86_64h+0xa6bc6)
>     #8 0x7fffc78b05f8 in __CFRunLoopRun (CoreFoundation:x86_64h+0x875f8)
>     #9 0x7fffc78b0033 in CFRunLoopRunSpecific (CoreFoundation:x86_64h+0x87033)
>     #10 0x7fffc6e10ebb in RunCurrentEventLoopInMode (HIToolbox:x86_64+0x30ebb)
>     #11 0x7fffc6e10bf8 in ReceiveNextEventCommon (HIToolbox:x86_64+0x30bf8)
>     #12 0x7fffc6e10b25 in _BlockUntilNextEventMatchingListInModeWithFilter (HIToolbox:x86_64+0x30b25)
>     #13 0x7fffc53a5a53 in _DPSNextEvent (AppKit:x86_64+0x46a53)
>     #14 0x7fffc5b217ed in -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] (AppKit:x86_64+0x7c27ed)
>     #15 0x7fffc539a3da in -[NSApplication run] (AppKit:x86_64+0x3b3da)
>     #16 0x7fffc5364e0d in NSApplicationMain (AppKit:x86_64+0x5e0d)
>     #17 0x109f6e553 in main main.m:52
>     #18 0x7fffdd0a2234 in start (libdyld.dylib:x86_64+0x5234)
> ...
> 
>> Begin forwarded message:
>> 
>> From: John M McIntosh <johnmci at smalltalkconsulting.com <mailto:johnmci at smalltalkconsulting.com>>
>> Subject: Re: [Vm-dev] [Pharo-users] macOS VM builds with AddressSanitizer/LeakSanitizer
>> Date: 26 January 2019 at 01:04:30 GMT+1
>> To: Manuel Leuenberger <leuenberger at inf.unibe.ch <mailto:leuenberger at inf.unibe.ch>>
>> Reply-To: John M McIntosh <johnmci at smalltalkconsulting.com <mailto:johnmci at smalltalkconsulting.com>>
>> 
>> There is a branch in the source tree where I have a Xcode build for deployment of the vm on iOS and OS X.  Change the vm source  group folder to compile the cog stack or vm.
>> 
>> Although a year or two old you might be able to git merge it into the  current OS X build. You can then build the vm with Xcode settings and run instruments etc.
>> 
>> As Eliot points out you can also go in and alter the current make options for the cod line build 
>> 
>> ....
>> John M. McIntosh. Corporate Smalltalk Consulting Ltd https://www.linkedin.com/in/smalltalk <https://www.linkedin.com/in/smalltalk>
>> 
>> 
>> 
>> 
>> On Fri, Jan 25, 2019 at 06:04, Manuel Leuenberger <leuenberger at inf.unibe.ch <mailto:leuenberger at inf.unibe.ch>> wrote:
>>> 
>>> Hi Ben,
>>> 
>>> Thanks for the pointer, I subscribed to those two mailing lists as well.
>>> 
>>> Cheers,
>>> Manuel
>>> 
>>>> On 25 Jan 2019, at 14:25, Ben Coman <btc at openinworld.com <mailto:btc at openinworld.com>> wrote:
>>>> 
>>>> Hi Manuel,
>>>> 
>>>> This level question would be better handled on pharo-dev and vm-dev mail lists (forwarded a copy).  
>>>> http://lists.pharo.org/mailman/listinfo/pharo-dev_lists.pharo.org <http://lists.pharo.org/mailman/listinfo/pharo-dev_lists.pharo.org>
>>>> http://lists.squeakfoundation.org/mailman/listinfo/vm-dev <http://lists.squeakfoundation.org/mailman/listinfo/vm-dev>
>>>> 
>>>> On Fri, 25 Jan 2019 at 16:09, Manuel Leuenberger <leuenberger at inf.unibe.ch <mailto:leuenberger at inf.unibe.ch>> wrote:
>>>> Hi,
>>>> 
>>>> Anybody has experience building the VM (pharo.cog.spur) on macOS with custom compiler and flags?
>>>> 
>>>> 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.
>>>> 
>>>> 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?
>>>> 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?
>>>> 
>>>> 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.
>>>> 
>>>> Cheers,
>>>> Manuel
>>>> 
>>>> 
>>> 
>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20190128/5be616bb/attachment-0001.html>