Thanks for the great lib, it has helped me debug several crashes already.
One thing related to windows is still unclear to me - is it possible to have a minidump produced by a "release binary" (no debug symbols) of my app produce a usable stack trace ? So far, I have only been able to get usable stack traces using windows debug build of the app.
On mac+linux I run strip on the binaries after generating the symbols and a proper stack trace can be generated. How can this be handled on windows?
On Wed, Oct 10, 2012 at 10:18 AM, tp <lete...@gmail.com> wrote:
> Hi,
> Thanks for the great lib, it has helped me debug several crashes already.
> One thing related to windows is still unclear to me - is it possible to have
> a minidump produced by a "release binary" (no debug symbols) of my app
> produce a usable stack trace ? So far, I have only been able to get usable
> stack traces using windows debug build of the app.
> On mac+linux I run strip on the binaries after generating the symbols and a
> proper stack trace can be generated. How can this be handled on windows?
Hi Teemu,
Generally what you need to do is run the dump_syms tool
(src/tools/windows/dump_syms in the Breakpad tree, or
src/tools/windows/binaries/dump_syms.exe for a pre-built binary) on
each PDB file from your application. This will produce output on
stdout in Breakpad's symbol file format[1]. We don't have good
documentation for this process on Windows currently, but the Linux
documentation[2] is virtually the same process and should show you
what you need to do to dump the symbols and get them used in minidump
processing.
I have read the documentation and actually we already have the whole symbol generation automated and working. We're using CMake and the only problematic build was windows build with "Release" build type; the symbol generation was failing due to missing PDB files, as those are not generated for CMake's "Release" build type. I worked around this by using CMake's "RelWithDebInfo" build type for release windows builds (it compiles with optimizations enabled and generates PDBs), and now we finally get proper stack traces for all platforms. And no longer need to distribute large and non-optimized windows binaries to crash reporting working. Thanks again.
teemu
keskiviikko, 10. lokakuuta 2012 17.29.18 UTC+3 Ted Mielczarek kirjoitti:
> On Wed, Oct 10, 2012 at 10:18 AM, tp <let...@gmail.com <javascript:>> > wrote: > > Hi,
> > Thanks for the great lib, it has helped me debug several crashes > already.
> > One thing related to windows is still unclear to me - is it possible to > have > > a minidump produced by a "release binary" (no debug symbols) of my app > > produce a usable stack trace ? So far, I have only been able to get > usable > > stack traces using windows debug build of the app.
> > On mac+linux I run strip on the binaries after generating the symbols > and a > > proper stack trace can be generated. How can this be handled on windows?
> Hi Teemu,
> Generally what you need to do is run the dump_syms tool > (src/tools/windows/dump_syms in the Breakpad tree, or > src/tools/windows/binaries/dump_syms.exe for a pre-built binary) on > each PDB file from your application. This will produce output on > stdout in Breakpad's symbol file format[1]. We don't have good > documentation for this process on Windows currently, but the Linux > documentation[2] is virtually the same process and should show you > what you need to do to dump the symbols and get them used in minidump > processing.
That's unfortunate that CMake's release builds default to not generating symbols. IMHO there is no excuse for not always generating (and archiving) symbols. If done correctly the symbol generation on Windows should not affect the generated code at all. The .exe and .dll files should get 50-100 bytes larger due to the debug link that is inserted, but the actual code bytes should be unchanged. It's worth verifying this since some release-with-symbols configurations will forget to specify /opt:ref and /opt:icf which makes builds with symbols a lot larger, since for some reason the /DEBUG linker switch disables /opt:ref and /opt:icf.
On Wednesday, October 10, 2012 12:03:05 PM UTC-7, tp wrote: > Hi,
> I have read the documentation and actually we already have the whole > symbol generation automated and working. We're using CMake and the only > problematic build was windows build with "Release" build type; the symbol > generation was failing due to missing PDB files, as those are not generated > for CMake's "Release" build type. I worked around this by using CMake's > "RelWithDebInfo" build type for release windows builds (it compiles with > optimizations enabled and generates PDBs), and now we finally get proper > stack traces for all platforms. And no longer need to distribute large and > non-optimized windows binaries to crash reporting working. Thanks again.
> teemu
> keskiviikko, 10. lokakuuta 2012 17.29.18 UTC+3 Ted Mielczarek kirjoitti:
>> On Wed, Oct 10, 2012 at 10:18 AM, tp <let...@gmail.com> wrote: >> > Hi,
>> > Thanks for the great lib, it has helped me debug several crashes >> already.
>> > One thing related to windows is still unclear to me - is it possible to >> have >> > a minidump produced by a "release binary" (no debug symbols) of my app >> > produce a usable stack trace ? So far, I have only been able to get >> usable >> > stack traces using windows debug build of the app.
>> > On mac+linux I run strip on the binaries after generating the symbols >> and a >> > proper stack trace can be generated. How can this be handled on >> windows?
>> Hi Teemu,
>> Generally what you need to do is run the dump_syms tool >> (src/tools/windows/dump_syms in the Breakpad tree, or >> src/tools/windows/binaries/dump_syms.exe for a pre-built binary) on >> each PDB file from your application. This will produce output on >> stdout in Breakpad's symbol file format[1]. We don't have good >> documentation for this process on Windows currently, but the Linux >> documentation[2] is virtually the same process and should show you >> what you need to do to dump the symbols and get them used in minidump >> processing.
