Saturday, December 15, 2012

gcc update succeeded! (plus: four heads are better than one)

Our failure upgrading to gcc 4.6.3 in the prior post turned out to be a canary in the coal mine (though in retrospect issue 169 was the first manifestation of the underlying problem) because soon after, Tobias started finding problems in some of his test builds for AuroraFox, and SeaMonkeyPPC wouldn't run at all either. Tobias was able to show that Apple ld had generated a bad branch in the Mozilla megalibrary XUL (which has been an intrinsic part of Firefox and all of our PPC community derivatives including AuroraFox, Tenfourbird and SeaMonkeyPPC since Mozilla 5), and my analysis showed it to be completely out of range. Ben's and my thought was to slim down XUL, but Tobias was able to find the bug in Apple ld to properly handle such large branches, hikerxbiker was able to prove it worked against SeaMonkeyPPC, and this post is, voila, coming to you from a debug build of 19.0a2 on the G5. So TenFourFox lives once more. Tobias has upstreamed this linker fix to MacPorts; our Fink users should make sure they make a similar fix themselves.

This is why it's wonderful to have a community working on continuing the PowerPC OS X Mozilla ports. As an example of what happens when there isn't a community, it looks like the OS/2 port of Firefox, one of the longer running Tier-3 community builds, is running out of gas; they're still stuck on ESR 10 and the lone guy still cranking them out, Dave Yeo, doesn't have a lot of resources to turn to when things go wrong. They're already somewhat compromised in that WOFF downloadable fonts don't work right, so they're not fully Acid3-compliant as it is. I think this is going to happen to a lot of the smaller Tier-3 ports: ourselves and Landry Breuil on the OpenBSD side are about the only ones supporting big-endian hardware (WebKit even took big endian support out of YARR, the regexp library our JavaScript compiler uses, which we had to put back in), we don't see anything much going on with Solaris on SPARC these days, and I'm not sure what the state of Firefox is on the PPC Linuces since a lot of those users have migrated to WebKit-based browsers. It is entirely possible that the OS/2 port will end with Firefox ESR 10. And as an admirer of OS/2 back in the day, that's very sad to see happen.

Fortunately, that won't happen to us, at least not yet. Most of the 10.5 compatibility code has been restored successfully (and backported to 10.4, of course), and I have not found any major bugs in this version except for a strange problem with favicons I'm not able to fully track down yet. Now that we're running on a current compiler for a change, I was able to jettison all the ugly fixes I had to make for gcc 4.0.1 and make our changesets smaller and easier to maintain. When 19 goes into beta I'm going to pull it again and possibly generate some opt builds for people to play with, starting our new unstable branch off right. I'm also going to begin work on our PowerPC IonMonkey port and let's hope we get it done before Mozilla sends JaegerMonkey to that great tracing compiler in the sky. Remember: no plugin support exists at all in 18+.

For the stable branch, we will issue a fix for issue 194, which is a Mozilla bug actually but that doesn't appear is being backported to ESR17, and I'm looking into issue 195 where the check for dud fonts introduced with issue 171 can slow down the browser when it gets run unnecessarily, though this probably won't be fixed in time for 17.0.2, our "Best Commodore 64 Monitor Ever" release.

12 comments:

  1. "except for a strange problem with favicons"

    Is this the usual problem with the favicons randomly disappearing from the bookmarks menu? This bug just keeps coming back. Even when the favicons are visible, the display/refresh of the icons is pathetically slow. I think they need to come up with a new, fast, reliable way of displaying these icons. I mean - they're just little icons in a menu. How hard can it be?

    ReplyDelete
    Replies
    1. Based on your deep and thoughtful analysis, obviously very easy, so feel free to send in a patch. ;P

      (The actual issue in this case is issue 196, which turns out to be a Mozilla bug Tobias fixed upstream.)

      Delete
    2. Hasn't there been a problem in the past especially with bookmark icons? I can't find anything in the TFF issues but I think I remember something like that.

      Delete
    3. There was one with bookmark icons in menus that I fixed (and Mozilla accepted) a few cycles ago, but I don't remember which one that was.

      Right now I'm trying to track down a problem with session restore; it's not remembering tabs (it will with 17). I don't know if you've encountered this also. Not sure if it's something wrong with my profile yet or not.

      Delete
    4. Session restore working fine in AuroraFox and I didn't yet have problems with it.

      Delete
    5. I figured out the problem -- the webworker responsible for file I/O choked because 10.4 defines dirfd's dd_fd differently (10.5+ defines it as __dd_fd). So I think that covers all the outstanding bugs.

      Delete
  2. "Based on your deep and thoughtful analysis, obviously very easy, so feel free to send in a patch. ;P"

    Maybe I will.... mayyybe I will. (said while looking at the ceiling and rubbing chin thoughtfully)

    I wasn't saying this was just a TFF problem. I've had this problem also on many other versions of Firefox. I certainly wasn't knocking YOUR programming, Cameron. I think you're kick-ass awesome. :)

    ReplyDelete
    Replies
    1. Lol, I'm just yanking your chain. I think I've seen similar glitches, though I haven't experienced any lately. However, since Mozilla is moving more towards asynchronous updating to take advantage of multiple cores, many tasks that used to be synchronous and therefore simple to debug are now much more complex than they appear thanks to the interplay of multiple simultaneous threads. Some race conditions we've found independently because our systems are in general slower, and for the G3 and 7400 G4s, markedly slower, than the mainstream Firefox user.

      Delete
  3. Congrats to all working on this. I was reading along in issue 52 during the last weeks – for lack of programming skills I was unable to contribute anything more than keeping my fingers crossed. But anyway: ��������

    ReplyDelete
    Replies
    1. I knew it… That was supposed to be four glasses of beer, but blogspot seems to screw up the symbols. Generally, they render fine if Symbola is installed: http://tinyurl.com/cc5wtub

      Delete
  4. It looks like it's messing up the UTF surrogates. I had the same problem in TTYtter and had to throw together a UTF-16 surrogate interpreter.

    ReplyDelete
  5. Thanks for your great work!
    How does upgrading gcc improve TFF performance? Is TFF 19 much faster than 17?

    ReplyDelete

Due to an increased frequency of spam, comments are now subject to moderation.