Comments on: Ask the Readers: How to Report Software Bugs? http://www.soitscometothis.com/2008/08/12/ask-the-readers-how-to-report-software-bugs/ "So It's Come To This:" is a scrapbook for my philisophical essays on the world, casual observations, and personal rants. Tue, 06 Jan 2009 02:43:33 +0000 http://wordpress.org/?v=2.7 hourly 1 By: C.G. http://www.soitscometothis.com/2008/08/12/ask-the-readers-how-to-report-software-bugs/comment-page-1/#comment-22715 C.G. Wed, 13 Aug 2008 23:25:35 +0000 http://www.soitscometothis.com/?p=449#comment-22715 Maciej, Well, I did it. I joined Bugzilla and I submitted my first crash report. I was able to isolate specific actions that caused a crash and I reported it. Hopefully, I submitted a quality report which can be reviewed and fixed. Now I get a sense of why people contribute to FOSS... I feel pretty good. Thanks for the advice!! Maciej,

Well, I did it. I joined Bugzilla and I submitted my first crash report. I was able to isolate specific actions that caused a crash and I reported it. Hopefully, I submitted a quality report which can be reviewed and fixed.

Now I get a sense of why people contribute to FOSS… I feel pretty good.

Thanks for the advice!!

]]> By: Maciej Stachowiak http://www.soitscometothis.com/2008/08/12/ask-the-readers-how-to-report-software-bugs/comment-page-1/#comment-22695 Maciej Stachowiak Wed, 13 Aug 2008 09:44:50 +0000 http://www.soitscometothis.com/?p=449#comment-22695 Hey there C.G.! Thanks for asking about bug reports. If you're seeing a lot of crashes, then yes, a bug report would help. Here are some things to think about: A) If you can find a consistent set of steps to get a crash (visiting a specific site, clicking a particular part of a site, etc) then that makes for the best kind of bug report. In fact, if you crash, you should try to do the same thing you just did to see if you can repeat it. If you can consistently get a particular crash, then you should include steps to reproduce the crash, including the specific URL, and that should be enough if the WebKit team can reproduce it too. B) If you can't reproduce it consistently (or even about 50% of the time) with the same set of steps, then those kinds of bugs are tougher. What I recommend is clicking on "Report" when the crash dialog comes up, but don't report to Apple, instead, copy the crash trace from the window that comes up, and put it in a bug report. You should also include the URL or URLs of sites where this happens, if possible. If you want extra credit, you can try old builds from the archives at . A good way to proceed is to start with a build several months old, to see if the crashing still occurs. Once you find a good build, start splitting the difference between that and the latest. For instance, if you find that r34000 is good, but r35000 is bad, then your next build to try is halfway in between, r34500 (or whatever is closest). If that one is bad, you split the difference again to 34000 and try 34250. If it is good, then you split the difference to r35000 and try r34750. Basically keep track of what are your known good and bad builds and split halfway in between. Proceeding this way, you should be able to narrow the range to between two specific nightlies, which will help the WebKit team a lot! This isn't strictly necessary, but again, if you are really excited about helping the WebKit team this is a good thing to do after you file the initial bug report. More info on reporting bugs to the WebKit project is here: and here . I hope this helps. Hey there C.G.! Thanks for asking about bug reports. If you’re seeing a lot of crashes, then yes, a bug report would help. Here are some things to think about:

A) If you can find a consistent set of steps to get a crash (visiting a specific site, clicking a particular part of a site, etc) then that makes for the best kind of bug report. In fact, if you crash, you should try to do the same thing you just did to see if you can repeat it. If you can consistently get a particular crash, then you should include steps to reproduce the crash, including the specific URL, and that should be enough if the WebKit team can reproduce it too.

B) If you can’t reproduce it consistently (or even about 50% of the time) with the same set of steps, then those kinds of bugs are tougher. What I recommend is clicking on “Report” when the crash dialog comes up, but don’t report to Apple, instead, copy the crash trace from the window that comes up, and put it in a bug report. You should also include the URL or URLs of sites where this happens, if possible.

If you want extra credit, you can try old builds from the archives at . A good way to proceed is to start with a build several months old, to see if the crashing still occurs. Once you find a good build, start splitting the difference between that and the latest. For instance, if you find that r34000 is good, but r35000 is bad, then your next build to try is halfway in between, r34500 (or whatever is closest). If that one is bad, you split the difference again to 34000 and try 34250. If it is good, then you split the difference to r35000 and try r34750. Basically keep track of what are your known good and bad builds and split halfway in between. Proceeding this way, you should be able to narrow the range to between two specific nightlies, which will help the WebKit team a lot! This isn’t strictly necessary, but again, if you are really excited about helping the WebKit team this is a good thing to do after you file the initial bug report.

More info on reporting bugs to the WebKit project is here: and here .

I hope this helps.

]]>