OS2 World Community Forum
OS/2, eCS & ArcaOS - Technical => Internet => Topic started by: Dariusz Piatkowski on December 17, 2019, 07:05:16 pm
-
FF 45.9, AMD Phenom build that Dave did a while back here.
For years I was running my FF configuration utilizing options that attempted to balance the page renderning speed given the available connection throughput. Well, I moved to Fibre about a year ago and other than a couple of small tweaks I didn't spend much time changing the previous configuration.
Well, having some spare time on my hands at the moment I decided to revisit this (I will do another post on this subject since the results I'm seeing here are very encouraging).
I have been using the 'Web Developer => Network' function to assess the impact various config:about changes have. Specifically how long do various connections take, what's coming out of cache vs. pure fetch.
This approach has worked very well for numeours destinations, however there is a specific site I use rather heavily that always causes a problem in this process however, that being https://www.cbc.ca/news (https://www.cbc.ca/news).
Here is a snippet from the crash report:
______________________________________________________________________
Exception Report - created 2019/12/15 00:47:44
______________________________________________________________________
OS2/eCS Version: 2.45
# of Processors: 5
Physical Memory: 3327 mb
Virt Addr Limit: 2560 mb
Exceptq Version: 7.11.3-shl (Jul 5 2016)
______________________________________________________________________
Exception C0000005 - Access Violation
______________________________________________________________________
Process: G:\APPS\TCPIP\FIREFOX\FIREFOX.EXE (12/28/2018 21:29:16 279,712)
PID: 12B (299)
TID: 01 (1)
Slot: BA (186)
Priority: 200
Module: XUL
Filename: G:\APPS\TCPIP\FIREFOX\XUL.DLL (12/28/2018 21:41:21 36,967,630)
Address: 005B:9B46ECFF (0001:032EECFF)
Cause: Attempted to read from 000000A8
(not a valid address)
______________________________________________________________________
Failing Instruction
______________________________________________________________________
9B46ECE4 SUB ESP, 0x1ec (81ec ec010000)
9B46ECEA MOV ESI, [ESP+0x200] (8bb424 00020000)
9B46ECF1 MOV EBX, [ESP+0x204] (8b9c24 04020000)
9B46ECF8 MOV EDI, [ESP+0x208] (8bbc24 08020000)
9B46ECFF >CMP BYTE [ESI+0x38], 0x0 (807e 38 00)
9B46ED03 JNZ 0x9b46ed0e (75 09)
9B46ED05 CMP BYTE [EBX+0xed], 0x0 (80bb ed000000 00)
9B46ED0C JZ 0x9b46ed24 (74 16)
______________________________________________________________________
Registers
______________________________________________________________________
EAX : 00000070 EBX : 2013CD80 ECX : 0019EE7C EDX : 00000000
ESI : 00000070 EDI : 0019EE7C
ESP : 0019EC60 EBP : 0019F0A4 EIP : 9B46ECFF EFLG : 00210206
CS : 005B CSLIM: FFFFFFFF SS : 0053 SSLIM: FFFFFFFF
EAX : not a valid address
EBX : read/write memory allocated by LIBCN0
ECX : read/write memory on this thread's stack
EDX : not a valid address
ESI : not a valid address
EDI : read/write memory on this thread's stack
______________________________________________________________________
Stack Info for Thread 01
______________________________________________________________________
Size Base ESP Max Top
00100000 001A0000 -> 0019EC60 -> 0011F000 -> 000A0000
______________________________________________________________________
I've attached the full trap file (zipped down to size). Not sure if this trap is readily recognizable, or whether this is one of these "deep in the bowels of the beast" type of a thing... ???
-
Unluckily the XQS files are missing so can't say much. Further, I lost the object tree in a HD crash so I don't have a copy of the XQS files.
Guess I could rebuild it if you want to post the optimize arguments I used, they'll be under about:buildconfig
-
Hey Dave!
...Guess I could rebuild it if you want to post the optimize arguments I used, they'll be under about:buildconfig...
Ohhh...like you didn't know I'be be all over that in a blink...LOL!
Here they are, and big Thank You!
about:buildconfig
Build platform
target
i386-pc-os2-emx
Build tools
Compiler Version Compiler flags
gcc.exe 5.5.0 -Wall -Wempty-body -Wpointer-to-int-cast -Wsign-compare -Wtype-limits -Wno-unused -Wcast-align -Zomf -std=gnu99 -fgnu89-inline -fno-strict-aliasing -Zomf -fno-math-errno -pthread
c++ 5.5.0 -idirafter g:/OS2TK45/h -Wall -Wempty-body -Woverloaded-virtual -Wsign-compare -Wwrite-strings -Wno-invalid-offsetof -Wcast-align -fno-exceptions -fno-strict-aliasing -Zomf -fno-rtti -fno-exceptions -fno-math-errno -std=gnu++0x -pthread -DNDEBUG -DTRIMMED -g -march=amdfam10 -O2 -fomit-frame-pointer
Configure arguments
--enable-application=browser '--enable-optimize=-mtune=generic -march=pentium-m -O2' '--enable-optimize=-march=amdfam10 -O2' --disable-debug --enable-debug-symbols --disable-tests --enable-os2-high-mem --without-x --enable-system-cairo --enable-system-pixman --with-intl-api --with-system-icu --with-system-zlib --with-system-nss --with-system-nspr --with-system-libvpx --disable-startupcache
Not sure how complex of an undertaking this is, but can you also include the fixes you published for the i686 and pentium4 builds a month ago (or thereabouts)?
In the meantime I'm going to try to separate out the trap to one of the elements in that capture, by default I'm picking up 'All, but that's a combination of:HTML, CSS, JS, HXR, Fonts, Images, Media, Flash & Other. Maybe it's just one of these that's the contributing factor to the crash?
-
Sure, building now, so later this afternoon it'll hopefully be done.
-
Sorry it took longer then expected, xpshell crashed with a sigill so had to disable the startup cache. Should be at https://bitbucket.org/dryeo/mozilla-os2/downloads/firefox-45.9.0.en.US.os2.SUa2.PhenomII.zip (https://bitbucket.org/dryeo/mozilla-os2/downloads/firefox-45.9.0.en.US.os2.SUa2.PhenomII.zip). Crashes here with a sigill as expected so needs testing.
-
Thanks Dave...will put it through the paces next!
-
Dave,
Same crash, which I think is good b/c now we have the additional information that was previously missing, please see attached file.
FYI, I went through the process of trying these captures one-by-one (as per my previous post), all resulted in a crash...so I'm thinking it's something at the back-end?
-
Seems to be timing related, script calling another while it is loading? I loaded cbc.ca/news about 2 dozen times and reproduced your crash twice. It's a big page and takes anywhere between 25 seconds and 210 seconds to load here and it only seemed to crash when loading faster then 25 seconds. The actual crash seems to be a missing callback but the code is more complicated then I can understand. It's in mozilla\js\src\vm\SavedStacks.cpp I believe. I notice a couple of tests involving it, which I assume passed for Bitwise.
-
Hey Dave!
Seems to be timing related, script calling another while it is loading? I loaded cbc.ca/news about 2 dozen times and reproduced your crash twice. It's a big page and takes anywhere between 25 seconds and 210 seconds to load here and it only seemed to crash when loading faster then 25 seconds...
Hmm, makes sense, the page actually loads in under 10 sec here, so probably a combination of the hardware (although not exactly any sort of blazing speed by today's standards lol) and the network speed (due to the 1Gig Fibre hookup).
Anyways, alright sir, thank you! I appreciate the time you spent to take a peek at this.
On another note, should I keep this version of FF as production-ready code? I am not sure what's involved in getting the additional debug info baked-in, but I wanted to utilize the fixes you put out in your last i686 and Pentim-M releases, and now that you built the Phenom version should I keep it?
-
Hey Dave!
On another note, should I keep this version of FF as production-ready code? I am not sure what's involved in getting the additional debug info baked-in, but I wanted to utilize the fixes you put out in your last i686 and Pentim-M releases, and now that you built the Phenom version should I keep it?
Sure, it should be at the same level as my last releases (might have screwed up the readme slightly). The XQS files are just built from the map files using a script Rich wrote some years back, the problem was in package-manifest.in, which lists what gets packaged.
-
Dave!
...should be at the same level as my last releases (might have screwed up the readme slightly). The XQS files are just built from the map files using a script Rich wrote some years back, the problem was in package-manifest.in, which lists what gets packaged.
I'm curious about something. This release had all the other DLLs iincluded. I had assumed this was the case since they were built using the same AMD family optimizations.
OK, so since I did not want to leave all these DLLs in the Firefox program directory I moved them out to \usr\local\lib. For FF purposes that was OK (\usr\local\lib is the 1st directory in my LIBPATH), however, things like ANPM fail, specifically that one complains of being unable to load the NSS library:
Executing: @python G:\UTIL\ANPM\scripts\yum_populate.py
error: Failed to initialize NSS library
Traceback (most recent call last):
File "G:\UTIL\ANPM\scripts\yum_populate.py", line 6, in <module>
import yum
File "/@unixroot/usr/lib/python2.7/site-packages/yum/__init__.py", line 23, in <module>
import rpm
File "/@unixroot/usr/lib/python2.7/site-packages/rpm/__init__.py", line 39, in <module>
from rpm.transaction import *
File "/@unixroot/usr/lib/python2.7/site-packages/rpm/transaction.py", line 5, in <module>
from rpm._rpm import ts as TransactionSetCore
ImportError: cannot import name ts
Return code: 0
Therefore, I moved the DLLs back into FF directory to avoid impacting the remainder of the system. This works so far, but begs the question of: do I not run into DLL conflicts now?
So FF will use it's own DLLs, but when things like ANPM run they will load them from the \usr\lib path, which is where they should be.
Now, maybe all this is a bit of a moot point, and maybe you built stuff like NSS from the latest releases which are currently showing up in netlabs-exp repo, and which i have not installed here?
What do you recommend as the preferred install?
FYI: I did try running just the core FF binaries with the current netlabs-rel DLLs, however that did cause some one-off crashes which i could not explain. So I am making the assumption the stuff in your FF release package must all go together and be used together.
-
Yes, I updated various security stuff (pins certs) and decided to compile and include NSPR and NSS (NSS is dependent on NSPR) so for this release should be left in the program directory. They're likely compiled with different options compared to the system ones which results in the incompatibilities.
As Firefox etc now have LIBPATHSTRICT and BEGINLIBPATH built in, there should be no DLL conflicts with the system ones though they will use a bit more memory so should have their read only bit turned off and marked to load the code high. I assume the read only attribute is for security.
The ones in exp are a bit questionable right now, I'm running with some more fixes and it is slightly unstable when using the updated NSS and NSPR, as well NSS breaks loading some HTTPS sites on 38ESR. Working on it but not much time currently which is why I built your Firefox from the same base as the other releases though it does have some experimental changes in the optimization flags
-
Hi Dave,
What you are doing with Firefox sounds to me like a step forward. At least I won't have to be careful with the DLL stupidity that I have to step round at the moment where some of the programs I use don't work with the latest DLLs.
Do you think it is worth my trying the version you did for Dariusz on my Ryzen machines, or is it too optimised for what he has?
-
Hi Ivan, I think it should work fine on a Ryzen CPU, worth testing anyways.