Firefox - occasional trap but weird TRP file entry

OS/2, eCS & ArcaOS - Technical > Web applications

(1/1)

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: ---______________________________________________________________________

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

...

--- End code ---

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

--- Code: ---...
______________________________________________________________________

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

--- End code ---

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:

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

--- End quote ---

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: ---DOSCALLS 06/15/2021 16:58:09 870,886 W:\OS2KRNL

--- End code ---

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

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

--- End quote ---
...

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.

Navigation

[0] Message Index

Go to full version