<div dir="ltr">So it seems this was due to including the source file that contains operator new and delete in the framework instead of the app.<div><br></div><div>Moving that file into the app layer appears to have solved the problem.</div><div><br></div><div>This comment here, ultimately provided me with the information I needed: <a href="https://stackoverflow.com/questions/8186018/how-to-properly-replace-global-new-delete-operators#comment10059105_8186116">https://stackoverflow.com/questions/8186018/how-to-properly-replace-global-new-delete-operators#comment10059105_8186116</a></div><div><br></div><div>Cheers,</div><div>James</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 22 March 2018 at 22:00, James Robertson <span dir="ltr"><<a href="mailto:james@movi.ai" target="_blank">james@movi.ai</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Eric,<div><br></div><div>I'm trying to find the time to figure out a repo case for you to take a look at. Just got some xcode shenanigans to figure out. :)</div><div><br></div><div><br></div><div>Our set up is as follows:</div><div><br></div><div>Static lib written in C++. Our memory manager exists in here.</div><div>Framework (shared library) with mixed Swift and C++ code. The global new/delete operators are compiled here, and the static lib is linked in as well.</div><div>App written in Swift.</div><div><br></div><div><br></div><div>As far as the callstack is concerned, it's basically this:</div><div><br></div><div><div>#0 __pthread_kill ()</div><div>#1 pthread_kill$VARIANT$mp ()</div><div>#2 abort ()</div><div>#3 free ()</div><div>#4 std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::~basic_string()</div><div><br></div><div>#5 The following five stack frames are in our C++ code...</div><div>#6</div><div>#7</div><div>#8</div><div>#9</div><div><br></div><div>#10 These four frames are Swift code in our framework...</div><div>#11</div><div>#12 <br></div><div>#13</div><div><br></div><div>#14 -[UIApplication _<wbr>handleDelegateCallbacksWithOpt<wbr>ions:isSuspended:restoreState:<wbr>]</div><div>#15 -[UIApplication _<wbr>callInitializationDelegatesFor<wbr>MainScene:transitionContext:]</div><div>#16 -[UIApplication _runWithMainScene:<wbr>transitionContext:completion:]</div><div>#17 __111-[__<wbr>UICanvasLifecycleMonitor_<wbr>Compatability _scheduleFirstCommitForScene:<wbr>transition:firstActivation:<wbr>completion:]_block_invoke</div><div>#18 +[_UICanvas _<wbr>enqueuePostSettingUpdateTransa<wbr>ctionBlock:]</div><div>#19 -[__UICanvasLifecycleMonitor_<wbr>Compatability _scheduleFirstCommitForScene:<wbr>transition:firstActivation:<wbr>completion:]</div><div>#20 -[__UICanvasLifecycleMonitor_<wbr>Compatability activateEventsOnly:<wbr>withContext:completion:]</div><div>#21 __82-[_UIApplicationCanvas _<wbr>transitionLifecycleStateWithTr<wbr>ansitionContext:completion:]_<wbr>block_invoke</div><div>#22 -[_UIApplicationCanvas _<wbr>transitionLifecycleStateWithTr<wbr>ansitionContext:completion:]</div><div>#23 __125-[_<wbr>UICanvasLifecycleSettingsDiffA<wbr>ction performActionsForCanvas:<wbr>withUpdatedScene:settingsDiff:<wbr>fromSettings:<wbr>transitionContext:]_block_<wbr>invoke</div><div>#24 _<wbr>performActionsWithDelayForTran<wbr>sitionContext</div><div>#25 -[_<wbr>UICanvasLifecycleSettingsDiffA<wbr>ction performActionsForCanvas:<wbr>withUpdatedScene:settingsDiff:<wbr>fromSettings:<wbr>transitionContext:]</div><div>#26 -[_UICanvas scene:didUpdateWithDiff:<wbr>transitionContext:completion:]</div><div>#27 -[UIApplication workspace:didCreateScene:<wbr>withTransitionContext:<wbr>completion:]</div><div>#28 -[<wbr>UIApplicationSceneClientAgent scene:didInitializeWithEvent:<wbr>completion:]</div><div>#29 -[FBSSceneImpl _<wbr>didCreateWithTransitionContext<wbr>:completion:]</div><div>#30 __56-[FBSWorkspace client:handleCreateScene:<wbr>withCompletion:]_block_invoke_<wbr>2</div><div>#31 _dispatch_client_callout</div><div>#32 _dispatch_block_invoke_direct</div><div>#33 __FBSSERIALQUEUE_IS_CALLING_<wbr>OUT_TO_A_BLOCK__</div><div>#34 -[FBSSerialQueue _performNext]</div><div>#35 -[FBSSerialQueue _performNextFromRunLoopSource]</div><div>#36 __CFRUNLOOP_IS_CALLING_OUT_TO_<wbr>A_SOURCE0_PERFORM_FUNCTION__</div><div>#37 __CFRunLoopDoSource0</div><div>#38 __CFRunLoopDoSources0</div><div>#39 __CFRunLoopRun</div><div>#40 CFRunLoopRunSpecific</div><div>#41 GSEventRunModal</div><div>#42 UIApplicationMain</div><div>#43 main</div><div>#44 start<br></div></div><div><br></div><div>Nothing overly interesting to look at. As I mentioned before, this happens during application initialisation.</div><div><br></div><div><br></div><div>The output window in xcode simply has the following message:</div><div><br></div><div>malloc: *** error for objectt 0x1051bc0c0: pointer being freed was not allocated</div><div><br></div><div><br></div><div>Which is partially correct. It's a 176 byte memory block allocated by my small block allocator. (I just managed to track it down.)</div><div><br></div><div><br></div><div>I don't think the optimiser has anything to do with this. This is happening in debug builds.</div><div><br></div><div>It's smells like a compiler bug to me. As I mentioned, the same code works fine on both MacOS, Windows, and the iOS simulator (which basically will compile to x86), so I would presume it's ARM specific - but that's merely a guess by me here.</div><div><br></div><div>Cheers,</div><div>James</div><div><div class="h5"><div><br></div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On 22 March 2018 at 05:31, Eric Fiselier <span dir="ltr"><<a href="mailto:eric@efcs.ca" target="_blank">eric@efcs.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra">There is no way to disable __builtin_operator_new/delete or prevent libc++ from using it.</div><div class="gmail_extra"><br></div><div class="gmail_extra">I would be interested to get some more details about your particular case. Ideally a reproducer</div><div class="gmail_extra">I could play with. Or at least provide some sort of stack trace and error log.</div><div class="gmail_extra"><br></div><div class="gmail_extra">I'm not too familiar with the optimization aspects of __builtin_operator_new/delete, but the behavior</div><div class="gmail_extra">you're observing sounds like a bug. Either in LLVM/Clang/libc++ or within your build. My suspicion</div><div class="gmail_extra">is that an ODR violation is involved.</div><div class="gmail_extra"><br></div><div class="gmail_extra">/Eric</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="m_6971808967745970554gmail-m_3484457522145625629gmail-m_-714283436289134295h5">On Wed, Mar 21, 2018 at 4:43 PM, James Robertson via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div class="m_6971808967745970554gmail-m_3484457522145625629gmail-m_-714283436289134295h5"><div dir="ltr"><div>Hi,</div><div><br></div>I'm trying to get my own global operator new/delete calls working that my memory manager plugs into.<div><br></div><div>This code is working fine on MacOS (clang) and Windows (Visual Studio), but on iOS I have a third party library (lohmann json) returning a std::string object which appears to have been allocated through my ::operator new function (I.e., my memory manager) but is being deleted through __builtin_operator_delete. Which just results in a crash almost immediately after the app starts.</div><div><br></div><div>So how do I disable these particular builtin functions?</div><div><br></div><div>Cheers,</div><div>James</div><div><br></div></div>
<br></div></div>______________________________<wbr>_________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-dev</a><br>
<br></blockquote></div><br></div></div>
</blockquote></div><br></div></div></div></div>
</blockquote></div><br></div>