FF trap in Web Developer => Network function...

[Dariusz Piatkowski]

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.

Here is a snippet from the crash report:

Code: [Select]

______________________________________________________________________

 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...

[Dave Yeo]

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

[Dariusz Piatkowski]

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!

Code: [Select]

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?

[Dave Yeo]

Sure, building now, so later this afternoon it'll hopefully be done.

[Dave Yeo]

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. Crashes here with a sigill as expected so needs testing.

[Dariusz Piatkowski]

Thanks Dave...will put it through the paces next!

[Dariusz Piatkowski]

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?

[Dave Yeo]

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.

[Dariusz Piatkowski]

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?

[Dave Yeo]

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.

[Dariusz Piatkowski]

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:

Code: [Select]

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.

[Dave Yeo]

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

[ivan]

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?

[Dave Yeo]

Hi Ivan, I think it should work fine on a Ryzen CPU, worth testing anyways.