Have you ever had an
assert get triggered only to result in a useless core dump with missing variable information or an invalid callstack? Common factors that go into selecting a C or C++ compiler are: availability, correctness, compilation speed and application performance. A factor that is often neglected is debug information quality, which symbolic debuggers use to reconcile application executable state to the source-code form that is familiar to most software engineers. When production builds of an application fail, the level of access to program state directly impacts the ability for a software engineer to investigate and fix a bug. If a compiler has optimized out a variable or is unable to express to a symbolic debugger how to reconstruct the value of a variable, the engineer’s investigation process is significantly impacted. Either the engineer has to attempt to recreate the problem, iterate through speculative fixes or attempt to perform prohibitively expensive debugging, such as reconstructing program state through executable code analysis.
Debug information quality is in fact not proportionally related to the quality of the generated executable code and wildly varies from compiler to compiler. This blog post compares debug information quality between two popular compilers: gcc and clang. In this blog post, we will introduce the topic of optimization and highlight examples of their impact on debuggability. This blog post is part of a longer series, in the next blog post we’ll do finer grained analysis directly comparing
clang in real world and synthetic programs.
A new integration wizard has just been released, allowing you to more easily integrate your applications into Backtrace. The wizard guides you through the steps of creating a new project, integrating an application and introduces you to other value-add features such as workflow integrations. Look below to see a live demo of how we process firefox crash dumps with symbolification in a matter of seconds.
Most users of Backtrace automatically submit error and crash reports, however some users just want to manually upload a few dumps from environments where automated submission is turned off. It is now possible to do this directly through our web console with just a few clicks. Simply select “Trace Upload” menu item to upload one or more minidumps or Backtrace snapshots for processing. It is also possible to do this from the command-line with the morgue tool. Read more to see a video of this functionality in action.
Backtrace now includes a completely new storage and indexing subsystem that enables engineers to slice and dice hundreds of attributes in real-time easily so they can better triage and investigate errors across their ecosystem, all from the comfort of their command-line environment. When an application crash occurs, there are hundreds of data points that may be relevant to the fault. This can range from application-specific attributes, such as version or request type to crucial fault data such as crashing address, fault type, garbage collector statistics to environment data such as system memory utilization.
Read on to learn more how you can interact with Backtrace from the command line for crash report and error investigation.
We are happy to announce the beta release of the Backtrace web-based inspector. Seamlessly integrated into the Backtrace Console, you will now be able to view detailed application state captured at the time of error. This information includes all threads (and goroutines for the Gophers), variables, memory allocation details, annotations, pretty-printed data structures, and more. Read More