google / sawbuck Goto Github PK

It should be possible to filter the log by a regexp.

What steps will reproduce the problem?
1. Start Sawbuck
2. Enable Capture
3. Kill Sawbuck's process
4. Start Sawbuck again
5. Try to enable Capture

What is the expected output? What do you see instead?
Should enable Capture but it can't

I'm guessing we need to add an internal way to close previous Event Tracing 
Sessions if they were left open. Currently, we can use the logman -ets stop 
command manually, but it would be nice if Sawbuck would do it automagically.

Currently, our instrumenter contains no data as to what original DLL it 
corresponds to. A small data section containing some identifying information 
should be added as part of the instrumenting process. Similarly, the generated 
call-trace ETW file is not sufficient on its own to parse events. We currently 
need to correlate it with kernel events in order to determine in what module 
the events originate. Each instrumented module should output an event at load 
time that indicates the instrumented and original modules that the events 
correspond to (maybe an unload event as well?). This will also greatly simplify 
processing for orderings that will require data from multiple profiling runs 
(no need to correlate multiple call-trace files to multiple kernel trace files).

The order generator should similarly output identifying information for the 
original module that is meant to be applied to. Finally, the relinker should 
validate this information before actually relinking a module.

Should empty the log view.

What steps will reproduce the problem?
1. Minimize the Sawbuck window.
2. Right click on it in the task bar and close it.
3. Open Sawbuck again

What is the expected output? What do you see instead?
We should see the Sawbuck window when we start it. In this case, it starts 
minimized and choosing the restore option of the context menu when we right 
click on it in the task bar doesn't bring it back, we must first choose the 
move option of that context menu, hit the keyboard arrow keys, and then 
move the mouse to see a tiny window that you can finally resize and see the 
Sawbuck window as you wish to see it :-)

It should be possible to open trace files, or to import them into an existing 
session. This would allow viewing remotely captured logs, like e.g. logs 
captured during reliability test runs. 

Not saved currently.

The .egg file names are no longer constant - they change with the SVN revision 
number. The build will need to glob for the most recent versions.

What steps will reproduce the problem?
1. Verbose Omaha logging enabled.
2. Information logging for Chrome enabled.
3. Run Omaha unit test.
4. Clear all events.
5. Let new Chrome events be collected.

What is the expected output? What do you see instead?
Since I don't have Chrome symbols, I expect the symbols to be empty.
Instead, I see 3 lines that match the Omaha unit test executable.

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

Please provide any additional information below.
The three matching addresses were:
0x00403554
0x00403B45
0x004469AF

I assume but have not confirmed that these same addresses exist in both 
Chrome and the unit test.

The symbol path should be self-configuring from the installer, or at first 
use, and should be configurable in the UI.

The correct structures are:

struct ImageLoad64V1 {
  ULONGLONG BaseAddress;
  ULONGLONG ModuleSize;
  ULONG ProcessId;
  wchar_t ImageFileName[1];
};

struct ImageLoad64V2 {
  ULONGLONG BaseAddress;
  ULONGLONG ModuleSize;
  ULONG ProcessId;
  ULONG ImageChecksum;
  ULONG TimeDateStamp;
  ULONG Reserved0;
  ULONGLONG DefaultBase;
  ULONG Reserved1;
  ULONG Reserved2;
  ULONG Reserved3;
  ULONG Reserved4;
  wchar_t ImageFileName[1];
};

In the WriteTraceFileHeader() function in trace_file_writer.cc the header 
pointer gets initialized to point to the top of the buffer being used by the 
VectorBufferWriter for serializing the variable length portion of the header.

After writing the variable length part of the header, the code tries to update 
the header with the total length, and tries to align the writer to the page 
size.

The problem is that writing the variable length part of the header may have 
caused the underlying buffer memory (managed by a vector) to have been 
reallocated. The header pointer may now be pointing to the wrong memory region.

The header pointer should be reset before adjusting the header size and 
aligning the stream to a page boundary.

Set default column widths on first use and save/restore column widths and 
order.

What steps will reproduce the problem?
1. Start Sawbuck 
2. Click on a log message from a version of Chrome you don't have symbols for.
3. Sawbuck starts downloading the >170Mb (!!!) pdb file, which may take some 
time.
4. Quit Sawbuck, but note that while the window goes away, the process does not 
exit.

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

