There was definitely a massive problem with libunwind & JIT frames, which made it unsuitable for windows and os x
Another issue was that libunwind made traces ten times bigger, for no immediate benefit other than "it might be useful some day" and added complexity. On linux I was getting ~7% of stack that was not correctly rebuilt. This is not an issue if you assume that the 7% is statistically distributed evenly, but I heavily doubt that is the case (and there is no way to check) which made us build a more robust approach. I think I would like the following properties: * everything works without libunwind, native=True raises an exception * with libunwind, we don't loose frames in python just because libunwind is unable to reconstruct the stack * we don't pay 10x storage just because there is an option to want native frames Can we have that? PS. How does the new approach works? If it always uses libunwind and ditches the original approach I'm very much -1 Cheers, fijal On Wed, Feb 15, 2017 at 12:10 PM, Richard Plangger <planri...@gmail.com> wrote: > Hi, > >> Avoiding to make it a hard dependency would be a good idea. Also, >> libunwind is a hack that showed problems when vmprof previously >> supported C frames, and it was removed for that reason. Maybe you >> should give a word about why re-enabling C frames with libunwind looks >> ok now? > > Can you elaborate on that? My understanding is that Maciej at some point > complained that there are some issues and removed that feature (which > Antonio was not particularly happy about). I never learned the issues. > One complaint I remember (should be on IRC logs some place): > > It was along the lines: "... some times libunwind returns garbage ..." > > Speaking from my experience during the development: > > I have not seen a C stack trace that is totally implausible (even though > I thought so, but I turned out to be some other error). It was very hard > to get the trampoline right and it was also not easy to get the stack > walking right (considering it should work for all platform combinations). > > There are several cases where libunwind could say: 'hey, unsure what to > do, cannot rebuild the stack' and those cases now lead to skipping the > sample in the signal. > > I'm happy to accept the fact that 'libunwind is garbage/hack/...' if > somebody proves that. So if anyone has some insight on that, please > speak up. There are alternatives like: use libbacktrace from gcc (which > is already included in vmprof now). > > Cheers, > Richard > > > > > > _______________________________________________ > pypy-dev mailing list > pypy-dev@python.org > https://mail.python.org/mailman/listinfo/pypy-dev _______________________________________________ pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev
