On Feb 24, 2015, at 3:10 PM, Sylvain Galineau <galin...@adobe.com> wrote:
> I’ve recently found myself in the following situation while debugging > WebKit: the debugger (Xcode) would hit a breakpoint, I would place a new > breakpoint in a method up the current call stack, re-run my test and > then…nothing. The new breakpoint would never be hit though the original > one still was and I could still see that method on the call stack with my > breakpoint in it. > > For instance, I would set a breakpoint in FontCascade::width(), see > RenderSVGText::layout() on the call stack then set a breakpoint in the > latter. I’d try my test again and never break into > RenderSVGText::layout(). > > I verified I was using a debug build, rebuilt from scratch, tried > command-line LLDB, stood on my head, no luck. > > Until I added: > > settings set target.inline-breakpoint-strategy always > > > in ~/.lldbinit. > > I’m glad it works - yay breakpoints - but am not quite sure why this bit > of magic is needed. Does anyone else use this/know why it helps? This is a known issue (tracked internally as rdar://problem/16829492). It’s exacerbated by our “all in one” .cpp files (e.g. RenderSVGAllInOne.cpp) which are required to get around linking size issues iirc. Simon _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
