We've got the types we need to support ppc minidumps now.  Even before the
OS X-specific stuff is ready (we may need to add or change a few
OS-specific structures), we can get the processor-side minidump reader
prepared to read ppc state.

It'll be more flexible for library consumers if the report_id is a string
rather than a u_int64_t.  Callers can still use 64-bit ints if they want,
but also have the flexibility to use longer ids.

MSVC turns on /Oy (frame pointer omission) at /O1 and /O2.  Frame pointer
omission, oy!  The present StackwalkerX86 relies on %ebp as the frame
pointer and expects to be able to dereference %ebp to find the caller's
frame pointer.  stackwalker_x86.cc contains this comment:

  // If there is no frame pointer, determining the layout of the stack is
  // considerably more difficult, requiring debugging information.  This
  // stackwalker doesn't attempt to solve that problem (at this point).

Resolving this bug will require three things:

 - PDBSourceLineWriter (the dump_syms tool) will need to get stack frame
   data out of pdb files and write what we need in its output.  We can
   get this data from the pdb's FrameData table, which we access using
   the DIA IDiaFrameData and IDiaEnumFrameData APIs.
 - SourceLineResolver needs to interpret this information and make it
   available.  We can't use a RangeMap for this because of the way that
   the data is organized in a pdb: stack frame information is logically
   keyed by program counter, but blocks of stack frame information
   may enclose other blocks, possibly with identical start or end
   addresses.  (This supports different uses of the stack between
   different parts of the same function, when dictated by control
   structures or compiler optimizations.)  SourceLineResolver may want
   to be renamed.
 - StackwalkerX86 needs to find which module an instruction is in
   (which will require a slight reorganization between Stackwalker
   and the concrete StackwalkerX86) and pull stack frame information
   for an instruction out of that module's debugging information.
   When this information is available, it should be used to locate
   the position of the next stack frame.  When it is not available,
   StackwalkerX86 should continue to use %ebp as the frame pointer.

One open question is exactly how much stack frame information we need to
pull out of the pdb.  We have access to the sizes used on the stack for
locals, saved registers, and parameters.  We also have access to a "program
string," which is something we can feed to a stack machine along with a few
known bits of context and get some information out of at stackwalking time.
   The former is easy and correct when the compiler doesn't push extra
temps onto the stack outside of what we're told it's done in the debugging
info. If additional temps are pushed (i.e. if IDiaFrameData::get_maxStack
returns nonzero), it'll be wrong, though.  I haven't seen nonzero values
for maxStack yet, but I'm building a Firefox optimized build with vc8 now
to see if any turn up there.

Per our discussion, we are not going to provide reporting and symbol server
implementation. This CL removes files under java directory.

Initial import of a few Java files, asking for a code review.

Add servlet-api.jar, which was from Apache/Tomcat project. 
A servlet api is necessary to compile airbag/java/common. Although the
runtime library can be other implementations.

The binary file should have the same license (Apache 2.0) as Airbag.

The binary file is skipped by 'svn diff'.

SourceLineResolver presently uses its own memory map (MemAddrMap), but #6
introduced a more generic RangeMap.  We can migrate SourceLineResolver to
the new class.

One caveat: currently, MemAddrMap and the file format used by
SourceLineResolver and the Windows dump_syms tool don't take the size/high
address of a range into account, where RangeMap does.

This will be the first step toward processor-side ppc support.

I've written the x86-specific parts of a stackwalker.  I can't provide a
clean patch yet because it depends on and changes parts of #6 (pending).

I've gotten the minidump reader ready for import.  It's tremendous.

- The patch contains only the change to Makefile.am; run automake before
  testing or checking in.
- I couldn't figure out how to get script-based unit tests to run within
  this framework.  "make check" runs "make MinidumpDump_unittest" which
  does nothing because the script already exists, but doesn't include
  MinidumpDump_unittest in the list of tests to run.  If you add it to
  $(TESTS), automake sets up rules to build it from .c source which of
  course does not exist.  So the test is here, but it's never run.
- This isn't done, but it works and the interfaces are roughly where I'd
  like them to be, so it's suitable to get into the tree.

bryner, when you get a chance, could you give me whatever type of review is
appropriate for a huge import?

It does not reproduce!

We should simplily the API for processing minidumps by getting rid of the
mostly-unused CrashReport.  Library consumers may have vastly different
requirements and it's not helpful to try to enforce this structure when we
don't even make use of the members.

SourceLineInfo duplicates some fields of StackFrame, and it should be
possible for the lookup method (which I'd like to rename to
FillSourceLineInfo) to just take a StackFrame as an in/out parameter and
fill in those missing fields.

Presently, the build system is slightly annoying in that objects,
executables, and libraries are all placed in the root directory of the
package instead of adjacent to the relevant sources.  The automake option
to fix this is "subdir-objects."

Also, maintaining the build system is slightly awkward because configure.ac
references macros that are defined outside the source tree.  We should add
the m4 macros we use to our own repository.

I'm skeptical about the STL_NAMESPACE and GOOGLE_NAMESPACE thing anyway,
because I don't really want to export config.h.  Maybe we should just get
rid of this stuff and assume std and google_airbag everywhere.

Right now, the only test for minidump.cc runs minidump_dump on a minidump
file and compares the output to known output.  We should test the code
itself more directly (possibly by providing minidump files or fragments
that test limits?)

Changing header paths in #includes and #ifdef guards to be relative to src/.

This is the beginning of airbag's server-side public API.

Most of the TODO(mmentovai) messages in minidump.cc are about checking
memory allocations.  The Minidump family of classes should provide some
(user-configurable) allocation limits, to avoid over-allocating in the
event of a huge or (worse) malicious minidump.

Initial import of a few Java files, asking for a code review.

What steps will reproduce the problem?
1. go to "Source" tab
2. click on the link to browse svn repository

What is the expected output? What do you see instead?
expecting to see the source tree, but I got 'access denied' message.

This cleans up some of the rough edges in RangeMap.

This is an opaque entity like the report id, but can uniquely identify the
client who sent the report.

What steps will reproduce the problem?
1.
2.
3.

What is the expected output? What do you see instead?


What version of the product are you using? On what operating system?


Please provide any additional information below.

Right now Minidump accepts an fd.  This should be changed to a const char*
or string filename.  We agreed that we probably don't need a file
abstraction here for now.

What steps will reproduce the problem?
1. run "make check"

What is the expected output? What do you see instead?

I see:

--- ../src/processor/testdata/minidump1.out     2006-09-06
11:18:24.000000000 -0700
+++ -   2006-09-06 16:17:04.997440000 -0700
@@ -4,7 +4,7 @@
   stream_count         = 8
   stream_directory_rva = 0x20
   checksum             = 0x0
-  time_date_stamp      = 0x44172f15 2006-03-14 16:01:09
+  time_date_stamp      = 0x44172f15 2006-03-14 13:01:09
   flags                = 0x0
 mDirectory[0]
 MDRawDirectory

presumably because the expected result is local time in EDT, and I'm in PDT.

I was thinking about different ways to test Stackwalk.  One idea I had was
to walk the test process' own stack.  I threw this together, which makes a
bunch of recursive calls to verify that Stackwalker returns the right
number of frames on x86.