Firefox - occasional trap but weird TRP file entry

[Dariusz Piatkowski]

So I'm using Dave's excellent FF 49.5 update (Sec #2 I think?). Pretty rock solid, although there does appear to be a slight regression in terms of saving certain types of files, where the tmp location FF uses never re-names the file to the final filename and instead keeps it in that *.*.part format. Anyways, no biggie, I know about it (normally happens when I d/l any Google Photos grouping of files and it's actually a ZIP file that's built).

Alright, but that's not the reason why I'm posting.

I just had one of these rare crashes, FF trapped and I found the following in the TRP file:

Code: [Select]

______________________________________________________________________

 Exception Report - created 2021/06/26 10:30:47
______________________________________________________________________

 LIBC: Killed by SIGSEGV

 Hostname:         NEUROBOX
 OS2/eCS Version:  2.45
 # of Processors:  6
 Physical Memory:  3199 mb
 Virt Addr Limit:  3072 mb
 Exceptq Version:  7.11.5-shl BETA8 (Jun  1 2020 18:37:02)

______________________________________________________________________

 Exception C0000005 - Access Violation
______________________________________________________________________

 Process:  G:\APPS\TCPIP\FIREFOX\FIREFOX.EXE (02/21/2021 11:47:09 72,434)
 PID:      5C (92)
 TID:      01 (1)
 Slot:     C3 (195)
 Priority: 200

 Module:   XUL
 Filename: G:\APPS\TCPIP\FIREFOX\XUL.DLL (02/21/2021 11:52:25 39,789,052)
 Address:  005B:BAB6EF7E (0001:02D2EF7E)
 Cause:    Attempted to read from 00000010
           (not a valid address)

______________________________________________________________________

 Failing Instruction
______________________________________________________________________

 BAB6EF6E  TEST EBP, EBP         (85ed)
 BAB6EF70  JZ   0xbab6f0b0       (0f84 3a010000)
 BAB6EF76  MOV  [ESP], EBP       (892c24)
 BAB6EF79  CALL 0xbab6b080       (e8 02c1ffff)
 BAB6EF7E >MOV  EAX, [EAX+0x10]  (8b40 10)
 BAB6EF81  MOV  EAX, [EAX+0x20]  (8b40 20)
 BAB6EF84  MOV  ECX, [EAX+0x10]  (8b48 10)
 BAB6EF87  TEST ECX, ECX         (85c9)
______________________________________________________________________

 Registers
______________________________________________________________________

 EAX : 00000000   EBX  : 0013D14C   ECX : 20C68FCC   EDX  : BA8CEA04
 ESI : 3F549020   EDI  : 0013D0BC
 ESP : 0013D090   EBP  : 20C68EE0   EIP : BAB6EF7E   EFLG : 00210206
 CS  : 005B       CSLIM: FFFFFFFF   SS  : 0053       SSLIM: FFFFFFFF

 EAX : not a valid address
 EBX : read/write memory on this thread's stack
 ECX : read/write memory allocated by LIBCN0
 EDX : read/exec  memory at 0001:02A9CA04 in XUL
 ESI : read/write memory allocated by LIBCN0
 EDI : read/write memory on this thread's stack

______________________________________________________________________

 Stack Info for Thread 01
______________________________________________________________________

   Size       Base        ESP         Max         Top
 00100000   00140000 -> 0013D090 -> 000CE000 -> 00040000

...

...but much further down when I see the list of DLLs that process was "aware" of I find the following:

Code: [Select]

...
______________________________________________________________________

 DLLs accessible from this process
______________________________________________________________________
....
BRWSRCMP b7d49000 0001c000 02/21/2021 11:53:01    108,314 G:\APPS\TCPIP\FIREFOX\BROWSER\COMPONENTS\BRWSRCMP.DLL
 LGPLLIBS b7d79000 0000f000 02/21/2021 11:46:07     75,290 G:\APPS\TCPIP\FIREFOX\LGPLLIBS.DLL
 MOZSQLT3 b7d99000 0009d000 02/21/2021 11:46:07    520,683 G:\APPS\TCPIP\FIREFOX\MOZSQLT3.DLL
 XUL      b7e49000 03c2d000 02/21/2021 11:52:25 39,789,052 G:\APPS\TCPIP\FIREFOX\XUL.DLL
...
 LGPLLIBS bba89000 0000f000 11/17/2020 00:43:25     74,292 G:\APPS\TCPIP\THUNDERBIRD\LGPLLIBS.DLL
 MOZSQLT3 bbaa9000 00098000 11/17/2020 00:43:15    510,726 G:\APPS\TCPIP\THUNDERBIRD\MOZSQLT3.DLL
 LDAP60   bbb69000 00020000 11/17/2020 00:48:04    119,571 G:\APPS\TCPIP\THUNDERBIRD\LDAP60.DLL
 XUL      bbb99000 03c7d000 11/17/2020 00:52:28 41,160,984 G:\APPS\TCPIP\THUNDERBIRD\XUL.DLL
...

You'll note that the very same DLLs are showing up that are actually loaded by either FF or THUNDERBIRD.

I was always under the impression that with the Mozilla suite of applications this should never be the case, meaning: the process will have visibility to it's own DLLs, which FF does, but would not see same named DLLs that were loaded by another process.

The above conclusion is based on the comments in both the FF and TB readmes that state the following:

Note:  Starting with Firefox 45.9.0 GA, it is not necessary to set LIBPATHSTRICT
       manually or using the Run! utility for it as this is done automatically
       by firefox.exe when loading XUL.DLL and other Mozilla DLLs.

So am I just misunderstanding what the TRP file shows as far as the listing of the DLLs being accessible by the process goes?

I did NOT expect FF to have any visibility to TB's DLLs, or vice versa.

If something needs to be done about this, there is always the option to use the README suggested program object parameter of:

Parameters:         /c set LIBPATHSTRICT=T & seamonkey.exe "%*"

...although I have not tried that approach yet, easy enough to do though.

[Dave Yeo]

You might want to try lowering your VIRTUALADDRESSLIMIT as with only 3199 MB's of ram accessible, there isn't much of a cushion. Perhaps try 2560 for a while.
As for the DLLs accessible thing, I don't remember seeing that, but don't usually look.
Hmm, looking at the few trps I have, the one SM trp doesn't even list the DLLs, or some other stuff, like it got cut off. The TB traps only show calbscmp.dll (calendar extension dll) from the profile and FF doesn't show any from the profile.
This brings up the question of what have you changed on your system lately. Seems I saw an exceptq update and then there was that thing that we were discussing on the testers list that David wanted a testlog for. That might be the culprit, it's a shame you don't properly test on ArcaOS.
BTW, looking at a trp file produced last night by Python2.7, I do see something new in the DLLs accessible from the system

Code: [Select]

DOSCALLS                   06/15/2021 16:58:09    870,886 W:\OS2KRNL


[Dave Yeo]

For anyone following along, these changes are in exceptq, eg from history,

Thu Apr 23 20:18:24 2020  Steven H. Levine <steve53@earthlink.net>
        * exceptq.dll v7.11.5-shl BETA2
          Search for .xqs files before .sym files.
          Report DLLs loaded in high-memory.
          Report address and size of loaded DLLs (1st code object only).
          Report OS2KRNL timestamp and size.

...

[Dariusz Piatkowski]

Dave,

I lowered the setting to 2560 (which is what I used to run some time ago) so I'm curious if this will impast stability in any way.

Regardless, I responded to Steven on our Testers List suggesting that in the TRP output file we split out the process specific DLLs from the high-memory, and therefore system-wide DLLs.

Either way, I also reverted back to 202 kernel because 203 was certainly causing me problems here. As you commented in your post though, my testing being done outside of AOS is only relevant to a certain extent.

However, with all due respect I have to disagree with your "...it's a shame you don't properly test on ArcaOS..." comment. I think AOS is missing a huge opportunity by relegating two AOS pathways to the back of the queue, those being:

1) Software Subscription - this was initially in place, I am not sure if that offering exists anymore
2) Upgrade Path - I'm not certain how many stand-alone users can, or are willing to completely start with a clean-slate approach, that being a fresh re-install and the unenviable attempt to bring the relevant data over to the new system

I will say this again, and I have been very open about this: if I have to re-install from scratch, I will probably depart from our beloved OS/2 platform and carry on elsewhere. There simply is that much accumulated content I currently have, where it would make no sense to re-create all of it. It is much easier to build a new cutting-edge solution and replicate my existing OS/2 install within a VM...so much simpler, faster and much less pain.

In fact I wish there was a sub-team focused on doing the sort of testing I regularly do: see if the currently delivered changes still work on the "old" OS/2 config, as well as perhaps even introducing additional functionality. Heck, this could be entirely volunteer driven effort since the subset of the AOS functionality that could continue to filter out under the 'Software Subscription' option is a much smaller and managable bucket, and those releases could remain completely outside of the main AOS code-base trunk, thus would have very little impact on the pure AOS stuff.

[Dave Yeo]

Well, ideally you would have an ArcaOS install that you use occasionally so if you find a problem, you can double check on ArcaOS.
It is good for you to test the stuff available by subscription as that is targeted at Warp V4 and newer, some stuff like the kernel has a more restrictive license, so blame IBM and Arca Noae having to accept that for the right to patch the kernel.