TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Faster Backtraces for Native Applications

46 点作者 sbahra超过 10 年前

5 条评论

js2超过 10 年前
There are a couple excellent reporting frameworks, PLCR and breakpad. What&#x27;s sorely missing is a really good backend.<p>There&#x27;s commercial options in crittercism, crashlytics, bugsense, and hockeyapp, but these are either mobile only or subpar in what they provide.<p>And there&#x27;s really not any decent opensource backend. Mozilla Socorro is ugly and tied to their infrastructure in many ways. The closest I can think of is Sentry... but it&#x27;s primarily designed for handling tracebacks from backend apps. (Oh, I guess there&#x27;s also squash.io)<p>Anyway, I&#x27;m curious to see what you&#x27;re building on the backend, and if you intend to opensource it in addition to what you plan to offer commercially.
评论 #8333300 未加载
BruceM超过 10 年前
It would be useful to know the commands that were run for gdb, lldb, and so on to do our own comparisons.<p>I also have need of being able to run a program under a harness that, should it crash, lets me get the stack and other details. Bonus points if I get to set up my own code to help decode and pretty print my own data types. But for my purposes, that needs to be something under a more open license which is why I&#x27;ve been working with LLDB to date.
sbahra超过 10 年前
Appreciate any feedback to the early access core software and we&#x27;re all ears on feature requests. Let us know if you encounter any sub-optimal output and we&#x27;ll fix it, hope some of you guys find this useful and live a more manageable life :-P
评论 #8332875 未加载
kevingadd超过 10 年前
So something I don&#x27;t understand that doesn&#x27;t seem to have an explanation in the linked article:<p>Why does the speed of backtrace generation matter for handling&#x2F;reporting crashes? If the process is dead, I don&#x27;t see how it taking an extra 50ms (if that) to tear down makes a big difference - especially since crashes should be an exceptional case, not a common one.<p>Is the optimization here actually intended to enable more accurate, less intrusive realtime profiling, or something like that? Otherwise I&#x27;m having a hard time understanding how optimizing for wall-clock time here is actually a useful exercise (even if it is very interesting)
评论 #8333285 未加载
评论 #8334249 未加载
sbahra超过 10 年前
Thanks for all the feedback people. We&#x27;ve released a new version with robust handling of attachment failures, additional DWARF features and performance improvements (up to 35% on targets with lots of shared objects).