Alexander C. Hubmann-Haidvogel has created a Thread Arc visualization extension for Thunderbird!Â Get info on the extension with some pretty pictures or just go straight for the extension at AMO.Â Thanks to David Ascher for the heads up.
As an example starting point, take a look at messageWindow.js’s global reads or global writes.Â From either of these you can click on other files in the sidebar to go to them.Â There is no execution trace, so the overview diagram won’t be any help.Â Be sure you have some free memory available and won’t try and hurt me if Firefox does something crazy.Â Note: for long documents, some delay is expected as it attempts to apply various fix-ups.Â Also note: clicking on things in the global reads/global writes tab won’t get you anywhere for now.
A quick example of a global read from that file (and who writes to that global):
- Top Level: commandglue.js
- Function: ClearThreadPane (in commandglue.js)
- Function: CreateBareDBView (in commandglue.js)
- Function: RerootFolder (in commandglue.js)
- Function: SwitchView (in commandglue.js)
- Function: openFolderTab (in mailWindowOverlay.js)
- Function: setMailTabState (in mailWindowOverlay.js)
- Function: restorePreSearchView (in searchBar.js)
- Function: MsgGroupBySort (in threadPane.js)
A quick example of a global write from that file (and who reads from that global):
- Function: OpenMessageByHeader (in mailContextMenus.js)
- Function: OpenInboxForServer (in mailWindow.js)
- Function: selectFolder (in mailWindow.js)
- Function: openFolderTab (in mailWindowOverlay.js)
- Function: LoadNavigatedToMessage (in messageWindow.js)
- Function: LoadNavigatedToMessage (in msgMail3PaneWindow.js)
- Function: OnLocationTreeSelect (in msgMail3PaneWindow.js)
- Function: SelectServer (in msgMail3PaneWindow.js)
- Function: loadStartFolder (in msgMail3PaneWindow.js)
- Function: RenameFolder (in widgetglue.js)
- Function: loadInboxForNewAccount (in accountUtils.js)
- Function: DropOnFolderTree (in messengerdnd.js)
- Function: CrossFolderNavigation (in msgViewNavigation.js)
The code, as always, is available at http://hg.mozilla.org/users/bugmail_asutherland.org/pecobro/
The title isn’t true yet, but it’s disturbingly almost-true.Â Pecobro’s hackish underpinnings have been “accidentally” replaced with surprisingly forward-looking code capable of supporting a much fancier feature set.Â (I didn’t mean to, but I got tricked because the incremental cost to doing the ‘right thing’ was always so low.)
The trace that you can see here, by clicking on any of this text what has coloring (and using firefox 3 in a session that you don’t mind if it crashes), is of running Mark Banner (Standard8)‘s Thunderbird bloatTest on OS X with DTrace probes enabled, but without actually doing the bloat testing.Â So Thunderbird starts up, opens the address book, closes it, opens the compose window, closes it, and then quits.
Here is a preliminary processed trace from a run triggering bug 296453.Â Be forewarned that there is some missing information from the underlying trace and so it’s not all that it could be.Â I think the XPConnect probes need to be fleshed out slightly more (and processed).
The code (both pecobro and mozilla codebase patches) is at: http://hg.mozilla.org/users/bugmail_asutherland.org/
What crazy overkill things can pecobro do now?
- Parse/interpret disturbingly large portions of makefiles.Â Sure, it ignores the rules, and I’ve only implemented the functions I require, but it does all the conditional and include stuff with variable expansion, including some key functions like foreach/filter/etc.
- Parse jar manifests sufficiently well to figure out what file ends up at what chrome path.
What is not crazy, but still nice:
- A foolish bug in the sparkbar calculation has been fixed.Â aka “Now With Accuracy”!
- If a function in a trace called another function or was called by another function, this will be displayed inline in the source display.
- Infer ‘native’ functions (with the above additional modifications to the Mozilla USDT probes), assigning them to an object.Â This ends up being Object, ChromeWindow, or other native Class type.Â Some of this may be mooted by getting the XPConnect probes reliably in the mix.
What doesn’t it do?
- Add the XPConnect js_Invoke probes; I punted on that because that was turning out to be difficult to get right.
- It ignores .xul files for now.Â Although xul files primarily appears in a caller context (as told by function-info probes), they can also be a callee when someone pulls a fast one and inlines some simple code in a script tag.Â We brutally mis-attribute the call to the previous function when this happens.Â This will eventually get resolved because we will need to understand .xul files for namespace reasons.Â Also, people sound like they’re interested in who overlays what and the like, and that’s sorta right up our alley thanks to all the overkill stuff we do.
- Exhaustively determine reads from/contributions to the ‘global’ (window or what not) namespace/scope.Â The groundwork is there in terms of understanding the contribution of top-level statements to the namespace or its reads from it, but we don’t traverse into functions.
- Associate functions with an object/type (ignoring the native function case).Â This requires more semantic understanding.
- Clicking on functions still doesn’t do anything.Â I disabled that before my first post on pecobro due to firefox-crashing issues, and still haven’t gotten around to resolving it.
- A usable overview visualization.Â The overview diagram has become cluttered by the presence of so many ‘relevant’ (touched) files.