You are currently viewing a snapshot of www.mozilla.org taken on April 21, 2008. Most of this content is highly out of date (some pages haven't been updated since the project began in 1998) and exists for historical purposes only. If there are any pages on this archive site that you think should be added back to www.mozilla.org, please file a bug.

Skip to main content

Bug Triager's Guide
How to Pick a Component for Crashing Bugs

DRAFT
comments to cbegle@mozilla.org

Program Crashed, no stack trace is available

Windows
If you crash, and know what module you crashed in, type the module name here:
The result of the search should be a file called makefile.win. The makefile.win's directory name should give you a clue to the bug's correct Component.

For example, searching for the dll name uconv would result in a makefile.win that lives under /intl/uconv. Based on the intl directory name, you could guess that the bug was in Internationalization.

Here's a list of most of the DLLs and libraries in Mozilla.

Crash - With a Stack Trace

If you're triaging a bug that has a stack trace, a good first place to look is the first line in the stack trace. For example:

SinkContext::FlushText(int * 0x00000000, int 0) line 1985 + 6 bytes
SinkContext::FlushTags() line 1778
HTMLContentSink::DidBuildModel(HTMLContentSink * const 0x03fd7bd0, int 0) line 2191
CNavDTD::DidBuildModel(CNavDTD * const 0x02d633a0, unsigned int 0, int 1,
nsIParser * 0x03fd7da0, nsIContentSink * 0x03fd7bd0) line 696 + 14 bytes
nsParser::DidBuildModel(unsigned int 0) line 587 + 55 bytes
nsParser::ResumeParse(nsIDTD * 0x00000000, int 1) line 1017 nsParser::OnStopRequest(nsParser * const 0x03fd7da4, nsIChannel * 0x02e2db30,
nsISupports * 0x00000000, unsigned int 0, const unsigned short * 0x00000000) line 1407 + 19 bytes

Here's what we can learn from from the first line of that stack trace:
FlushText Name of the function where Mozilla crashed
SinkContext Class of which the function FlushText is a member
line 1985 Line number in the file that defines FlushText

A good first guess is to assign it to whoever wrote line 1985 of SinkContext::FlushText.

  1. Use LXR to find the definition of SinkContext::FlushText.

    The search result should show you the directory and file where this function is defined. In this, case the file lives under the "layout" hierarchy, in the file nsHTMLContentSink.cpp.

  2. We can figure out who wrote the code that crashed by going to the top of nsHTMLContentSink.cpp, and clicking the link to CVS Blame. This shows us who wrote each line of code in this file.

  3. Now we can go to line 1985, and see that vidur@netscape.com wrote that line of code.

  4. Change the bug report's component to Layout component, and assign the bug to vidur@netscape.com.

Sometimes, it's not this straightforward; the code that really caused the problem might not be right at the top of the stack. In that case, the person you assinged it to will probably re-assign the bug to someone who owns the code higher on the stack.

Code threw an assertion, stack trace is attached

If the first line in the stack trace starts with nsDebug, that means that some code threw an assertion. You want to look up the code that threw the assertion, not the assertion itself.

If the first functions in a stack trace are members of nsDebug, that means that the application threw an assertion. In this case, you want to look up the code that threw the assertion (the line that is in bold), not the code in the assertion itself. For example:

nsDebug::Assertion(const char * 0x01061bd8, const char * 0x01061b8c, const char * 0x01061b54, int 1071) line 189 + 13 bytes
nsDebug::WarnIfFalse(const char * 0x01061bd8, const char * 0x01061b8c, const char * 0x01061b54, int 1071) line 247 + 21 bytes
nsXULWindow::NotifyObservers(nsXULWindow * const 0x01f87ff0, const unsigned short * 0x0012e5f0, const unsigned short * 0x0012e84c) line 1071 + 96 bytes
nsContentTreeOwner::SetJSDefaultStatus(nsContentTreeOwner * const 0x02bb9554, const unsigned short * 0x0012e84c) line 214 + 35 bytes
GlobalWindowImpl::SetDefaultStatus(GlobalWindowImpl * const 0x02b6c540, const nsString & {...}) line 797
...

Here's what we can learn from the first line after all the nsDebug stuff:
NotifyObservers Function that called the assertion
nsXULWindow Class of which the function NotifyObservers is a member
line 1071 Line number in the file that defines NotifyObservers that makes the assertion

Now we just follow the same steps as a crash.

  1. Search for the function NotifyObservers using LXR. You want to find out where it is defined as a function.
    Your search result should find that the function is defined in the file nsXULWindow.cpp

  2. Once you are looking at nsXULWindow.cpp, you can click the link at the top of that page that says CVS Blame. This shows you who wrote each line of code in this file.

  3. Now look at line 1071 of that file. You can see that the person who wrote this code is tbogard@netscape.net, and with a little poking around you find that his Bugzilla ID is travis@netscape.com. Now you know the right owner for the bug.

  4. Now you can change the component of this bug to XP Tookit/Widgets, and the owner of the bug to travis@netscape.com.

Sometimes it's not that straightforward; the code that really caused the problem might not be right at the bottom of the stack.