Author Topic: Firefox trap.  (Read 6757 times)

Remy

  • Hero Member
  • *****
  • Posts: 645
  • Karma: +9/-1
    • View Profile
Firefox trap.
« on: February 06, 2021, 11:57:00 am »
Hi !

I just had following trap into Firefox 45.9.0-SUa2 (2019-05-20)
Any idea about what happens ?

 Filename: W:\PROGRAMS\FIREFOX\XUL.DLL (06/02/2019 18:00:05 39,105,957)
 Address:  005B:AB8A86F2 (0001:029286F2)
 Cause:    Attempted to read from 00000010
           (not a valid address)

______________________________________________________________________

 Failing Instruction
______________________________________________________________________

 AB8A86E2  MOV  [ESP], EDX       (891424)
 AB8A86E5  MOV  [ESP+0x1c], EDX  (895424 1c)
 AB8A86E9  CALL 0xab8a6730       (e8 42e0ffff)
 AB8A86EE  MOV  EDX, [ESP+0x1c]  (8b5424 1c)
 AB8A86F2 >MOV  EAX, [EAX+0x10]  (8b40 10)
 AB8A86F5  MOV  EAX, [EAX+0x20]  (8b40 20)
 AB8A86F8  MOV  EDI, [EAX+0x10]  (8b78 10)
 AB8A86FB  TEST EDI, EDI         (85ff)

______________________________________________________________________

 Registers
______________________________________________________________________

 EAX : 00000000   EBX  : 0019D8EC   ECX : 3330622C   EDX  : 33306140
 ESI : 34E67420   EDI  : 34E67538
 ESP : 0019D850   EBP  : 0019D87C   EIP : AB8A86F2   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/write memory allocated by LIBCN0
 ESI : read/write memory allocated by LIBCN0
 EDI : read/write memory allocated by LIBCN0

______________________________________________________________________

 Stack Info for Thread 01
______________________________________________________________________

   Size       Base        ESP         Max         Top
 00100000   001A0000 -> 0019D850 -> 0015E000 -> 000A0000

______________________________________________________________________

 Call Stack
______________________________________________________________________

   EBP     Address    Module     Obj:Offset    Nearest Public Symbol
 --------  ---------  --------  -------------  -----------------------
 Trap  ->  AB8A86F2   XUL       0001:029286F2  between nsDocShell::GetOriginAttributes + 52 and nsDocShell::CreatePrincipalFromReferrer - 16E  (both in Unified_cpp_docshell_base0.cpp)

 0019D87C  201424E0   *Unknown*

 33306140  AB8BA0DC   XUL       0001:0293A0DC  between nsDocShell::{vtable} + 534 and nsQueryObject::{vtable} - 6E0  (both in Unified_cpp_docshell_base0.cpp)

 AB8B9BB0  AB8A1870   XUL       0001:02921870  nsDocShell::AddRef  (in Unified_cpp_docshell_base0.cpp)

 Lost Stack chain - new EBP below previous

______________________________________________________________________

Regards
Rémy
« Last Edit: February 06, 2021, 11:59:06 am by Remy »

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4786
  • Karma: +99/-1
    • View Profile
Re: Firefox trap.
« Reply #1 on: February 06, 2021, 05:37:30 pm »
Doesn't look familiar. Was it a one off or repeatable?

Remy

  • Hero Member
  • *****
  • Posts: 645
  • Karma: +9/-1
    • View Profile
Re: Firefox trap.
« Reply #2 on: February 06, 2021, 06:09:19 pm »
Doesn't look familiar. Was it a one off or repeatable?

I've got it 4 times since first January 2021.
But i could not indentify in which conditions it happens

Today, I updated ff to the latest build and got again a trap.


 Exception Report - created 2021/02/06 13:44:36
______________________________________________________________________

 OS2/eCS Version:  2.45
 # of Processors:  4
 Physical Memory:  3470 mb
 Virt Addr Limit:  2816 mb
 Exceptq Version:  7.11.3-shl (Jul  5 2016)

______________________________________________________________________

 Exception C0000005 - Access Violation