The download should be cancelled and the process should quit.

This would make it easier to deal with logs from multiple providers (e.g. 
Chrome and Chrome Frame).

We're currently outputting the LoadConfig's SEH table with the handlers in 
whatever order we found them in.
It appears that the table of handlers is expected to be sorted, which makes 
sense, as then the exception handling machinery can binary search the table.
See 
http://msdn.microsoft.com/en-us/library/windows/desktop/ms680328(v=vs.85).aspx: 

SEHandlerTable
The VA of the sorted table of RVAs of each valid, unique handler in the image. 
This member is available only for x86.

As-is the module lookups can fail for existent modules, or can return the 
wrong module. 
The module paths yielded from the NT Kernel Log sometimes start with a 
backslash, without any indication of the drive letter that stores the module 
file. 
The module resolution machinery should search all local drives for the 
module, and should verify the checksum and size for any module found. 

So far the only way to recompile/test again is to close sawbuck and relaunch it 
so that the PDB files can be modified.

This requires providing a password again, given the need to run as admin :(

It is possible for the call trace consumer to consume e.g. two kernel logs 
simultaneously, where one is 32 bit and the other is 64 bit. To correctly parse 
them, the 32/64 bit state needs to be maintained per log file.
The same is necessary to allow consuming logs in raw time mode.

The bat files are awkward and on Windows XP there seems to be no way to 
instruct logman to capture with perf or CPU clock time resolution. This is 
better done with a small command line tool, or with an export on call_trace.dll 
that can be invoked with rundll32.

The instrumenter currently ignores calls out to imports. This can not stand.

What steps will reproduce the problem?
1. Capture a log from a very busy system.

What is the expected output? What do you see instead?
The events should be in strict time order, in particular events from the same 
process/thread should.
Sometimes, however, the events are delivered out of order by ETW, and Sawbuck 
does not fix this on receipt.

Expected: No fail!

There is no easy way to keep track of interesting messages (the time stamp 
could be used, but it is not unique and it is kind of hard to track).

There appears to be something the matter with the reordered image files that 
prevents rebase and bind from successfully binding or rebasing them.

D:\>ReBase.Exe -v -b 0x100000 chrome-reordered.dll

REBASE: *** RelocateImage failed (chrome-reordered.dll).  Image may be corrupted


REBASE: Total Size of mapping 0x0000000000000000
REBASE: Range 0x0000000000100000 -0x0000000000100000

It would be cool to be able to file or update issues with log entries and their 
associated stack traces from the Sawbuck UI.
See the codesite API: http://code.google.com/p/support/wiki/IssueTrackerAPI

It would be nice if each column had a right-click context menu to add the 
columns value to the include/exclude filters. 

SRV*C:\Users\pregommi\AppData\Local\Temp\symbols*http://msdl.microsoft.com/downl
oad/symbols;SRV*C:\Users\pregommi\AppData\Local\Temp\symbols*http://chromium-bro
wser-symsrv.commondatastorage.googleapis.com

From registry.

At present, the PE parser doesn't parse resources, as a case in point. Parsing 
the remaining PE structures would give us flexibility to relocate all sections, 
which will make our lives easier all around.

What steps will reproduce the problem?
1. Start capture
2. Select a log item
3. Open stack trace pane
4. Clear all

What is the expected output? What do you see instead?
The stack trace should clear out.
Instead it stays in place for an empty selection.

Please use labels and text to provide additional information.

When building up a set of filters, the user should be able to save that list to 
a file and load it again later. 

The saveable configuration could also include the list of enabled ETW consumers.

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

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


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


Please provide any additional information below.

As-is the main UI will hang for long periods of time while symbol files are 
being downloaded and symbols are resolved.

Only the log view implements copy as-is.

What steps will reproduce the problem?
1. build chromium with the source tree located on d:
2. run sawbuck and chromium
3. open stack trace pane

What is the expected output?
Should show file/line/function for all chrome.dll frames.

What do you see instead?
no file/line/function info for chrome.ddll

What version of the product are you using? On what operating system?
Sawbuck 0.6.4.0 on Vista 64

Please provide any additional information below.
If I create an empty directory tree on C: matching the one on D: and copy 
chrome.dll there, sawbuck shows stack traces correctly.

The disassembler should not disassemble past call to a non-returning function. 
As-is, this occurs a few times during Chrome.dll disassembly, but AFAICT the 
disassembly either flows into the adjoining basic block, or terminates on 
reaching switch jump tables. 

There are very few remaining dependencies on Sawbuck. We should promote Syzygy 
to its own top-level project.

See http://goto.google.com/zzign

[1229/164529:INFO:parse_engine_rpc.cc(85)] Processing 
'trace-chrome.exe-201111164115864-2567248.bin'.
[1229/164529:ERROR:parse_engine.cc(93)] Trying to insert conflicting module: 
\Device\HarddiskVolume2\b\build\slave\chrome-official\build\src\build\Release\in
strumented\chrome.dll (base=0x1883176960, size=34738176).
[1229/164529:ERROR:parse_engine.cc(93)] Trying to insert conflicting module: 
\Device\HarddiskVolume2\b\build\slave\chrome-official\build\src\build\Release\in
strumented\chrome.dll (base=0x1883176960, size=34738176).
[1229/164529:ERROR:reorderer.cc(386)] Relative(0x019BE2ED) maps to a non-code 
block (_bad_alloc_Message in 
\Device\HarddiskVolume2\b\build\slave\chrome-official\build\src\build\Release\in
strumented\chrome.dll).
[1229/164529:ERROR:parse_engine_rpc.cc(74)] Failed to consume 
'src\build\Release\call_traces\trace-chrome.exe-201111164115864-2567248.bin'.
[1229/164529:ERROR:reorderer.cc(255)] Failed to consume call trace events.
[1229/164529:ERROR:reorder_main.cc(182)] Reorder failed.
ERROR:__main__:Exception during Syzygy optimization.

Add a command handler (and perhaps an r-click handler with a popup) that 
makes all time display relative to the currently selected event.  

If the disassembly kept metrics on how many bytes disassembled, and how many 
bytes attributed to data (jump tables), we could dump an overall disassembly 
coverage metric after decomposition.

For symbol files that already have Omap data because of a previous reordering, 
we should be able to produce a symbol file for a new reordering by merging new 
Omap data with the Omap data in the original symbol file.

It would be great to be able to filter logs by process id/thread id, 
{file|line} etc.

As-is, Sawbuck will pass an enable mask of 0xFFFFFFFF for every provider 
enabled. It would make sense to allow setting the enable bit mask per 
provider, which would allow using enable mask bits to control additional 
features to stack trace capture or to define finer grained facilities.

What steps will reproduce the problem?
1. Create a filter to exclude a frequently occurring message.
2. Run an instrumented process and observe that the log message does not appear.
3. Exit Sawbuck.
4. Open Sawbuck.
5. Run the same instrumented process.

What is the expected output? What do you see instead?
Expected: The filtered messages are not shown.
Actual: The filtered messages are shown. If you open the Filter dialog and 
click OK, the messages will be filtered.


What version of the product are you using? On what operating system?
0.6.5.0
Windows XP SP3

Please provide any additional information below.
My use case is that I have verbose logging enabled, but there are some strings 
that occur much too often and need to be filtered. Thus, I'd like to always 
have them automatically filtered.

A nice feature might be to have "permanent" filters or saved filters that 
always get loaded but can be modified. This would be useful if you wanted to 
regularly filter messages and sometime needed to filter specific ones. Fixing 
this specific issue, though, would be sufficient.

Symbol downloads can take a long time. It would be nice if the status of 
resolution were displayed in the status bar. 

Copying selected log statements from log view.

The RPC events are played back one process at time instead of replaying events 
in time order, interleaving processes.
This confuses the reorderer's process group accounting and reporting.

Typical output looks like this (which covers 10 launches of Chrome, one 
renderer, one browser each + misc):

[1230/074924:INFO:reorderer.cc(272)] Calculating new order.
[1230/074924:INFO:linear_order_generator.cc(129)] Encountered 21 process groups.

See e.g. 
[http://chromegw.corp.google.com/i/client.syzygy/builders/Syzygy%20Release/build
s/290/steps/Benchmark%20Chrome/logs/stdio]

This would it quicker to find problems where we fail to e.g. copy references.

Under VS2010, the grinder project fails to build because the code assumes it 
can modify a set element via an iterator. In the latest iteration of the C++ 
standard, this is not allowed (as it can invalidate the set constraint).