SGI: Development

recondas wrote: So reload noscript and stop javascript from trying to jam all that extra crap thru that little hole in the GFW.

No-Script is back in the saddle, we shall see what happens. Did notice that the crashes

comes at the point of closing a tab, several times. Memory management coding error within Fireflop ?


Gotta go warsh the kevlar outerwear now, tomorrow night is The Second Biggest One here (the Truly Big Night is four nights after new year's, when the flying people come carrying money) ... intensive ground level fireworks on their way

First: A great, big T H A N K S ! for porting this to IRIX.
I waited a really long time for it.

I installed it on both Octanes, and it feels a lot faster than FF2.
Especially scrolling don'r locks up anymore while loading heavy pages,
an Javascript seems to be a lot more responsive...

However, I'm experiencing a strange problem: I can't reach some sites
from FF3, which load fine in FF2. If I type in an address in the address field
and press return, following happens with these addresses:

- FF seems to resolve the hostname successfully
- Begins loading the page from the server:
- Throbber begins to rotate
- Progress bar shows up
- Loading action stops after less than one seconds, status says: Done.
- Result: empty, white page.

Hitting reload button changes nothing. It's the same when trying to access the page from bookmarks,
passing URL as a command line argument and everything else.

These are the pages are affected by this:

http://www.google.com (also other TLDs)
http://www.bing.com
http://www.mozilla.org

and probably others.

But most pages load as intended. So no problems with

http://www.sgi.com
http://www.apple.com
http://www.microsoft.com
http://www.ebay.de
http://www.airliners.net

and lots of others (the one mentioned above are the ones I tried...)

Installation is on 6.5.22 systems, with old nekoware installs on it (originally installed back
in 2008), only updated packes when required, never updated the nekoware install as a
whole. So maybe its a problem with old libraries...
Of course I installed the required dependencies when installing FF3, so these should be up-to-date.

Its maybe interesting that all my traffic is forced to pass a proxy server of the provider (UMTS connection),
which seems to modify some HTTP traffic in sometime unpredictable ways. I've no means to shut this off
currently, but it seems not affecting any other browsers (in case it's the source of the problems with FF3 on
IRIX).

Any ideas about this? So far, I was not to recognize a pattern behind this...

Voralyan wrote: However, I'm experiencing a strange problem: I can't reach some sites
from FF3, which load fine in FF2. If I type in an address in the address field
and press return, following happens with these addresses:

- FF seems to resolve the hostname successfully
- Begins loading the page from the server:
- Throbber begins to rotate
- Progress bar shows up
- Loading action stops after less than one seconds, status says: Done.
- Result: empty, white page.

Hitting reload button changes nothing. It's the same when trying to access the page from bookmarks,
passing URL as a command line argument and everything else.

That is very weird. If you do a "view source" does it seem to have read the entire html page, and it just isn't rendering it?

View source: This is what I get:



which is the source of "about:blank". It's also what the window caption of the source viewer says:
"Source of: about:blank".

Seems that nothing gets downloaded...
So time to install wireshark and dig a little bit deeper.
I wonder where the difference is between the working and non-working sites..?

If I remember correctly the 3.0.X MacOS X versions suffered from the same problem,
but maybe my mind is fooling me on this... But I could swear that I've encountered this
strange phenomena earlier with FF...

That's just bizarre! Who are you using for name resolution? Maybe try opendns.org's nameservers, which is to say, put in your /etc/resolv.conf

Voralyan wrote: These are the pages are affected by this:

http://www.google.com (also other TLDs)
http://www.bing.com
http://www.mozilla.org

Okay, all this sites are ipv6 enabled.

http://www.sgi.com
http://www.apple.com
http://www.microsoft.com
http://www.ebay.de
http://www.airliners.net

And these sites are ipv4 only.

I build firefox3 with ipv6 enabled - this can be a problem if your system is ipv6 enabled and you don't have a working ipv6 connection. You can switch this off using about:config by setting network.dns.disableIPv6 to true.

diegel wrote: You can switch this off using about:config by setting network.dns.disableIPv6 to true.

That works. Many thanks!

I just installed Firefox and all its dependencies on my Octane. It was a surprisingly smooth and painless installation. I only had a couple of Nekoware packages on that machine, so I had to install more than 20 dependencies (and dependencies of dependencies). Everything just plain worked in my quick tests. (I'll try to do more extensive testing in a few days when I should have more time.)

I did encounter the same IPv6 issue that Voralyan mentioned but diegel's workaround took all of 10 seconds to implement and it worked well.

Great work, and thanks!

I gotta know, did you track down all the unaligned memory access? Or did you use 'sysmips(MIPS_FIXADE, 1, 0, 0)' ?

If you could e-mail your patches, I'd appreciate it just out of curiosity. I've had my build working (with Frank's excellent assistance) but hitting BUS errors sitting idle for a few months with a big 'todo' of sitting down and tracking down the errors or recompiling with the FIXADE workaround.

[EDIT, FWIW I was using mips pro, so I'm not sure how similar the problems were with gcc. I see the patch is supposed to be included in the tardist. I'll take a look.]

[EDIT, EDIT: Hmm, I've got it installed and it runs fine, but I don't see the patch file under /usr/nekoware/patch[es] ]

telackey wrote: Hmm, I've got it installed and it runs fine, but I don't see the patch file under /usr/nekoware/patch[es] ]

The patchfile is /usr/nekoware/patch/neko_firefox3.patch and it's not installed by default.

I fixed two more alignment errors. The main problem was an alignment error in the nsUrlClassifierHashCompleter stuff - I did not fix this problem, I simply disabled this code by disabling safe-browsing. Safe browsing is completely useless for Irix users and adds a lot of additionally database overhead. You can build firefox3 with this patch and mips pro also, but as usual you have to fix a lot of broken code if you start to use aggressive optimization with mips pro.

diegel wrote: I fixed two more alignment errors.

Still crashes for me sometimes but sure renders pages better than FF2 !

Take a look here :

http://www.libpng.org/pub/png/pngs-img.html

Nice !

Attached you find a rebuild of the javascript and xpcom libraries for firefox3. Hamei, can you please check if some of your crashes disappear with this libraries. It's a tar archive with libmozjs.so, libxpcom.so and libxpcom_core.so included. The libraries should be placed in /usr/nekoware/lib/firefox-3.0.19.

diegel wrote: Hamei, can you please check if some of your crashes disappear with this libraries.

Got them installed, thank you.

The weirder crashes seem to have gone away with a thorough house-cleaning. This installation is almost ten years old and I'm not afraid of /beta (bites one in the ass sometimes) so there was some cruft in there ... I still get crashes but now they are almost all just :


Thanks again, will see how it goes. One small step for man ...

it might help if diegel could post the list of what he has installed on his dev machine. only a clean(!) and similar environment can yield proper results.

foetz wrote: it might help if diegel could post the list of what he has installed on his dev machine. only a clean(!) and similar environment can yield proper results.

I don't think this is a version problem. I can see the errors here as well. But I don't use very fancy sites with lots of adds, so this is not a real problem for me. For my daily work this version of firefox works without any crashes. I think there was an optimization problem within the xpcom libraries, that caused segmentation faults. I have seen the bus error hamei reported, but I don't have any idea how to debug it, since I was never able to reproduce it.