911540 - Upgrading Firefox or Thunderbird Causes Loss of Connection

Status: RESOLVED WORKSFORME

(Core :: Networking, defect)

Description

[Yev]

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:25.0) Gecko/20130726 Firefox/25.0 (Nightly/Aurora)
Build ID: 20130726030203

Steps to reproduce:

If I try upgrading past version 25.0a1 with build id "20130726030203" any attempts to connect to a website fails. When upgrading to latest nightly the add-on check compatibility also fails as if there is no internet connection. All other browsers/apps work. I have Win 7 x64 and only have this problem on my desktop. I have another desktop and laptop with Win 7 x64 that connect through Wi-Fi and it shows no problem.


Actual results:

After realizing Firefox and Thunderbird just wouldn't successfully connect to anything I installed the last version that still worked 25.0a1 with build id "20130726030203" and no problems with this version. I then set the Update settings to never check for updates because then it would automatically install latest nightly and stop working again.


Expected results:

Firefox and Thunderbird should have updated to latest nightly and work normally.

Comment 1

[Loic]

Reinstall the build "20130726030203" with a clean profile and try to reproduce the issue, please.
https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles

Comment 2

[Yev]

I removed all profiles, uninstalled nightly, and reinstalled with a fresh build of "20130726030203". The issue is reproduced 100% of the time as soon as it upgrades to anything past this build. Previous builds work fine btw, only future builds stop working.

Comment 3

[Yev]

The same applies to daily/thunderbird

Comment 4

[Loic]

Can you install Nightly (see http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2013/09/ builds are in folder mozilla-central/) and check the issue is present. if you're not able to reproduce the issue on another machine, maybe there is something wrong with your hardware on that machine.

Comment 5

[Yev]

I've installed latest nightly issue is still present, although it's gotten somewhat better lately as it'll work once, but after nightly is closed, it never fully shuts down have to force end the task in task manager, and profile gets locked. 

Well whatever, you're not even trying to figure out this bug

here's latest crash report from trying a newer nightly

https://crash-stats.mozilla.com/report/index/5b546f48-8522-434c-994a-727c62130908

Might as well close this bug

Comment 6

[Loic]

The crash report is about the Flash plugin. Maybe just a false positive effect.

Comment 7

[Yev]

Sure it's a false positive because flash isn't the issue. New threads keep getting opened while old threads are not shut down properly. So the crash report just guessing what the problem is. there is something seriously wrong with the coding.

Comment 8

[u279076]

Anything you can tell us about your network configuration would be helpful. I can't reproduce this locally so I can only assume it's something about your configuration which is exposing this Firefox bug. Considering it happens with both Firefox and Thunderbird I suspect a recent change in the Necko back-end.

Resetting status flags until we have an internally reproducible test.

Comment 9

[u279076]

Based on the dates provided:

Last Good: 2013-07-26 (46d73e889cb4)
First Bad: 2013-07-27 (fb48c7d58b8b)
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=46d73e889cb4&tochange=fb48c7d58b8b

Unfortunately, nothing in that pushlog stands out to me. Maybe one of the Networking devs can have a look?

Comment 10

[Yev]

hm.. my network configuration on my desktop is probably not common. I have a broadcom netxtreme 5714G dual gigabit network card (pci-express) that is teamed as a 2gbps link. Was there any code added that tries to detect network interfaces? Maybe I can upgrade and run a dump file?

Comment 11

[Yev]

also would having programs such as Microsoft sdk 7.1, direct x sdk, visual studio 2010, and/or other dev tools affect the installation? obviously I'm downloading the executable already compiled and installing but maybe some symbol links or processes are affected? I know recently the entire build process for x64 version was changed to use visual studio 2010 and Windows sdk 8. I don't have these tools installed on other machines that aren't affected.I can always try adding a WiFi card on desktop and try upgrading through that since all other machines using Wi-Fi have no problem? what do you think?

Comment 12

[u279076]

