Yes, there are major differences. The javascript engine is new designed and contains a lot of C++ code, in 3.0 javascript is C only. Additionally a lot of media tools for sound and video are added in 3.5, but you can disable this of course. I tried to compile 3.5 and came to the same point dexter had reached. I decided to debug 3.0 first, because I was sure to run into this bus error problem again in 3.5. Probably my fixes in 3.0 will fix firefox 3.5 as well, but at this point we are debugging firefox 3.0.hamei wrote: diegel : is there a major change between 3.0 and 3.5 ? I know there was a big different at 3.6 but is it possible that 3.5 would solve a few more problems ?
SGI: Development
beta test: firefox3.0.19 - Page 2
diegel wrote: I decided to debug 3.0 first, ...
Thank you very much once more! I finally updated my O2 (R10k/250, IRIX 6.5.27) so I was able to install your Firefox 3... and it works very well!
Both systems run IRIX 6.5.30, have >=2 CPUs and V12 graphics. I would not be surprised if both are not completely up-to-date wrt nekoware dependencies. Could you please build one tardist with -nostrip for the next beta, so that more meaningful backtraces can be made?diegel wrote: Thanks for testing so far. I will upload a new package including the missing files and dependencies on Friday.
@canavan: I don't see the crash you reported. Can you give some Information about your system and your Irix version?
I haven't seen any glitches.hamei wrote: Also, do you two sometimes have problems with re-drawing the screen ?
canavan wrote: I haven't seen any glitches.
Could be my 2@ graphics situation ...
Ran 'er hard for a few days and put 'er away wet, here's what it looks like to me :
Removed Firefox 2 this morning as having two versions of Firefox installed makes nothing but trouble. Yes, it's possible, but it doesn't work well.
FF3 functions better as a browser but it is a little less stable. With what I've been doing it crashes more frequently but at least the crashes are more predictable, and the chances of getting the problem fixed are higher.
If you run it on sites like Nekochan, which are mostly text and a few photos and standard html, it's great.
If you find yourself on more commercial sites with a lot of javascript, spyware, horseshit advertising gimmicks and track-you scripts, it will go down if you have very many tabs open. Four open tabs seems to be okay, except on really crappy sites.
I seem to get two kinds of crashes - the good ol' unexplained
Code: Select all
moz_run_program[36]: 1868 Memory fault
and
Code: Select all
terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc
It seems like about 50-50. At least the 'std::bad_alloc' gives a clue to what it is. If this cause goes away in the future we should cut our crashes in half. Yea !
At hi-res, it's waaaay better. At lower res on older, slower hardware Flop2 might be a better choice. I'm not sure how well this would run on an Indigo2 or an O2. If you have the faster hardware, it's worth upgrading.
One small step for man, one giant leap for mankind
Are you running out of memory, perchance?
smit happens.
bigred , 900MHz R16K, 4GB RAM, V12 DCD, 6.5.30
indy , 150MHz R4400SC, 256MB RAM, XL24, 6.5.10
purplehaze , 175MHz R10000, Solid IMPACT
probably posted from bruce , Quad 2.5GHz PowerPC 970MP, 16GB RAM, Mac OS X 10.4.11
plus IBM POWER6 p520 * Apple Network Server 500 * HP C8000 * BeBox * Solbourne S3000 * Commodore 128 * many more...
bigred , 900MHz R16K, 4GB RAM, V12 DCD, 6.5.30
indy , 150MHz R4400SC, 256MB RAM, XL24, 6.5.10
purplehaze , 175MHz R10000, Solid IMPACT
probably posted from bruce , Quad 2.5GHz PowerPC 970MP, 16GB RAM, Mac OS X 10.4.11
plus IBM POWER6 p520 * Apple Network Server 500 * HP C8000 * BeBox * Solbourne S3000 * Commodore 128 * many more...
ClassicHasClass wrote: Are you running out of memory, perchance?
May be ... only got 4 gigs in this box
hamei wrote: I seem to get two kinds of crashes - the good ol' unexplained
Code: Select all
moz_run_program[36]: 1868 Memory fault
and
Code: Select all
terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc
It seems like about 50-50. At least the 'std::bad_alloc' gives a clue to what it is. If this cause goes away in the future we should cut our crashes in half. Yea !
You may get some helpful information by running firefox via
Code: Select all
MOZ_DIST_BIN=/usr/nekoware/lib/firefox-3.0.19
MOZ_DEFAULT_NAME=./run-mozilla.sh-bin
MOZ_APPRUNNER_NAME=./mozilla-bin
MOZ_VIEWER_NAME=./viewer
MOZ_PROGRAM=/usr/nekoware/lib/firefox-3.0.19/firefox-bin
MOZILLA_FIVE_HOME=/usr/nekoware/lib/firefox-3.0.19
MRE_HOME=/usr/nekoware/lib/firefox-3.0.19
SHLIB_PATH=/usr/nekoware/lib/firefox-3.0.19:/usr/nekoware/lib/firefox-3.0.19
LIBPATH=/usr/nekoware/lib/firefox-3.0.19:/usr/nekoware/lib/firefox-3.0.19 3642 DYLD_LIBRARY_PATH=/usr/nekoware/lib/firefox-3.0.19:/usr/nekoware/lib/firefox-3.0.19
LIBRARY_PATH=/usr/nekoware/lib/firefox-3.0.19:/usr/nekoware/lib/firefox-3.0.19/components:/usr/nekoware/lib/firefox-3.0.19
ADDON_PATH=/usr/nekoware/lib/firefox-3.0.19
export MOZILLA_FIVE_HOME LD_LIBRARY_PATH
export SHLIB_PATH LIBPATH LIBRARY_PATH ADDON_PATH DYLD_LIBRARY_PATH
dbx /usr/nekoware/lib/firefox-3.0.19/firefox-bin
and then "run", after the crash just "where thread all".
Since it's a 32bit binary, everything > 2GB should be more than enough. You may be running out of address space, and a rqs/rqsall shuffle may be needed.May be ... only got 4 gigs in this box
try unlimiting before running FF.
Sitting in a room.....thinkin' shit up.
400MHz R12k - Dual 550MHz PIII - Apple G4 Cube dual 500MHz/GF6200 - Newton Messagepad 2100 - Apple PowerBook 2400c/G3@240 - DECstation5000/133 - Apple Workgroup Server 9150/120 G3@280 - Apple Macintosh IIfx - Apple Macintosh Color Classic (Mystic upgrade) - Sun Cobalt Cube 3 - Tadpole RDI UltraBook IIi - Digital HiNote Ultra II - HP 200LX
400MHz R12k - Dual 550MHz PIII - Apple G4 Cube dual 500MHz/GF6200 - Newton Messagepad 2100 - Apple PowerBook 2400c/G3@240 - DECstation5000/133 - Apple Workgroup Server 9150/120 G3@280 - Apple Macintosh IIfx - Apple Macintosh Color Classic (Mystic upgrade) - Sun Cobalt Cube 3 - Tadpole RDI UltraBook IIi - Digital HiNote Ultra II - HP 200LX
canavan wrote: You may be running out of address space, and a rqs/rqsall shuffle may be needed.
Thanks, went to do a rqs and got
Code: Select all
rqs32: Fatal Error: A /usr/nekoware/lib/firefox-3.0.19/libssl3.so region with address 0x400000 (region end address is 0x43c000). Failed due to address overlap. Please check firefox-bin and its liblist to make sure that it and its NEEDED shared objects have no overlaps among them by running "elfdump -o" on each of them
So the easiest thing to do is to sit on my fat ass and wait for diegel to put together a tardist with the ssl libraries incorporated
Got a little of this as well, in case it's of interest :
Code: Select all
(stuff)
libpng.so.3 => /usr/nekoware/lib/libpng.so.3
5586:firefox-bin: rld: Warning: elfmap: running new 32-bit executable but finding old 32-bit shared object /usr/lib/libCsup.so in the search path. You may not have set the environment variables correctly, please set LD_LIBRARY_PATH for old 32-bit objects, LD_LIBRARYN32_PATH for new 32-bit objects and LD_LIBRARY64_PATH for 64-bit objects (e_flags 0x10000003) -- continue searching ...
libCsup.so => /usr/lib32/libCsup.so
(more stuff)
I have no LD_LIBRARYN32_PATH set, on purpose.
It's a bit flaky at the moment but still livable. Better than Flop2, I think.
Have you tried the process mentioned in the
rqsall manpage
:
Some of the old firefox2 libraries may still be present in that list, this will rebuild the entire index and hopefully solve the problem.
Code: Select all
cp /var/inst/.rqsfiles t
rqsall -force -o t -update_registry /usr/lib/so_locations -update_registry_64 /usr/lib64/so_locations t
# Make sure t is not empty!
cp t t1
rqsall -rescan -same_age -force -move -o t2 t1
# Make sure t2 is not empty!
cp t2 /var/inst/.rqsfiles
Some of the old firefox2 libraries may still be present in that list, this will rebuild the entire index and hopefully solve the problem.
ShadeOfBlue wrote: Some of the old firefox2 libraries may still be present in that list, this will rebuild the entire index and hopefully solve the problem.
Discretion is the better part of valor .... I'll just wait a while for the next version, which will probably solve all these minor glitches
It's fine for now as long as you don't open very many tabs.
Copied over the FF2 libraris and all seems fine, though not done massive testing. All seems very smooth and swift.
Had been going to hang onto FF2 for the time being but then thought, why?
diegel, thank you!
Had been going to hang onto FF2 for the time being but then thought, why?
diegel, thank you!
Fuel
;
Indigo2
;
Octane
; RiscPC Kinetic/448MB/RISCOS4.39 or Debian-etch; Dell Inspiron4100/P3 1GHz/1GB/Debian-stable; EspressoPC ViaC3/900MHz/256MB/Debian-testing; RPi B RISCOS5.23; Rpi2 Raspbian-jessie; A5000/33MHz/FPA11/8MB/RISCOS3.11; A540/25MHz/FPA10/16MB/RISCOS3.11 or RISCiX1.21; R140/35MHz/4MB/RISCOS3.11 or RISCiX1.21
I'm posting with FF3 right now! All systems go!
GREAT work!
GREAT work!
(4x Challenge S)
The current fleet.
The current fleet.
I uploaded neko_firefox3.0.19.tardist to incoming, it will show up in beta soon. This version is now complete with the freebl libraries. I also moved many of the optimization options shadeofblue suggested to CFLAGS, so much more code is optimized with this options. I also double checked, that I don't have any newer software on the build system installed. In the previous builds I used a newer pango version than the current nekoware. This should fix some problems.
@canavan: This is a stripped version. If you still experience problems, I will put an unstripped version on my ftp server for you.
@canavan: This is a stripped version. If you still experience problems, I will put an unstripped version on my ftp server for you.
it is in beta now:
ftp://ftp.nekoware.de/beta/neko_firefox3.0.19.tardist
The "final" release looks good to me - no more crashes when loading the kickstarter page I've linked to before (or on amazon.com or garmin.com).
Now I'll have to figure out how to configure fonts with subpixel antialiasing and no color fringing.
Now I'll have to figure out how to configure fonts with subpixel antialiasing and no color fringing.
canavan wrote: Now I'll have to figure out how to configure fonts with subpixel antialiasing and no color fringing.
If anything, it's a little bit too sharp here. It's kind of disturbing
Your screenshot looks like you have not configured fontconf at all. Try adjusting thigs in /usr/nekoware/etc/fonts/local.conf and adding some more fonts (so far, I've tried the liberation fonts, the fonts that ship with qt 4.8 as well as the old microsoft "core fonts"). Apparently, you have to turn on antialiasing explicitly even for small sizes, otherwise bitmap replacements may get used. The configuration below is what I'm using now:If anything, it's a little bit too sharp here. It's kind of disturbing
Code: Select all
<dir>/usr/nekoware/etc/fonts/liberation</dir>
<dir>/usr/nekoware/etc/fonts/qtfonts</dir>
<dir>/usr/nekoware/etc/fonts/msttcore</dir>
<dir>/usr/java2/lib/fonts</dir>
<dir>/usr/lib/X11/fonts/75dpi</dir>:unscaled
<dir>/usr/lib/X11/fonts/100dpi</dir>:unscaled
<dir>/usr/nekoware/etc/fonts/URW</dir>
<dir>/usr/lib/X11/fonts/Type1</dir>
<dir>/usr/lib/X11/fonts/100dpi</dir>
<dir>/usr/lib/X11/fonts/75dpi</dir>
<match target="font" >
<edit mode="assign" name="hinting" >
<bool>true</bool>
</edit>
</match>
<match target="font" >
<edit mode="assign" name="hintstyle" >
<const>hintfull</const>
</edit>
</match>
<match target="font" >
<edit mode="assign" name="rgba" >
<const>rgb</const>
</edit>
</match>
<match target="font">
<edit mode="assign" name="lcdfilter">
<const>lcddefault</const>
</edit>
</match>
<match target="font" >
<edit mode="assign" name="autohint" >
<bool>true</bool>
</edit>
</match>
<match target="font">
<edit name="antialias" mode="assign">
<bool>true</bool>
</edit>
</match>
diegel wrote: it is in beta now: ftp://ftp.nekoware.de/beta/neko_firefox3.0.19.tardist
Thanks much! It works for me (O2 R10k/250, IRIX 6.5.27). I'm using it to write this post.
Diegel,
Thanks a lot for making it possible. FF3 works great on my Octane2 (running 6.5.30), but I still have problems on my fuel (also 6.5.30). It is probably due to bad library paths and so on. I could identify pendant references to libgdk_pixbuf (now "ldd .../firefox'bin" gives no error anymore) and tried to renew .rqsfiles as ShadOfBlue suggested... without success for the moment. I always have the std::bad_alloc issue.
Thanks a lot for making it possible. FF3 works great on my Octane2 (running 6.5.30), but I still have problems on my fuel (also 6.5.30). It is probably due to bad library paths and so on. I could identify pendant references to libgdk_pixbuf (now "ldd .../firefox'bin" gives no error anymore) and tried to renew .rqsfiles as ShadOfBlue suggested... without success for the moment. I always have the std::bad_alloc issue.
: oxygen (4xR12k400) /
: neon (16xI2 1.6, 9MB L2) /
: beryllium (4xR12k270)
: nitrogen (R16k800) / : carbon (2xR14k600) / : lithium (R10k400) / : fluorine (2xR12k300) / spare 2xR12k360
: hydrogen (R10k195) / : sodium (R5k180) / : R5k180->200 MB and PM only
: helium (R10k195, HighImpact) / : boron (R4k250)/ : magnesium (R4k100) / : aluminium (R5k180)
4D70GT : my very first one (now property of musée bolo and the foundation mémoires informatiques )
See the hinv/gfxinfo posts here .
: nitrogen (R16k800) / : carbon (2xR14k600) / : lithium (R10k400) / : fluorine (2xR12k300) / spare 2xR12k360
: hydrogen (R10k195) / : sodium (R5k180) / : R5k180->200 MB and PM only
: helium (R10k195, HighImpact) / : boron (R4k250)/ : magnesium (R4k100) / : aluminium (R5k180)
4D70GT : my very first one (now property of musée bolo and the foundation mémoires informatiques )
See the hinv/gfxinfo posts here .