______________________________________________________________________

 Process:  W:\PROGRAMS\FIREFOX\FIREFOX.EXE (11/11/2020 21:59:20 74,241)
 PID:      6C (108)
 TID:      01 (1)
 Priority: 200

 Filename: W:\PROGRAMS\FIREFOX\XUL.DLL (11/11/2020 22:08:01 41,073,853)
 Address:  005B:AB848BAA (0001:02C38BAA)
 Cause:    Attempted to read from 00000010
           (not a valid address)

______________________________________________________________________

 Failing Instruction
______________________________________________________________________

 AB848B9A  TEST EBP, EBP         (85ed)
 AB848B9C  JZ   0xab848ce8       (0f84 46010000)
 AB848BA2  MOV  [ESP], EBP       (892c24)
 AB848BA5  CALL 0xab844da0       (e8 f6c1ffff)
 AB848BAA >MOV  EAX, [EAX+0x10]  (8b40 10)
 AB848BAD  MOV  EAX, [EAX+0x20]  (8b40 20)
 AB848BB0  MOV  ECX, [EAX+0x10]  (8b48 10)
 AB848BB3  TEST ECX, ECX         (85c9)

______________________________________________________________________

 Registers
______________________________________________________________________

 EAX : 00000000   EBX  : 0013C87C   ECX : 20F33E0C   EDX  : AB5B8B84
 ESI : 2DEC3300   EDI  : 0013C7EC
 ESP : 0013C7C0   EBP  : 20F33D20   EIP : AB848BAA   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:029B0B84 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 -> 0013C7C0 -> 00114000 -> 00040000

______________________________________________________________________

 Call Stack
______________________________________________________________________

   EBP     Address    Module     Obj:Offset    Nearest Public Symbol
 --------  ---------  --------  -------------  -----------------------
 Trap  ->  AB848BAA   XUL       0001:02C38BAA  between nsDocShell::GetOriginAttributes + 4A and nsDocShell::CreatePrincipalFromReferrer - 166  (both in Unified_cpp_docshell_base0.cpp)

 20F33D20  AB85A21C   XUL       0001:02C4A21C  between nsDocShell::{vtable} + 534 and nsQueryObject::{vtable} - 6E0  (both in Unified_cpp_docshell_base0.cpp)

 AB859CF0  AB83F740   XUL       0001:02C2F740  nsDocShell::AddRef  (in Unified_cpp_docshell_base0.cpp)

 Lost Stack chain - new EBP below previous

______________________________________________________________________

« Last Edit: February 06, 2021, 06:13:46 pm by Remy »

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4786
  • Karma: +99/-1
    • View Profile
Re: Firefox trap.
« Reply #3 on: February 06, 2021, 06:20:57 pm »
Which build are you using? If the Pentium M, you might want to test the i686 one. Seems there are optimization problems with the Pentium M one, I need to upload new builds and haven't got around to it.
And of course a repeatable situation would be good, especially after testing with a new profile.

Remy

  • Hero Member
  • *****
  • Posts: 645
  • Karma: +9/-1
    • View Profile
Re: Firefox trap.
« Reply #4 on: February 06, 2021, 06:33:54 pm »
Which build are you using? If the Pentium M, you might want to test the i686 one. Seems there are optimization problems with the Pentium M one, I need to upload new builds and haven't got around to it.
And of course a repeatable situation would be good, especially after testing with a new profile.

It is the i686 one.
My system has an I7 970 cpu

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4786
  • Karma: +99/-1
    • View Profile
Re: Firefox trap.
« Reply #5 on: February 06, 2021, 07:53:42 pm »
Well, as usual, need to test with a new profile or at least in safe mode.

Remy

  • Hero Member
  • *****
  • Posts: 645
  • Karma: +9/-1
    • View Profile
Re: Firefox trap.
« Reply #6 on: February 06, 2021, 09:54:29 pm »
Well, as usual, need to test with a new profile or at least in safe mode.

With a new profile already done but not in safe mode.
I'll try it for a few days.

Regards
Rémy