CrashGenerationApp hangs instead of crashes

[GoogleCodeExporter]

I built (MSVC) and ran the CGA program (Vista).

I tried everything, but could not get it to actually crash. It always hung
until I closed the program hard.

Then I browsed the code and noticed it would try to write files to
c:\dumps, which did not exist.

So I created the dumps folder and it started working!

Original issue reported on code.google.com by harris...@gmail.com on 27 Feb 2009 at 2:56

[GoogleCodeExporter]

Thanks for the investigation.  Do you mind submitting a patch to create this
directory if it doesn't exist?

Original comment by neal...@gmail.com on 27 Feb 2009 at 10:25

[GoogleCodeExporter]

I normally wouldn't, but in this case, yes I do.  I don't know Win32 API, I use
QT+Boost, so I wouldn't know where to start.

But, what I *am* doing is writing a 'getting started' guide for the wiki.  I am
currently stuck at the link step, for some reason my app doesn't want to link 
with
the library.  Different #defines? I dunno.

So since I can't contribute a patch, perhaps I can contribute in another way.

While I have your attention, could you give me some pointers on how I'm 
supposed to
use an "external application" to catch the crashes?  Am I supposed to start the
external app at start up, and connect via the pipe, and make it wait for a 
dump-message ?

Documentation is really lacking, its hard to start using breakpad ...  if you 
can
fill me in, I'll put it in my wiki draft.

Original comment by harris...@gmail.com on 27 Feb 2009 at 10:54

[GoogleCodeExporter]

Related, I have a "getting started" guide for using the Linux code from another 
user
that I need to put on the wiki.

Original comment by ted.mielczarek on 28 Feb 2009 at 6:05

[GoogleCodeExporter]

here is what I would put on a wiki page if i had write access...

but first, some questions...
Is there any reason not to create an exception handler like so:

int main()
{
   ExceptionHandler handler(etc,etc,etc);
   DestructorCouldCrash troublesome_class;

   return 0;
}

compared to the "standard"
int main()
{
   ExceptionHandler * handler = new ExceptionHandler(etc,etc,etc);
   DestructorCouldCrash troublesome_class;

   delete handler;
   return 0;
}

I prefer the first, as it could potentially catch the troublesome_class's 
crash.  The 
second one would delete 'handler' before troublesome_class.

------------ now for the wiki content ------------------

Getting Started

This focuses on Windows and MSVC (2005).

Quickstart:
Retrieve the trunk from the svn repository.
Open up the MSVC Solution: src/client/windows/breakpad_client.sln
Build the Debug version.
Open up the MSVC Solution: 
src/client/windows/tests/crash_generation_app/crash_generation_app.sln
Build the Debug version.
Note: You could also build the other versions, eg Release, just be sure to 
build the 
same in both solutions.

Make a directory called c:\dumps

Run the executable: 
src/client/windows/tests/crash_generation_app/Debug/crash_generation_app.exe
In one, click Menu->Server->Start.  This is now the 'Server'.

Run the executable AGAIN (a second instance). This is now the 'Client'.
You should see a message like "Client connected" in the Server.
In the Client, click Menu->Client->Deref Zero

The client should crash, and you should see a message like "Client requested 
dump" in 
the server.

in c:\dumps you now have a .dmp file.
Open that in MSVC, like you would a Solution.
Then click 'Begin Debug', and it will zip to the place where it crashed.

That ends the demo project.

Now, to integrate it into your application...  again, specifically for MSVC 
projects.

First thing, if you do NOT have the "Treat wchar_t as Built-in Type 
(/Zc:wchar_t)" 
enabled (in Properties, Configuration Properties, C/C++, Language) then you 
need to 
change the Project Properties for all of BreakPad's projects to /Zc:wchar_t- 
(ie turn 
it off).   If you don't then Breakpad's methods that include wchar_t will not 
link 
(the method signatures/symbols will be different).

