tigerdog ([info]tigerdog) wrote in [info]bezilla,
@ 2006-10-12 09:12:00
Previous Entry  Add to memories!  Tell a Friend!  Next Entry
Report: bezilla day of coding
First and most important: a big "Thank You!" to everyone who showed up and helped on yesterday's "day of coding" event. This is the first time in recent memory I've seen fyysik, tqh, neilx, beteka, mmadia, koki, Drake (a BeOS dev returning after hiatus), [Beta] and others all on the #bezilla IRC channel at the same time. Everyone contributed, everyone worked hard. Special thanks to fyysik, who helped despite feeling ill.

Our efforts focused on identifying bugs that were fixed on the trunk but not on the branch, then back-porting these fixes so as to release a stable and useable Firefox 2.0 at the same time as the rest of the world gets their versions. The result is an up-to-date Bon Echo (Firefox 2.0) release candidate build, available now on the BeBits "Firefox Bleeding Edge" page.

Neilx also created a new Firefox 3.0 tracking bug and moved all the pesky, longstanding entries (i.e. printing) still needing to be fixed. Neilx also kept a running wiki page that documented our discussions.

We also discussed incorporating tqh's new, lightweight nspr. Because some recent problems might be related to the increased use of threading, tqh agreed to take a detailed look at the nspr test suite and insure this new nspr is as solid as possible before we incorporate it.

After we satisfied ourselves that we'd done what we could with Bon Echo, discussions turned towards isolating the nasty problems plaguing our current trunk builds: crashes at startup and "freezes". It was pointed out on IRC that the "freeze" problem may have been around a long time because its symptoms sound similar to that discussed in a Chatzilla bug filed a long time ago. Drake and neilx looked at bdb screenshots of the browser in its frozen state. (see http://www.sheltonfamily.org/bdbScreenshots/screen02.png through screen20.png if you also want to puzzle on this.)

If you attended and I left you out of this message, please don't be offended - just blame it on my overloaded brain! I hope everyone found this session as enjoyable as me. Let's try to do it again sometime soon!



(Post a new comment)

Great stuff
[info]kokimare
2006-10-12 05:15 pm UTC (link)
Congrats and thanks to the Bezilla team for this effort.

Could post the IRC log somewhere for the rest to see the details of what was discussed? Perhaps somewhere on Bezilla.org (I volunteer to post it if somebody emails it to me)?

> Neilx also kept a running wiki page that documented our discussions...

How about also moving this to the Bezilla.org wiki?

Cheers,

Koki

(Reply to this) (Thread)

Re: Great stuff
[info]tigerdog
2006-10-12 05:32 pm UTC (link)
I will incorporate a link to the wiki if I can find it - I cleared my browser history and lost the link. if anyone has the link, please post it in a comment here.

(Reply to this) (Parent)

IRC log
[info]kokimare
2006-10-12 07:09 pm UTC (link)
I have (an almost complete) IRC log of yesterday's session on #bezilla.

Any opposition to posting this online?

Koki

(Reply to this)


[info]paradroid
2006-10-12 10:05 pm UTC (link)
I don't want to take any credit for mostly idling, and keeping up with the progress on BeZilla :^)

[Beta]

(Reply to this)

Duplicating stack trace of lock up.
[info]engaric
2006-10-12 10:19 pm UTC (link)
managed to get one tab to lock. Same stack traces (based on memory as I had to reboot) as screen13 and screen14. Accessing an extension page. https://addons.mozilla.org/firefox/1810/

Definitely seems to be related to usage to PRWaitCondVar due to SSL.

I believe we were going to recommend people may want to turn off periodic update checks as they cause backpground https gets and therefore cause lockups at random times.

(Reply to this) (Thread)

Re: Duplicating stack trace of lock up.
[info]engaric
2006-10-12 10:26 pm UTC (link)
This lock up is not an always reproduces (as others have also had) so your experiences may vary. I have only been able to reproduce this once it is almost certainly a race condition.

(Reply to this) (Parent)


[info]tqh
2006-10-13 08:36 am UTC (link)
Interesting to see in the screenshots is the port_buffer_size_etc call seems overrepresented. Did fyysiks nsAppShell changes go in to the branch. I know he uses that call a lot there, and it might behave badly (ports and pipes on BeOS are pretty bad citizens).

(Reply to this) (Thread)


[info]tqh
2006-10-13 08:40 am UTC (link)
Although I think that might have been get_port_info that gets called a lot.

(Reply to this) (Parent)


Create an Account
Forgot your login or password?
Login w/ OpenID
English • Español • Deutsch • Русский…