How to file a bug on a Firefox hang on OS X

August 5, 2010
Posted by beltzner

How to file a bug on a Firefox hang on OS X

When I plugged my Mac into an external monitor yesterday, my nightly build of Firefox “beachballed” and became non-responsive. I was experiencing a browser hang.

I wanted to do what I could to help our engineers understand what caused the problem, and my colleague Jeff Muizelaar showed me what to do. I figured that I’d share that knowledge with you, gentle reader, in case you were also interested in doing what you could to help the Mozilla project with the development of the Firefox browser.

Requirements:

a Mac running OS X (I’ll write another post later on how to do this on Windows, too)
a nightly Mac build of Firefox (don’t worry – they’re stable; I use it as my day-to-day browser)
XCode installed on your computer (this is also included on your OS X DVD)

When Firefox “beachballs”:

When you see a colourful spinning disc (also known as a “beachball”) instead of a mouse cursor while hovering over a Firefox window, you’re experiencing a hang. If this lasts a long time, you’ll want to file a bug so that our engineers can investigate the source of the problem. To help them do this, you can collect two sources of information:

a profile
a stack trace

Profiling Firefox with Shark:

In the “Developer” folder installed by XCode there’s a folder called “Applications”, and inside that there’s a folder called “Performance Tools” and inside that there’s a program called “Shark.app”. You should also be able to find it with Spotlight.

Launch Shark.app
Select “Time Profile”, “Process”, “firefox-bin” and set the time limit to 30s
Press Start
Stop it anytime after 10 seconds if you’re not patient enough to wait the full 30s

Once it’s done collecting samples, Shark will analyse them and produce a chart indicating where Firefox was spending it’s time. Congratulations! That’s the first piece of information which will help the engineering team.

Getting a stack trace with gdb:

The next thing you can collect is a stack trace. Here’s how:

Open a terminal window and type “ps aux | grep firefox-bin | grep -v grep” – this returns a list of running processes that match the name “firefox-bin”
Make a note of the process number – it’s the first number in the line of text, usually three or four digits – let’s pretend it was 6115 like in the screenshot below.
Type “gdb” to launch the debugger that was installed with XCode
Type “attach 6115″ where “6115″ is the process number you got from step 1
Wait a few seconds for the debugger to attach to your Firefox process
Type “bt”
Type “detach” to detach from the Firefox process
Type “quit” to quit the debugger

Congratulations! Now you have a window with a stack trace! You can now force-quit Firefox and restart it, since you’ll need it to file the bug.

Now you’re ready to file a bug:

Bugzilla isn’t a very friendly tool at times, but it’s powerful and what we use. Don’t worry if your bug is a duplicate, people check for those and duplicate bugs end up being very helpful, so please don’t hesitate to file them. When dealing with a hang, it’s probably best to file the bug in the Firefox::General component and start the summary with the word “hang”. Try to write a summary that represents what you were doing when Firefox hung, like “hang when I plug in an external monitor” or “hang when I click on a link from Tweetie”.

Go to bugzilla.mozilla.org and log in (you may need to create an account)
Click on File a Bug
Select Firefox as the product and General as the component unless you suspect it’s associated with something in particular based on the Shark analysis or stack trace
Write a summary that starts with the word “hang” and expresses what you were doing when Firefox hung
Type a few sentences at the top of the report that describes what you were doing, and what version of Firefox you’re using (you can copy the “build identifier” from the page that appears when you type “about:” into the location bar and hit enter)
Expand all the twisties in the Shark analysis window, select all the rows, then copy them and paste them into the bug report
Scroll back the Terminal window and copy the stack trace into the bug report
Submit the bug report

I filed a bug on the hang I was experiencing using these steps, and that information may save our users from experiencing the same hang in the future. This is an important part of the open source process, and using these steps, hopefully you’ll also be able to take part in the development of Firefox.

8 Comments

Posted Under mozilla

Justin Dolske
August 5, 2010

A quick way to grab a look at what’s going on is the “sample” utility on OS X…

1) grab the Firefox process ID as above (let’s assume 6115 again)
2) run “sample -p 6115″

It’ll sample for 10 seconds by default, you can press Control-C to cancel it earlier.

It’ll chug for a moment, and then report something like “Sample analysis of process 6115 written to file /tmp/firefox-bin_6115.34Xrsp.sample.txt”

Attach that to a bug, enjoy great success.

Cww
August 5, 2010

You may want to also include about:support info (Help > Troubleshooting info) and if this seems too complex, try SUMO where we can walk you through some common fixes so it doesn’t happen again.

matt
August 5, 2010

Mike, I just went through the same learning process filing a bug, and this would have come in handy.

Developers might ask for different kinds of Shark profiles, but I wonder if you should recommend the “Tree View” not the default “Heavy View”. This can be changed in the bottom right corner of the profile window.

Also, using File / Generate Report seems helpful for cut & pasting into a bug.

And shouldn’t there be a way to automatically expand the twisties?

Mossop
August 5, 2010

You can also just use Activity Monitor to do basic sampling, select the process and click the “Sample Process” toolbar icon

Smokey Ardisson
August 5, 2010

I second Mossop; that method is so much easier and more user-friendly.

Also, does pasting the Shark output into a bug really work (I see there’s not one in your bug)? Seems to me like

1) It’d wrap very badly, making the output almost impossible to read as a bug comment, and
2) It’d be far more that “a few lines of debugging output”

Both mean that the output would be better off pasted into a plain-text file and then attached as an attachment.

Jan
August 5, 2010

I just wanted to point out that the Activity Monitor -> inspect -> sample route has also Save option.
Activity Monitor resides in (Applications/Utilities)

Boris
August 6, 2010

> And shouldn’t there be a way to
> automatically expand the twisties?

There is. Option-click on any closed twistie to open it and everything under it. So you can close the root twistie, then option-click it, and get the full tree.