[Lldb-commits] [PATCH] D86417: [lldb] do not propagate eTrapHandlerFrame repeatedly

llunak abandoned this revision. llunak added a comment. Funny coincidence, the ctor has been broken for 5 years and that commit introducing my problem has been there for a year. Ok, closing, thank you for your help. Repository: rLLDB LLDB CHANGES SINCE LAST ACTION

[Lldb-commits] [PATCH] D86417: [lldb] do not propagate eTrapHandlerFrame repeatedly

jasonmolenda added a comment. Hahaha I remember looking at this constructor and expecting to find an uninitialized ivar, but it was initialized correctly and I went to look for another place where the bug might be. I think I see why there's some confusion -- this change landed Thrusday:

[Lldb-commits] [PATCH] D86417: [lldb] do not propagate eTrapHandlerFrame repeatedly

llunak added a comment. No, everything's fine :). See the updated patch. The UnwindPlan object already enters x86AssemblyInspectionEngine::AugmentUnwindPlanFromCallSite() with the lazybool uninitialized and fixing that fixes everything: (lldb) bt * thread #1, name = 'a.out', stop reason =

[Lldb-commits] [PATCH] D86417: [lldb] do not propagate eTrapHandlerFrame repeatedly

jasonmolenda added a comment. Ah, so we've still got a bug in x86AssemblyInspectionEngine::AugmentUnwindPlanFromCallSite somehow for abort(). This method takes an UnwindPlan from eh_frame instructions (which says it is not a trap handler - correct), and adds some epilogue unwind rows at the

[Lldb-commits] [PATCH] D85705: Add a "Trace" plug-in to LLDB to add process trace support in stages.

wallace updated this revision to Diff 288788. wallace added a comment. - Removed whitespace only changes. - Simplified the way a SettingsParser is created, now there's no need to passinga a pointer around. - Fixed the forward declaration in lldb-private-interfaces. This should address all

[Lldb-commits] [PATCH] D86417: [lldb] do not propagate eTrapHandlerFrame repeatedly

llunak updated this revision to Diff 288780. llunak edited the summary of this revision. llunak added a comment. And it indeed was suspicious. 3fd917d8860e9bdcabc14c536da4377307906be0 didn't update the UnwindPlan copy ctor to copy the field. This patch fixes the problem even without your

[Lldb-commits] [PATCH] D86417: [lldb] do not propagate eTrapHandlerFrame repeatedly

llunak added a comment. In D86417#2239062 , @JosephTremoulet wrote: > and let me know how that goes? I don't have a linux system here to try it > on, but I have a feeling this may fix the problem you're seeing. Yes, it fixes my problem. However (if