In your main() function (or equivalent), before your program does any real 
work, add 
the following:

// include Google-Breakpad (for windows)
#include <client/windows/handler/exception_handler.h>

int main() 
{
  etc etc

   static wstring prod = get_myapp_name();
   static wstring ver = get_myapp_version();
   static wstring subver = get_myapp_subversion();

   static int google_custom_count = 3;
   static google_breakpad::CustomInfoEntry google_custom_entries[] = {
      google_breakpad::CustomInfoEntry(L"prod", prod.c_str()),
       google_breakpad::CustomInfoEntry(L"ver", ver.c_str()),
       google_breakpad::CustomInfoEntry(L"subver", subver.c_str()),
   };

   google_breakpad::CustomClientInfo custom_info = {google_custom_entries, 
google_custom_count};

google_breakpad::ExceptionHandler * google_pad = new 
google_breakpad::ExceptionHandler(
         L"C:\\dumps\\",   // dump path
         NULL,             // filter callback
         NULL,             // MinidumpCallback,
         NULL,             // callback context
         google_breakpad::ExceptionHandler::HANDLER_ALL, // handler types
         MiniDumpNormal, // or for a larger dump: MiniDumpWithFullMemory
         NULL,             // pipe name
         &custom_info);    // custom info

etc etc
}

If you define MinidumpCallback, the signature is like so:
bool MinidumpCallback(const wchar_t* dump_path,
                     const wchar_t* minidump_id,
                     void* context,
                     EXCEPTION_POINTERS* exinfo,
                     MDRawAssertionInfo* assertion,
                     bool succeeded);

The callback is the point where you could spawn another program that tells the 
user 
that the program has crashed etc.   I have not investigated doing that bit yet, 
I 
would love to get some help on this topic.

Compile it as either Debug OR as RelWithDebInfo.

The above code will generate dumps in the c:\dumps folder.  MAKE SURE the 
folder is 
created first, otherwise your app will probably hang rather than finish 
crashing.  
Its enough to get you going.

Now you have crash-dumps.  Next, you receive a dump via email/web from a user.
Open up a fresh MS Visual C++ and then go file->open and open the dump as if it 
were 
a project.
IF your source code and .pdb files are in the same location as when you 
compiled this 
version, it'll just work.

If you want to have multiple product versions out there (and in reality, who 
doesn't 
have such a situation), then you will need to either keep all the old code and 
.pdb 
files around zipped up for future reference (the easy way).

Or, the "easier" way is to use symstore.exe to catalog and store your .pdb 
files.  
Then you configure your MSVC (tools->options->debugging->symbols) to refer to 
the 
symstore's root directory.  This works well, and if you need the symbols for 
Microsoft dlls, you can use the same technique to refer to microsoft's 
webserver 
(google for info).
HOWEVER it does not help you store your source code.  Mozilla figured out a way 
to do 
it with CVS servers etc, but it looks like a lot of work.  
AND it also doesn't help you delete old .pdb files in the future, so your 
symbols 
storage may grow and grow and grow...  Old .pdb files can be deleted from 
symstore 
but it requires you manually checking index files etc.

For small software groups, it may be easier just to zip up all the binaries, 
.pdbs 
and source files and keep them aside for the future.

I would like to expand on this information, I see no reason why everyone can't 
have 
this set up out-of-the-box.

Original comment by harris...@gmail.com on 3 Mar 2009 at 9:21

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

> Thanks for the investigation.  Do you mind submitting a patch to create this
> directory if it doesn't exist?

https://breakpad.appspot.com/1134002/

Original comment by b152fee4...@gmail.com on 7 Feb 2014 at 2:45

[GoogleCodeExporter]

Should be fixed by r1348

Original comment by b152fee4...@gmail.com on 14 Jul 2014 at 12:23

[GoogleCodeExporter]

Original comment by thestig@chromium.org on 14 Jul 2014 at 7:01

• Changed state: Fixed