I am having issues with Firefox 44.0 and 45.0.1 crashing repeatedly. Was happening on Windows 7 Enterprise and now on Windows 10 Educational.

RESOLVED INVALID

Status

()

Core
Networking: DNS
--
critical
RESOLVED INVALID
2 years ago
2 years ago

People

(Reporter: NaturalNerd, Assigned: valentin)

Tracking

({crash, crashreportid})

44 Branch
x86_64
Windows 10
crash, crashreportid
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: hardware-failure, crash signature)

(Reporter)

Description

2 years ago
User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:44.0) Gecko/20100101 Firefox/44.0
Build ID: 20160210153822

Steps to reproduce:

I have reinstalled fresh, uninstalling folder in C:\Program Files (x86) as well. I have installed 44.0 and 45.0.1


Actual results:

Here are my crash results. I have not installed any extensions yet:

https://crash-stats.mozilla.com/report/index/8ddaeefe-c79d-4609-b191-ae92d2160406
https://crash-stats.mozilla.com/report/index/6e361198-907b-4ae7-af74-603ed2160406
https://crash-stats.mozilla.com/report/index/020431c8-d459-4769-8fc8-be4f82160406
https://crash-stats.mozilla.com/report/index/830423da-a182-4cb8-8b8f-e79a72160406
https://crash-stats.mozilla.com/report/index/a5fe1d06-f109-49e2-bb72-ee3d82160406
https://crash-stats.mozilla.com/report/index/5943740e-2380-4021-9294-32a402160406
(Reporter)

Updated

2 years ago
OS: Unspecified → Windows 10
Hardware: Unspecified → x86_64

Updated

2 years ago
Crash Signature: [@ mozilla::EventListenerChange::~EventListenerChange ]
Component: Untriaged → DOM: Events
Keywords: crash, crashreportid
Product: Firefox → Core
There is no call to EventListenerChange::~EventListenerChange from mozilla::net::NetAddrToString.
The link from the crash stack (in the last URL above) points at the call to inet_ntop_internal:
https://hg.mozilla.org/releases/mozilla-release/annotate/e0e51efe7b15/netwerk/dns/DNS.cpp#l106
Is it possible it might have overwritten the stack somehow?
Group: core-security
Severity: normal → critical
Component: DOM: Events → Networking: DNS
(Reporter)

Comment 2

2 years ago
I am not sure how I would have overwritten the stack when each reinstall was fresh.
(Reporter)

Comment 3

2 years ago
Also, the first crash was on the first, fresh install of Firefox on a fresh install of Windows 10 64bit.
(Reporter)

Comment 4

2 years ago
The Windows 7 crashes were also on a fresh install of Windows 7 Enterprise 64 bit (just installed yesterday). After installing Firefox 45.0.1., it immediately crashed with the EventListenerChange error. After some troubleshooting, I wiped the hdd again and repeated and had the same issue. I then changed the hdd and installed Windows 10 educational (trying to start with a completely clean slate). I installed Firefox 45.0.1 and it crashed with the same error. I then removed all instances of Firefox (making sure to follow the steps per instructions on the Mozilla website), and installed 44.0 from the website. This time everything was working fine for about 10 mins, and then Firefox started crashing again with the EventListener error. This is when I submitted the ticket. I don't know how it could be the OS after trying on two different ones, but I can get a fresh copy of the OS, install from a different media, and try again. I honestly don't think that will solve the issue, but am will to try anything at this point.
I didn't mean to imply you did anything wrong.  I'm saying that it might be a bug in our
networking code or something.
Since the crash is fairly reproducible, then perhaps the networking guys
might want to work with the reporter to investigate this more closely?
Flags: needinfo?(mcmanus)
valentin, would you be available to take a look?
Flags: needinfo?(mcmanus) → needinfo?(valentin.gosu)
(Assignee)

Comment 8

2 years ago
I took a look at the minidumps:
	xul.dll!mozilla::EventListenerChange::~EventListenerChange() Line 34	C++
 	[External Code]	
 	[Frames below may be incorrect and/or missing]	
 	xul.dll!nsSocketTransport::SendStatus(nsresult status) Line 1001	C++
 	xul.dll!nsSocketTransport::InitiateSocket() Line 1383	C++
 	xul.dll!nsSocketTransport::OnSocketEvent(unsigned int type, nsresult status, nsISupports * param) Line 1809	C++
 	...

So the stack traces might not be very helpful. If the reporter is willing to help with debugging this issue, that would be great!

First of all, bug 1257309 mentions that DRAM issues might cause frequent instability, so we need to make sure that's not the case by running http://www.memtest86.com/

Secondly, I'd like to get some logs for this. @NaturalNerd do you think you could gather some logs?
The instructions are here: https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging
Note, that the log could grow very quickly, so if it doesn't crash in the first few minutes, you should close the browser and try again.

Thanks!
Assignee: nobody → valentin.gosu
Flags: needinfo?(kena)
(Reporter)

Comment 9

2 years ago
(In reply to Valentin Gosu [:valentin] from comment #8)
> I took a look at the minidumps:
> 	xul.dll!mozilla::EventListenerChange::~EventListenerChange() Line 34	C++
>  	[External Code]	
>  	[Frames below may be incorrect and/or missing]	
>  	xul.dll!nsSocketTransport::SendStatus(nsresult status) Line 1001	C++
>  	xul.dll!nsSocketTransport::InitiateSocket() Line 1383	C++
>  	xul.dll!nsSocketTransport::OnSocketEvent(unsigned int type, nsresult
> status, nsISupports * param) Line 1809	C++
>  	...
> 
> So the stack traces might not be very helpful. If the reporter is willing to
> help with debugging this issue, that would be great!
> 
> First of all, bug 1257309 mentions that DRAM issues might cause frequent
> instability, so we need to make sure that's not the case by running
> http://www.memtest86.com/
> 
> Secondly, I'd like to get some logs for this. @NaturalNerd do you think you
> could gather some logs?
> The instructions are here:
> https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging
> Note, that the log could grow very quickly, so if it doesn't crash in the
> first few minutes, you should close the browser and try again.
> 
> Thanks!

Sure - I can grab these tomorrow morning (EST).
Flags: needinfo?(kena)
Restoring the needinfo? for the reporter until the requested info is grabbed so it's clear who is waiting for what.
Group: core-security → network-core-security
Flags: needinfo?(kena)
(Reporter)

Comment 11

2 years ago
Sorry about that. I setup the computer to create logs on Friday, but by end of day had other hardware issues and am now having issues with booting. I will close this ticket as there are other issues at play and cannot get back in at this point to try to grab logs. Thanks for the assistance.
Flags: needinfo?(kena)
(Reporter)

Updated

2 years ago
Status: UNCONFIRMED → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WONTFIX
(Assignee)

Comment 12

2 years ago
Sorry to hear about your hardware problems. Please feel free to report any other issues you may encounter in the future.
Have a nice day!
Flags: needinfo?(valentin.gosu)
Resolution: WONTFIX → INVALID
Whiteboard: hardware-failure
Group: network-core-security
You need to log in before you can comment on or make changes to this bug.