<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 _handleDelegateCallbacksWithOptions:isSuspended:restoreState:]</div><div>#15 -[UIApplication _callInitializationDelegatesForMainScene:transitionContext:]</div><div>#16 -[UIApplication _runWithMainScene:transitionContext:completion:]</div><div>#17 __111-[__UICanvasLifecycleMonitor_Compatability _scheduleFirstCommitForScene:transition:firstActivation:completion:]_block_invoke</div><div>#18 +[_UICanvas _enqueuePostSettingUpdateTransactionBlock:]</div><div>#19 -[__UICanvasLifecycleMonitor_Compatability _scheduleFirstCommitForScene:transition:firstActivation:completion:]</div><div>#20 -[__UICanvasLifecycleMonitor_Compatability activateEventsOnly:withContext:completion:]</div><div>#21 __82-[_UIApplicationCanvas _transitionLifecycleStateWithTransitionContext:completion:]_block_invoke</div><div>#22 -[_UIApplicationCanvas _transitionLifecycleStateWithTransitionContext:completion:]</div><div>#23 __125-[_UICanvasLifecycleSettingsDiffAction performActionsForCanvas:withUpdatedScene:settingsDiff:fromSettings:transitionContext:]_block_invoke</div><div>#24 _performActionsWithDelayForTransitionContext</div><div>#25 -[_UICanvasLifecycleSettingsDiffAction performActionsForCanvas:withUpdatedScene:settingsDiff:fromSettings:transitionContext:]</div><div>#26 -[_UICanvas scene:didUpdateWithDiff:transitionContext:completion:]</div><div>#27 -[UIApplication workspace:didCreateScene:withTransitionContext:completion:]</div><div>#28 -[UIApplicationSceneClientAgent scene:didInitializeWithEvent:completion:]</div><div>#29 -[FBSSceneImpl _didCreateWithTransitionContext:completion:]</div><div>#30 __56-[FBSWorkspace client:handleCreateScene:withCompletion:]_block_invoke_2</div><div>#31 _dispatch_client_callout</div><div>#32 _dispatch_block_invoke_direct</div><div>#33 __FBSSERIALQUEUE_IS_CALLING_OUT_TO_A_BLOCK__</div><div>#34 -[FBSSerialQueue _performNext]</div><div>#35 -[FBSSerialQueue _performNextFromRunLoopSource]</div><div>#36 __CFRUNLOOP_IS_CALLING_OUT_TO_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><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="gmail-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="gmail-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>