dump_syms.exe

[Will Stokes]

You may recall I wrote earlier about trying to use breakpad with
MinGW. I've since then ported my app to use the MSVC compiler,
specifically Visual Studio Expression 2008 (I found I couldn't get
breakpad to compile against VS2010). I have an exception handler now
linked into my code and all is going well except for one basic
problem: I can't create symbol files using dump_syms.exe.

-I've compiled my app with -Zi which results in appName.pdb being
created in addition to appName.exe
-I tried running google-breakpad\src\tools\windows\binaries
\dump_syms.exe.

If I run it without arguments I get:

Usage: dump_syms.exe <file.[pdb|exe|dll]>

So far so good. But then if I run it and give it my pdb file I get:

dump_syms.exe appName.pdb
CoCreateInstance CLSID_DiaSource failed (msdia80.dll unregistered?)
Open failed

Passing it appName.exe produces a similar error message. What is
msdia80.dll? I notice I have a copy of msdia90.dll installed with MSVC
2008. I tried to compile dump_syms myself but ran into include errors
with:

c:\programming\libs\src\google-breakpad\src\common\windows
\pdb_source_line_writer.h(36) : fatal error C1083: Cannot open include
file: 'atlcomcli.h': No such file or directory

c:\programming\libs\src\google-breakpad\src\common\windows
\pdb_source_line_writer.cc(30) : fatal error C1083: Cannot open
include file: 'atlbase.h': No such file or directory

I'm at a total loss. Dumping symbols on the Mac was breeze so having
trouble with this last step is quite unexpected...

-Will

[Ted Mielczarek]

On Wed, Aug 11, 2010 at 12:52 PM, Will Stokes <wst...@gmail.com> wrote:
> So far so good. But then if I run it and give it my pdb file I get:
>
> dump_syms.exe appName.pdb
> CoCreateInstance CLSID_DiaSource failed (msdia80.dll unregistered?)
> Open failed
>
> Passing it appName.exe produces a similar error message. What is
> msdia80.dll? I notice I have a copy of msdia90.dll installed with MSVC
> 2008. I tried to compile dump_syms myself but ran into include errors
> with:
>
> c:\programming\libs\src\google-breakpad\src\common\windows
> \pdb_source_line_writer.h(36) : fatal error C1083: Cannot open include
> file: 'atlcomcli.h': No such file or directory
>
> c:\programming\libs\src\google-breakpad\src\common\windows
> \pdb_source_line_writer.cc(30) : fatal error C1083: Cannot open
> include file: 'atlbase.h': No such file or directory
>
> I'm at a total loss. Dumping symbols on the Mac was breeze so having
> trouble with this last step is quite unexpected...

dump_syms on Windows is a bit of a pain. It requires the DIA SDK to
read information out of PDB files. Unfortunately it requires some
headers (I think you're seeing ATL there) that aren't provided with
Visual C++ Express editions, so we provide pre-built binaries. Doubly
unfortunately, the pre-built binaries are tied to a specific version
of Visual C++, since they require the DIA DLL (msdia80.dll in this
case) to be installed. We could probably provide pre-built binaries
for both Visual C++ 2005 and 2008 which would solve your problem. If
you'd like, I can send you a link to a pre-built dump_syms.exe for
VC2008.

-Ted

[Will Stokes]

Ah ha, I figured as much.

-Yes, I'd *very* much appreciate of dump_syms.exe compiled for MSVC2008.

-I also suggest it be checked into SVN so that others can overcome
this issue more easily in the future.

-I suggest a note be made somewhere that breakpad isn't compatible
with MSVC2010 yet (I tried compiling it against MSVC2010 and it failed
but I didn't note what the problem was).

-It would be nice if dump_syms could be made compatible with the
express versions of visual studio down the road. Is there any reason
in particular ATL needs to be used?

-Finally, I found it odd that on the Mac when using breakpad you get
the report crash dialog for free (integrating the handler into Mac was
trivial), where as on Windows all you get a .dmp file on disk and it's
up to you to setup a dialog and then setup communication with a
soccero server. Out of curiosity, are there plans to make integrating
breakpd into Windows apps as easy as Mac apps eventually?

Sorry for all the questions/requests. I'm quite excited to soon have
pretty crash reports with human readable call stacks across both Mac
and Windows without distributing huge binaries with debugging symbols.

-Will

> --
> You received this message because you are subscribed to the Google Groups "google-breakpad-dev" group.
> To post to this group, send email to google-br...@googlegroups.com.
> To unsubscribe from this group, send email to google-breakpad...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/google-breakpad-dev?hl=en.
>
>