(In reply to Yev from comment #11)
> also would having programs such as Microsoft sdk 7.1, direct x sdk, visual
> studio 2010, and/or other dev tools affect the installation? 

I don't think that should matter.

> I can always try adding a WiFi card on desktop and try upgrading
> through that since all other machines using Wi-Fi have no problem?

If that is the case then that would certainly point the finger at some conflict between Firefox and your specific configuration. That doesn't necessarily mean there isn't a Firefox bug but it will be hard to tell for sure without being able to reproduce it locally. I can't say for sure until one of our devs has a look at that push log to see if there are any leads.

Comment 13

[Yev]

okay it isn't my networking interface. Actually I can't even get that far anymore, latest nightly won't get back "Checking plugins for compatibility" even though when upgrading through nightly it already did a check, disabled one that was incompatible, and on restart still came up with the "checking plugins for compatibility" and never got past that. When I load firefox using the -P profile switch even the "checking plugins" screen doesn't come up and nothing at all happens.

Can you please check with one of the devs to do a pushlog between the two versions there HAS to be something causing this.

Comment 14

[Yev]

it might have nothing to do with networking, it really could be a problem in any number of areas...

Comment 15

[Yev]

I'm strongly suspecting something wrong with threads not closing properly and causing a loop

Comment 16

[Yev]

Same problem with Nightly version 27, doesn't get past the check plugin compatibility. Really doesn't make sense.

Comment 17

[u279076]

We can't track until we have a confirmed reproducible test and until a Firefox developer can provide some leads based on the regression range I'm at a loss.

Comment 18

[Yev]

I have more information regarding this problem, I tried latest nightly and it generated a good number of crash reports.

https://crash-stats.mozilla.com/report/index/6e70b5e1-5e13-4b66-beb1-673672130924
The raw dump looks bad, rewrites dlls

17|2|ole32.dll|TLSAddToMap(tagSOleTlsData *)|||0xa3 17|3|ole32.dll|CROIDTable::WorkerThreadLoop(void *)|||0x10 17|4|ole32.dll|CRpcThread::WorkerLoop()|||0x1e 17|5|ole32.dll|CRpcThreadCache::ResetTLS()|||0x2a 17|6|ole32.dll|CRpcThreadCache::RpcWorkerThreadEntry(void *)|||0x1a

etc...

31|6|xul.dll|nsHostResolver::GetHostToLookup(nsHostRecord * *)|hg:hg.mozilla.org/mozilla-central:netwerk/dns/nsHostResolver.cpp:f97307cb4c95|905|0xf 31|7|xul.dll|mozilla::Telemetry::Accumulate(mozilla::Telemetry::ID,unsigned int)|hg:hg.mozilla.org/mozilla-central:toolkit/components/telemetry/Telemetry.cpp:f97307cb4c95|2160|0xc 31|8|xul.dll|nsHostResolver::ThreadFunc(void *)|hg:hg.mozilla.org/mozilla-central:netwerk/dns/nsHostResolver.cpp:f97307cb4c95|1067|0xc

so somehow it updates all my host records to localhost or void?

Next bug report is
https://crash-stats.mozilla.com/report/index/cbb493b1-badb-405a-a9c8-14f662130924

again I see

17|2|ole32.dll|TLSAddToMap(tagSOleTlsData *)|||0xa3 17|3|ole32.dll|CROIDTable::WorkerThreadLoop(void *)|||0x10 17|4|ole32.dll|CRpcThread::WorkerLoop()|||0x1e 17|5|ole32.dll|CRpcThreadCache::ResetTLS()|||0x2a 17|6|ole32.dll|CRpcThreadCache::RpcWorkerThreadEntry(void *)|||0x1a

next one is
https://crash-stats.mozilla.com/report/index/8ea5dbb1-b29a-4dc6-9d18-b0b642130924

25|3|MMDevAPI.dll|NotifyAudiosrvStatusChange(void (*)(void *),void *,SC_HANDLE__ * *,_SERVICE_NOTIFY_2W *)|||0xa5 25|4|MMDevAPI.dll|CMediaNotifications::UnregisterMediaCallback(IMediaNotificationCallback *)|||0x187 25|5|kernel32.dll||||0x22ce3 25|6|user32.dll|UserCallWinProcCheckWow|||0x13b 25|7|MMDevAPI.dll|CDeviceEnumerator::PnpNotificationThread()|||0x420 25|8|user32.dll|RealMsgWaitForMultipleObjectsEx|||0xfd 25|9|user32.dll|UserCallWinProcCheckWow|||0x8f 25|10|user32.dll|DispatchMessageWorker|||0x12a 25|11|MMDevAPI.dll|CDeviceEnumerator::PnpNotificationThread()|||0x420 25|12|MMDevAPI.dll|memcmp|||0xe6c8 25|13|user32.dll|MsgWaitForMultipleObjectsEx|||0x2e 25|14|MMDevAPI.dll|CDeviceEnumerator::PnpNotificationThread()|||0x2ce 25|15|MMDevAPI.dll|CDeviceEnumerator::PnpNotificationThread()|||0x420 25|16|MMDevAPI.dll|memcmp|||0x52f8

basically same things in these...

https://crash-stats.mozilla.com/report/index/8ecc2694-7e91-49b1-b2d9-a565a2130924
https://crash-stats.mozilla.com/report/index/53b0eaa5-815d-49ae-9552-7f8362130924
https://crash-stats.mozilla.com/report/index/0a1fc7d3-9c23-4f25-a380-cb31a2130924
https://crash-stats.mozilla.com/report/index/093f6113-a9e9-4e10-966b-bebe62130924
https://crash-stats.mozilla.com/report/index/e0a4c83e-c7f8-44ad-8bb5-44ee92130924
https://crash-stats.mozilla.com/report/index/f77196c0-50d3-4060-b985-d98022130924

Comment 19

[u279076]

Based on these crash reports you are not using the latest Nightly, you are using Firefox 25.0a1 Nightly which is two versions behind.

Comment 20

[Yev]

You are not understanding this at all. ALL of these crashes are from the latest nightly, but as the bug states when using a newer version nightly has no internet connection, or more specifically messes up the dll files making them null. Obviously it'll say it's from 25.0a1 because like I've been saying the only way to get nightly to work again is to install the older version. Then guess what, all the crash reports get sent in since my profile is in tact

Comment 21

[Yev]

first crash report, please actually read it

Firefox 27.0a1 Crash Report [@ @0x0 | PL_DHashTableOperate | mozilla::FrameLayerBuilder::DrawThebesLayer(mozilla::layers::ThebesLayer*, gfxContext*, nsIntRegion const&, nsIntRegion const&, void*) ]

really it doesn't say newest nightly?

Comment 22

[u279076]

I had a second look at your reports and it seems like you are the only person reporting this signature. So at least the crash is a situation unique to you as far as I can tell. Perhaps you have a virus or malware on your system causing this problem. Could you run a scan to rule that out? Please also make sure all security software (virus scanners, firewalls, etc) are up to date and are working correctly (try disabling them temporarily to see if it resolves the issue).

Comment 23

[Yev]

Hm... I found a way to fix it. I uninstalled through windows, kept personal files. Then downloaded the latest nightly in the .zip format, and instead of running the installer I just dropped all the files in the empty nightly folder.

I also changed the following prefs 

gfx.content.azure.enabled	false
gfx.direct2d.disabled	true
gfx.font_rendering.directwrite.use_gdi_table_loading	false
gfx.font_rendering.graphite.enabled	false
gfx.work-around-driver-bugs	false

I think the problem is with my graphics card, an AMD 6970 (vender id 0x1002)

I saw this in the blocklist.xml, and 

<gfxBlacklistEntry  blockID="g192">      <os>WINNT 6.2</os>      <vendor>0x1002</vendor>            <feature>DIRECT2D</feature>      <featureStatus>BLOCKED_DRIVER_VERSION</featureStatus>      <driverVersion>9.10.8.0</driverVersion>      <driverVersionComparator>LESS_THAN_OR_EQUAL</driverVersionComparator>    </gfxBlacklistEntry>

My operating system is WINNT 6.1, but d3d10_1core.dll version is WINNT 6.2.

I guess you won't have too many of these situations, but for people with an AMD video card be careful when dealing with d3d10_1core.dll as it will report it's from WINNT 6.2, even if it's installed on WINNT 6.1

So, previously with direct3d on, I remember it was using Direct 3D 10.1. So anyway I updated to latest beta driver as well so that the driver version is higher than 9.10.8.0

Now in troubleshooting it shows

Graphics
Adapter Description	AMD Radeon HD 6900 Series
Adapter Drivers	aticfx64 aticfx64 aticfx64 aticfx32 aticfx32 aticfx32 atiumd64 atidxx64 atidxx64 atiumdag atidxx32 atidxx32 atiumdva atiumd6a atitmm64
Adapter RAM	2048
ClearType Parameters	Gamma: 2200 Pixel Structure: RGB ClearType Level: 100 Enhanced Contrast: 100
Device ID	0x6718
DirectWrite Enabled	false (6.2.9200.16571)
Driver Date	9-4-2013
Driver Version	13.200.11.0
GPU #2 Active	false
GPU Accelerated Windows	0/1 Basic
Vendor ID	0x1002
windowLayerManagerRemote	false
AzureCanvasBackend	skia
AzureContentBackend	none
AzureFallbackCanvasBackend	cairo
AzureSkiaAccelerated	0

So now it's using skia canvas and cairo as a fallback. Before it was direct2d for layers.

So... no more framelayerbuilder problems, and this is first time I'm seeing skia as the canvas backend, which is working nicely.

Comment 24

[Yev]

thanks for not much help : )