1123324 - Unable to find proxy server with Firefox 35

Status: RESOLVED FIXED

(Core :: Networking, defect)

Description

[Mukund Sivaraman]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:35.0) Gecko/20100101 Firefox/35.0
Build ID: 20150115144527

Steps to reproduce:

I run a HTTP proxy on a remote machine, and an SSH tunnel to this proxy from localhost:12345. This is set in Firefox as proxy configuration. Another way to say it would be:

export http_proxy=http://localhost:12345/ # is my proxy config

There is no HTTP proxy running on localhost. ssh instead forwards localhost:12345 to a port on the remote server where the HTTP proxy is actually running. The TCP connection for the SSH tunnel is fine and remote proxy is also fine.

This is a Linux x86_64 desktop running fully updated Fedora 21 in stock configuration. Up to Firefox 34, everything worked properly.

I upgraded to Firefox 35 on Fedora 21. The stock RPM version is firefox-35.0-3.fc21.x86_64. The user-agent is "Mozilla/5.0 (X11; Linux x86_64; rv:35.0) Gecko/20100101 Firefox/35.0". Now, at random intervals, I get the "Unable to find the proxy server" error page when opening links as new tabs. I can't find a way to reproduce this when I want it, but it happens every few minutes. This error page is displayed instantaneously when the tab opens. Reloading the tab causes the actual page to be loaded properly (through the proxy). The issue is not specific to the URL being loaded.

I don't know what other information I can share that will be useful for you to figure the cause. I am unable to reproduce the issue whenever I want to. But it happens randomly every few minutes, and is enough of a problem to me that I am reporting it here because I would like it fixed.




Actual results:

"Unable to find the proxy server" error is displayed.



Expected results:

Page should load in new tab without errors.

Comment 1

[Mukund Sivaraman]

BTW, that export statement was just to convey the proxy settings to you. The "http_proxy" env variable is not used with Firefox, and the proxy configuration is set in the network settings.

This proxy has worked for years this way, and worked till the upgrade to Firefox 35. Nothing relevant to this has changed in the environment. The only relevant change was the upgrade to Firefox 35.

Comment 2

[Loic]

Dupe of bug 1108971 I guess.

Comment 3

[:Gijs (he/him)]

Hmmmmm. That's odd. Some questions:

1) can you still reproduce on current nightly ( https://nightly.mozilla.org ) ?
2) if not (ie, fixed on nightly), can you reproduce on this nightly: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2015/01/2015-01-16-03-02-03-mozilla-central/firefox-38.0a1.en-US.linux-x86_64.tar.bz2

(if the answer to 1 and 2 is "no" and "yes" respectively, it got fixed in bug 1108971... but my hopes aren't too high as those seem to be proxy issues of a different kind... but proxies are weird, and that bug is one of our top issues for 35, so it seems worth trying)

Otherwise... does this happen often enough that you can run mozregression ( http://mozilla.github.io/mozregression/ ) to figure out when this broke, exactly?

Something like:

mozregression --good 2014-07-01

should work to figure out when this broke in Nightlies, and then it should be pretty straightforward for us to figure out what's going on.

Comment 4

[Mukund Sivaraman]

(In reply to :Gijs Kruitbosch from comment #3)
> Hmmmmm. That's odd. Some questions:
> 
> 1) can you still reproduce on current nightly ( https://nightly.mozilla.org

Yes it is reproducible on the current nightly.

> Otherwise... does this happen often enough that you can run mozregression (
> http://mozilla.github.io/mozregression/ ) to figure out when this broke,
> exactly?
> 
> Something like:
> 
> mozregression --good 2014-07-01
> 
> should work to figure out when this broke in Nightlies, and then it should
> be pretty straightforward for us to figure out what's going on.

It happens often enough that it matters to me that this bug is fixed.

I'll check this mozregression tool, but it'll be a while as newer nightlies disable some of the extensions I use (and regular browsing is unbearable without them from where I live).

Comment 5

[John Peterson]

This is just a "me too" comment, as I am experiencing the exact same problem.

Here is a summary of my situation that I posted to support.mozilla.com;

I have used firefox with a proxy server (Squid running on the same system as the browser) for many years without any problems until I upgraded to Firefox 35.0. Now I get an occassional "Unable to find Proxy server" message on a random basis (about 10% of the time, the other 90% of the time it works fine).

Summary of relevant info;

1) Firefox worked fine before the upgrade to 35.0, and I didn't touch a thing with the proxy server configuration or the firefox configuration. I just tried FF 35.0.1 and experienced the problem right away on restoration of a previous session.

2) The problem (seems) random, and happens about 10% of the time, and clicking "Retry" always works every time.

3) No problems connecting through proxy server with Chromium or other browsers.

4) Problem is exhibited on two different machines, one running Fedora 19, the other CentOS 6.6.
 
5) It seems to happen most often when restoring a session with multiple tabs, or when following a link by right click, then Open link in New Tab.

6) When the "Unable to find Proxy Server" message appears, it does so almost instantaneously after following a link, well under a second for sure.

Comment 6

[:Gijs (he/him)]

(In reply to John Peterson from comment #5)
> This is just a "me too" comment, as I am experiencing the exact same problem.
> 
> Here is a summary of my situation that I posted to support.mozilla.com;
> 
> I have used firefox with a proxy server (Squid running on the same system as
> the browser) for many years without any problems until I upgraded to Firefox
> 35.0. Now I get an occassional "Unable to find Proxy server" message on a
> random basis (about 10% of the time, the other 90% of the time it works
> fine).
> 
> Summary of relevant info;
> 
> 1) Firefox worked fine before the upgrade to 35.0, and I didn't touch a
> thing with the proxy server configuration or the firefox configuration. I
> just tried FF 35.0.1 and experienced the problem right away on restoration
> of a previous session.
> 
> 2) The problem (seems) random, and happens about 10% of the time, and
> clicking "Retry" always works every time.
> 
> 3) No problems connecting through proxy server with Chromium or other
> browsers.
> 
> 4) Problem is exhibited on two different machines, one running Fedora 19,
> the other CentOS 6.6.
>  
> 5) It seems to happen most often when restoring a session with multiple
> tabs, or when following a link by right click, then Open link in New Tab.
> 
> 6) When the "Unable to find Proxy Server" message appears, it does so almost
> instantaneously after following a link, well under a second for sure.

Can you please try running this through mozregression ( http://mozilla.github.io/mozregression/ ) to figure out when this regressed? That would really help narrow this down, especially considering how intermittent it already is...

Comment 7

[John Peterson]

I am 100% certain that the 2014-09-23 nightly build has the problem I described (associated symptoms were observed and is repeatable). The best test case I have found is to configure Firefox to restore the previous session, open about 5-10 tabs, close and then restart. To be specific, I am referring to the build; http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014/09/2014-09-23-03-02-04-mozilla-central/firefox-35.0a1.en-US.linux-x86_64.tar.bz2

I ran multiple tests on the 2014-09-22 nightly build, but never observed any symptoms (or with any of the earlier nightly builds I tried). Given the random nature of the symptoms, I can't be 100% certain the problem doesn't exist in that build, but it appears to not be there. To be specific, I am referring to; http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014/09/2014-09-22-03-02-04-mozilla-central/firefox-35.0a1.en-US.linux-x86_64.tar.bz2

Comment 8

[Loic]

Corresponding pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2014-09-22&enddate=2014-09-23

Comment 9

[Loic]

Could it be a side effect of:
Valentin Gosu — Bug 1011354 - Use a mutex to guard access to nsHttpTransaction::mConnection. r=mcmanus, r=honzab

    // Provides a thread safe reference of the connection

100 	

    // nsHttpTransaction::Connection should only be used on the socket thread

101 	

    already_AddRefed<nsAHttpConnection> GetConnectionReference();

Comment 10

[:Gijs (he/him)]

Sounds very plausible. Valentin?

Comment 11

[Patrick McManus [:mcmanus]]

(In reply to :Gijs Kruitbosch from comment #10)
> Sounds very plausible. Valentin?

it doesn't make obvious sense to me.. its just putting a lock around a racey access

Comment 12

[Valentin Gosu [:valentin] (he/him)]

Just in case, I did a try push with that patch backed out.
I'll provide the build to our reporters to confirm, but I'm also doubting that this patch is to blame.

Comment 13

[:Gijs (he/him)]

(In reply to Loic from comment #8)
> Corresponding pushlog:
> http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2014-09-
> 22&enddate=2014-09-23

Sadly, pushlog dates don't match nightly dates. Here's a pushlog based on the nightly revs for those days:

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=5bd6e09f074e&tochange=790f41c631cc

(In reply to Patrick McManus [:mcmanus] from comment #11)
> (In reply to :Gijs Kruitbosch from comment #10)
> > Sounds very plausible. Valentin?
> 
> it doesn't make obvious sense to me.. its just putting a lock around a racey
> access

OK - I definitely defer to your and Valentin's expertise as regards what could be involved. Is there something else in the pushlog that seems more plausible?

Comment 14

[:Gijs (he/him)]

(bug 1038756, perhaps?)

Comment 15

[Valentin Gosu [:valentin] (he/him)]

Mukund, John, could you try this build and see if the problem reproduces?
https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-d1205ff12bd7/try-linux64/firefox-38.0a1.en-US.linux-x86_64.tar.bz2

This is to rule out Bug 1011354
https://treeherder.mozilla.org/#/jobs?repo=try&revision=d1205ff12bd7

Comment 16

[John Peterson]

No joy, the problem is still there.

An observation about the problem that is worth repeating;

The "Unable to find Proxy Server" message appears quite quickly on the test case (fraction of a second). Given that, it seems (to me at least) quite unlikely that it's a timeout sort of problem where you wait, wait, and wait and wait for something that never happens.

Comment 17

[Dragana Damjanovic [:dragana]]

Can you give as a log, maybe it will be easier to find error.

https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging

Comment 18

[John Peterson]

Attachment: HTTP log file

I used the 2014-09-23 nightly build to generate these results. To be specific; the http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014/09/2014-09-23-03-02-04-mozilla-central/firefox-35.0a1.en-US.linux-x86_64.tar.bz2

The associated environment variable for logging was:
NSPR_LOG_MODULES=timestamp,nsHttp:5,nsSocketTransport:5,nsStreamPump:5,nsHostResolver:5

The URLS associated with the tabs where the error message appeared are:
https://startpage.com/
https://startpage.com/eng/protect-privacy.html?
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014/09/2014-09-23-03-02-04-mozilla-central/

Comment 19

[Valentin Gosu [:valentin] (he/him)]

Thanks for all the info. It's really useful.
We'll continue to investigate.

Comment 20

[Dragana Damjanovic [:dragana]]

Thanks John.
The log is very useful.
I thing the problem is the same patch as in bug 1108971, but the problem is different. There is a problem with check if entry in cache expires.

Comment 21

[John Peterson]

No problem.

For what it's worth, I configured Firefox to override the automatic (disk) cache management, and set the disk cache limit to zero bytes. (To force Firefox to get everything through the proxy).

Whatever is going wrong, I'm sure it's a subtle issue...

Comment 22

[Dragana Damjanovic [:dragana]]

Attachment: bug_1123324_v1.patch

Hi Steve.
Can you look at this patch if this make sense.
I think that this part was not quite right before patch in bug 1067679. And that John fix it in right direction but miss one part.
At
http://hg.mozilla.org/mozilla-central/annotate/08e41ea36f6d/netwerk/dns/nsHostResolver.cpp#l839
we check unspecHe whether it is expired and that is correct (it use to be 'he' which is I think wrong because we had checked it before and it had been expired already).
In
http://hg.mozilla.org/mozilla-central/annotate/08e41ea36f6d/netwerk/dns/nsHostResolver.cpp#l870
it is now checking he but expiration time for for this entry has not be updated.
Before patch in bug 1067679 it used to check only flags but not time.

Comment 24

[Ray Satiro]

As described in bug #1101776 which was just marked as a dupe this happens to me about several times a day in Nightly. I use e10s mostly. If there's anything I can do please let me know.

Comment 25

[Steve Workman [:sworkman] (INACTIVE)]

Comment on attachment 8555559 [details] [diff] [review]
bug_1123324_v1.patch

Review of attachment 8555559 [details] [diff] [review]:
-----------------------------------------------------------------

Yeah, this looks like it's incorrect. But I'm not sure if it caused the problem.

If there's an existing UNSPEC record in the cache, we'll copy it over for INET and INET6 requests, then we check to see if it's usable. But we don't copy expiration time. However, those timestamps *should* be set to 'null' according to the Timestamp constructor. So, HasUsableResult would always return false, right?

But I guess if we're not creating a new nsHostRecord, but using one that's already in the cache, we might have problems. 'he' might already be in the hash table and is just not usable itself; that's why we would have dropped down to check for 'unspecHe'. 'he' may already have timestamp values; so we'd end up with timestamps mismatched with 'negative' or 'addr_info's which have been copied from unspecHe. (Note: he->rec->addr_info is set to nullptr before we copy from unspecHe, so we don't need to worry about a hybrid list of addrs too).

Could this have caused problems? Well, it's not correct, so we should fix it anyway :)

ResolveHost wiould have passed on 'he' first because it failed HasUsableResult. There are several reasons why that function returns false.
After copying from 'unspecHe', if the timestamps are wrong, then HasUsableResult could have incorrectly returned either true or false.
-- HasUsableResult returns false incorrectly - this should result in a call to the OS resolver and should be ok.
-- HasUsableResult returns true incorrectly - the DNS entry would be returned, but it could be invalid.

Does this line up with what you were thinking?

I suggest fixing this and trying it.

Thanks Dragana!

::: netwerk/dns/nsHostResolver.cpp
@@ +209,5 @@
>      mValidEnd = now + TimeDuration::FromSeconds(valid + grace);
>  }
>  
> +void
> +nsHostRecord::SetExpirationTimes(const mozilla::TimeStamp& validStart,

How about just passing in the other nsHostRecord? Then you don't need the getter functions and the function signature is cleaner.

Maybe rename to CopyExpirationTimes?

@@ +897,5 @@
>                                              unspecHe->rec->addr_info->mCanonicalName);
> +                                        he->rec->SetExpirationTimes(
> +                                            unspecHe->rec->GetValidStart(),
> +                                            unspecHe->rec->GetValidEnd(),
> +                                            unspecHe->rec->GetGraceStart());

You can do this outside the while loop. There is one expiration time, but many addresses.

Comment 26

[Dragana Damjanovic [:dragana]]

(In reply to Steve Workman [:sworkman] (please use needinfo) from comment #25)
> Comment on attachment 8555559 [details] [diff] [review]
> bug_1123324_v1.patch
> 
> Review of attachment 8555559 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> Yeah, this looks like it's incorrect. But I'm not sure if it caused the
> problem.
> 

Looking at the log from comment 18 and pushlog (comment 13), I am certain that for one of the reporters this is the problem. I will ask them to try.

> If there's an existing UNSPEC record in the cache, we'll copy it over for
> INET and INET6 requests, then we check to see if it's usable. But we don't
> copy expiration time. However, those timestamps *should* be set to 'null'
> according to the Timestamp constructor. So, HasUsableResult would always
> return false, right?
> 

If first line 839 returns true and we do have a valid record in unspec because of the timestamps the second check will return false and that returns NS_ERROR_UNKNOWN_HOST instead of valid address or negative. And this return PROXY_NOT_FOUND in the log from comment 18.


> But I guess if we're not creating a new nsHostRecord, but using one that's
> already in the cache, we might have problems. 'he' might already be in the
> hash table and is just not usable itself; that's why we would have dropped
> down to check for 'unspecHe'. 'he' may already have timestamp values; so
> we'd end up with timestamps mismatched with 'negative' or 'addr_info's which
> have been copied from unspecHe. (Note: he->rec->addr_info is set to nullptr
> before we copy from unspecHe, so we don't need to worry about a hybrid list
> of addrs too).

Yes only the timestamps are the problem.

> 
> Could this have caused problems? Well, it's not correct, so we should fix it
> anyway :)

We should fix it.

> 
> ResolveHost wiould have passed on 'he' first because it failed
> HasUsableResult. There are several reasons why that function returns false.
> After copying from 'unspecHe', if the timestamps are wrong, then
> HasUsableResult could have incorrectly returned either true or false.
> -- HasUsableResult returns false incorrectly - this should result in a call
> to the OS resolver and should be ok.

This is not ok. If it returns false it will return NS_ERROR_UNKNOWN_HOST and a new resolve host will not be triggered. And in most cases it will return false because the timestamps are wrong. These he timestamps are the same as in line 776 which already return false. So if we have a record this check will return false always.

> -- HasUsableResult returns true incorrectly - the DNS entry would be
> returned, but it could be invalid.

In this case the entry will be return and looking at the code I think we do not check timestamps any more - I am not completely sure in this but anyway both cases are wrong.

> 
> Does this line up with what you were thinking?

Approximately :)
  
> 
> I suggest fixing this and trying it.
> 
> Thanks Dragana!
> 
> ::: netwerk/dns/nsHostResolver.cpp
> @@ +209,5 @@
> >      mValidEnd = now + TimeDuration::FromSeconds(valid + grace);
> >  }
> >  
> > +void
> > +nsHostRecord::SetExpirationTimes(const mozilla::TimeStamp& validStart,
> 
> How about just passing in the other nsHostRecord? Then you don't need the
> getter functions and the function signature is cleaner.

Thanks I will fix this.
> 
> Maybe rename to CopyExpirationTimes?
> 
> @@ +897,5 @@
> >                                              unspecHe->rec->addr_info->mCanonicalName);
> > +                                        he->rec->SetExpirationTimes(
> > +                                            unspecHe->rec->GetValidStart(),
> > +                                            unspecHe->rec->GetValidEnd(),
> > +                                            unspecHe->rec->GetGraceStart());
> 
> You can do this outside the while loop. There is one expiration time, but
> many addresses.

It is in if statement that will return true only once when addr_info is null so it is not repeated.

Comment 27

[Dragana Damjanovic [:dragana]]

Attachment: bug_1123324_v2.patch

Comment 28

[Dragana Damjanovic [:dragana]]

Can you please try this build:
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-a45cd2aa07e2/try-linux64/firefox-38.0a1.en-US.linux-x86_64.tar.bz2
or 
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-a45cd2aa07e2/try-linux/firefox-38.0a1.en-US.linux-i686.tar.bz2

(I do not know if you have 32 or 64)
John, if it does not work, can you send me log made with this build? 

Ray and Mukund can you try it too?

http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-a45cd2aa07e2/try-win64/firefox-38.0a1.en-US.win64-x86_64.installer.exe

Please download versions that you need.

Comment 29

[Markus Kopp]

I do have the same reaction on firefox startup since 35.0.The ip accessed during startup is 63.245.217.219.  After firefox is started the proxy settings are used.  This results in slow firefox startup, but after startup the proxy settings  work Means, i'm not sure if this is related.

Comment 30

[Dragana Damjanovic [:dragana]]

I am not sure that it is the same problem.
Can you please send me a log:
https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging

and I can look at it.

Comment 31

[Markus Kopp]

Hi Drgana, i have sent you PM with the trace.

Comment 32

[Dragana Damjanovic [:dragana]]

Description from comment 29 is not related to this bug.

I have opened bug  1128575.

Comment 33

[John Peterson]

(In reply to Dragana Damjanovic [:dragana] from comment #28)
> Can you please try this build:
> http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/dd.mozilla@gmail.
> com-a45cd2aa07e2/try-linux64/firefox-38.0a1.en-US.linux-x86_64.tar.bz2
> > ...
> John, if it does not work, can you send me log made with this build? 
> 

A bit of good news. This build seems to be working correctly for me (no error messages).

I ran my test of choice five times (restoring a saved session with 5-10 tabs), and everything worked just fine. I am a bit pressed for time at the moment, but I will run some more thorough tests later today when I break free.

Comment 34

[Mukund Sivaraman]

Thank you for all the efforts you are putting into fixing this bug. I have been reading comments on this ticket, but as this bug requires running Firefox for a prolonged period before the bug is reproduced, I was unable to test nightlies that were provided.

Instead I've compiled my system's Firefox version (firefox-35.0.1-3.fc21.x86_64) with the patch in comment #27 and this comment is made using that Firefox build. I'll keep running this and report in a couple of days if the bug is reproduced.

Comment 35

[Steve Workman [:sworkman] (INACTIVE)]

Comment on attachment 8557793 [details] [diff] [review]
bug_1123324_v2.patch

Review of attachment 8557793 [details] [diff] [review]:
-----------------------------------------------------------------

(In reply to Dragana Damjanovic [:dragana] from comment #26)
> (In reply to Steve Workman [:sworkman] (please use needinfo) from comment
> > Does this line up with what you were thinking?
> 
> Approximately :)

:) Thanks for your answers to my questions!

r=me with the changes below.

::: netwerk/dns/nsHostResolver.h
@@ +100,5 @@
>      // Convenience function for setting the timestamps above (mValidStart,
>      // mValidEnd, and mGraceStart). valid and grace are durations in seconds.
>      void SetExpiration(const mozilla::TimeStamp& now, unsigned int valid,
>                         unsigned int grace);
> +    void SetExpirationTimes(const nsHostRecord *aHostRecord);

const nsHostRecord * const aFromHostRecord

And just to be clearer..
s/SetExpirationTimes/CopyExpirationTimesFrom/
s/aHostRecord/aFromHostRecord/

Comment 36

[John Peterson]

(In reply to John Peterson from comment #33)
> (In reply to Dragana Damjanovic [:dragana] from comment #28)
> > Can you please try this build:
> > http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/dd.mozilla@gmail.
> > com-a45cd2aa07e2/try-linux64/firefox-38.0a1.en-US.linux-x86_64.tar.bz2
> > > ...
> > John, if it does not work, can you send me log made with this build? 
> > 
> 
> A bit of good news. This build seems to be working correctly for me (no
> error messages).

I just finished some more thorough testing of the above build and it is still worked perfectly for me. I did not seen any "Unable to find Proxy Server" messages.

I ran about 10 invocations of my test case (restoring a saved session with multiple tabs), which worked pretty well in my previous tests to determine which of the nighlty builds had the bug. Usually only 1 or 2 test runs were needed to expose the bug, on one ocassion it took 3 test runs.

I also gradually increasing the number of tabs in the saved session to 20 tabs. No problems with any of the test sessions, so I'm quite convinced the fix is in...

Comment 37

[Dragana Damjanovic [:dragana]]

Attachment: bug_1123324_v3.patch

Comment 38

[Mukund Sivaraman]

This error has not occurred so far with my patched build (with the patch from comment #27), so the patch seems to work. Thank you.

Comment 39

[Dragana Damjanovic [:dragana]]

Thanks Mukund and John!!!

Comment 40

[Dragana Damjanovic [:dragana]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=01f364d3110d

Comment 41

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/fe36fa405fc2

Comment 42

[Ray Satiro]

I have been using the build win64 a45cd2aa07e2 since yesterday and I am no longer seeing proxy not found messages. I have noticed one thing that no longer works as compared to 38.0a1 20150124030202.

https://www.openssl.org/source/
Right-click on openssl-1.0.2.tar.gz and choose 'Save Link As...' and nothing happens.

Comment 43

[Loic]

(In reply to Ray Satiro from comment #42)
> https://www.openssl.org/source/
> Right-click on openssl-1.0.2.tar.gz and choose 'Save Link As...' and nothing
> happens.

It's probably a different issue, maybe related to e10s in Nightly. Could you file a bug and paste the link here, please.

Comment 44

[Dragana Damjanovic [:dragana]]

I have tried it out, it is a different issue and it is only on e10s.

Comment 45

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/fe36fa405fc2

Comment 46

[Ray Satiro]

(In reply to Loic from comment #43)
> (In reply to Ray Satiro from comment #42)
> > https://www.openssl.org/source/
> > Right-click on openssl-1.0.2.tar.gz and choose 'Save Link As...' and nothing
> > happens.
> 
> It's probably a different issue, maybe related to e10s in Nightly. Could you
> file a bug and paste the link here, please.

Filed as bug #1129195.

Comment 47

[Mukund Sivaraman]

I got this error twice with the patched build today. The first time I thought I was dreaming, but this is clearly happening again. Once "Open link in new tab" causes the error page to appear in a new tab, opening the same link from current tab in more new tabs cause the same error to continue occurring in the newly opened tabs. When I reload the page in any one of the tabs, the error no longer occurs.

Comment 48

[Mukund Sivaraman]

Note that it doesn't occur so often as before with the unpatched build. I have only got this error at two times with the new build in over 2 days.

Comment 49

[Dragana Damjanovic [:dragana]]

Attachment: bug_1123324_additional_v3.patch

Comment 50

[Dragana Damjanovic [:dragana]]

Hi Mukund,

can you add the patch bug_1123324_additional_v3.patch as well. In previous patch I have miss some really rare case, so I am not sure that it is going to solve the problem. I will appreciate if you could test it. Thanks

Comment 52

[Dragana Damjanovic [:dragana]]

Comment on attachment 8559720 [details] [diff] [review]
bug_1123324_additional_v3.patch


The part of the code with unspecHe has never been uses before, so there a 2 changes to make it correct.
I forgot to set NS_ERROR_UNKNOWN_HOST if a found unspecHe record is negative.
mDoomed flag must be copied. Now I do not check HasUsableResult because it is copied to "he" record and it should be the same as unspecHe. Now I am checking only the difference. The previous patch was getting the TimeStamp two times so theoretically i could cause problems.

Comment 54

[Steve Workman [:sworkman] (INACTIVE)]

Comment on attachment 8559720 [details] [diff] [review]
bug_1123324_additional_v3.patch

Review of attachment 8559720 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks Dragana! All these corner cases you're finding!

Mostly sane. Check if you need to still call HasUsableResult. If not, please add more info to the comment to explain why you're not calling it.

::: netwerk/dns/nsHostResolver.cpp
@@ +875,5 @@
>                                  }
>                                  addrIter = addrIter->getNext();
>                              }
>                          }
> +                        // Now check if we have a new record.

I'm concerned that you still need to call HasUsableResult here. Could you create a temp var for 'now' and reuse it here to avoid timestamp issues?

@@ +881,3 @@
>                              result = he->rec;
> +                            if (he->rec->negative) {
> +                              status = NS_ERROR_UNKNOWN_HOST;

nit: indentation :)

Comment 55

[Dragana Damjanovic [:dragana]]

Attachment: bug_1123324_additional_v2.patch

I have not called HasUsableResult, because it is easy to miss it later (forgetting to extend CopyExpitarionTimeAndFlags if something changes in HasUsableResult)

But I am certain that both version with HasUsableResult check and the check in previous patch would give the same result. I have changed it: now HasUsableResult is used

Comment 56

[Steve Workman [:sworkman] (INACTIVE)]

Yeah - I was worried on the other side, that 'if (he->rec->addr_info || he->rec->negative)' would get out of sync if changes were made to HasUsableResult :)

Either way, I think it will be fine. Thanks Dragana!

Comment 57

[promeneur]

ipv4 pb

i set privoxy to use ipv4 .

i have also pb with ipv4 .
when i go to a webpage with embeded flash video then i must reload the page to get the button to authorize the flash plugin or the clickable picture to start viewing movie .

for example
http://www.lemonde.fr/ameriques/video/2015/02/11/aux-etats-unis-un-dirigeable-geant-inquiete-les-habitants_4574077_3222.html

Comment 58

[Dragana Damjanovic [:dragana]]

Can you upload or send me  log?

Comment 59

[Dragana Damjanovic [:dragana]]

I forgot to add this:
https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging

Comment 60

[promeneur]

Attachment: log.txt.tar.gz

opensuse 13.1 x86_64
firefox 35.0

log of  :

i go to www.lemonde.fr
then
in the "vidéos" bar i center click a clickable image of a video
then
the video page is loaded in a new tab
then
i must relaunch the video page to get the button to authorize the flash plugin

no pb if i left click

Comment 61

[Dragana Damjanovic [:dragana]]

Before asking you for a log I tried the web site on Mac and everything worked fine.

Later I tried it on linux and it does what you say it do (without proxy).

Just to be clear that we are talking about the same thing if I click-open in new tab on the work "Vidéos" the main video is not loaded?


In you log I have not seen any error in networking part.

Comment 62

[Dragana Damjanovic [:dragana]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=e6563d02c682

Comment 63

[promeneur]

(In reply to Dragana Damjanovic [:dragana] from comment #61)

> Just to be clear that we are talking about the same thing if I click-open in
> new tab on the work "Vidéos" the main video is not loaded?

yes

or

same result if you center click one of the three images

Comment 64

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/e8e048191f8b

Comment 65

[Dragana Damjanovic [:dragana]]

I think that comment #59 is a bit different issue so i will open another bug for that.

Bug 1132382.

Comment 66

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/e8e048191f8b

Comment 67

[Dragana Damjanovic [:dragana]]

Comment on attachment 8558371 [details] [diff] [review]
bug_1123324_v3.patch

Approval Request Comment
[Feature/regressing bug #]: bug 1067679
[User impact if declined]:Some times dns responses are host unknown when we actually have a valid response in the cache. It is only happening for IPv6. It can happen for any dns request but it is especially affecting users with a proxy because queries for the same address are more often.
[Describe test coverage new/current, TreeHerder]: comment #36, #38. Comment #47 notice the error again, this error should be fix with the second patch.
[Risks and why]: no risk. It is running already for 1-2 weeks.
[String/UUID change made/needed]:none

Comment 68

[Dragana Damjanovic [:dragana]]

Hi Mukund,
Have you had time to try the additional patch?

Comment 69

[Mukund Sivaraman]

Hi Dragana

(In reply to Dragana Damjanovic [:dragana] from comment #68)
> Have you had time to try the additional patch?

I wanted to but the code this patch is touching doesn't exist in Firefox 35. OTOH, I haven't run into this error again since that day using just the first patch.

(I cannot use a newer build of Firefox for a long period of time as I depend on other things in the environment. So I am useless in testing this in a non-release build as it is very rarely noticeable now. I'm sorry I'm not of much help in this case. If you are going to backport it to a Firefox 35 branch and have a patch against Firefox 35, I'll try it.)

Comment 70

[Dragana Damjanovic [:dragana]]

the second patch was depending on the previous one. 
If you have not notice this problem after comment #47 it would be hard to tell if the patch fixes it.
And the corner cases that the second patch fixes are to be expected to occur really rarely.

The patch is pending approval for Firefox 36.

Comment 71

[Dragana Damjanovic [:dragana]]

Comment on attachment 8562166 [details] [diff] [review]
bug_1123324_additional_v2.patch

Approval Request Comment
[Feature/regressing bug #]: bug 1067679
[User impact if declined]: It fixes corner cases of the patch  bug_1123324_v3.patch, which are believed to be the cause for the error described in comment #47.
[Describe test coverage new/current, TreeHerder]:
[Risks and why]: no risk. It is nightly for some days.
[String/UUID change made/needed]: none

Comment 72

[Sylvestre Ledru [:Sylvestre]]

Comment on attachment 8558371 [details] [diff] [review]
bug_1123324_v3.patch

That is very late in the 36 cycle, we already shipped 35 with this, afaik, it is GNU/Linux only, there is no unit tests, I am afraid we cannot take this patch.

Next time, please submit to tracking bugs like this ealier. I wasn't aware of this...

Comment 73

[Sylvestre Ledru [:Sylvestre]]

Comment on attachment 8562166 [details] [diff] [review]
bug_1123324_additional_v2.patch

But we can take those in aurora (aka 37).

Comment 74

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/fb2fd73e30ec
https://hg.mozilla.org/releases/mozilla-aurora/rev/467c6c571ea1

Comment 75

[promeneur]

opensuse 13.1 x86_64
FF 35.0
privoxy 3.0.23

using ipv4 only

a very similar case

i go to www.liberation.fr
then
the home page is badly loaded

see the beginning of the webpage there is a photo. see liberation_bad_loading10.png
but after and till the end of the page there is no photo. see liberation_bad_loading11.png and liberation_bad_loading12.png

Comment 76

[promeneur]

Attachment: liberation_bad_loading10.png

Comment 77

[promeneur]

Attachment: liberation_bad_loading11.png

look , there is a white square instead of a photo

Comment 78

[promeneur]

Attachment: liberation_bad_loading12.png

look there is a white square instead of a photo .

Comment 79

[Dragana Damjanovic [:dragana]]

Does it work without privoxy?
Maybe privoxy is blocking the content.

You can send me a log.

Comment 80

[promeneur]

(In reply to Dragana Damjanovic [:dragana] from comment #79)
> Does it work without privoxy?
> Maybe privoxy is blocking the content.
> 
> You can send me a log.

if i reload the page then no pb . it's a random and rare phenomenon . thus it is difficult to log it .

Comment 81

[Ray Satiro]

I just upgraded Nightly from 20150510030207 to 20150512030215 and I've seen a several sporadic 'Unable to find proxy server' messages similar to what I described in bug #1101776 which was marked as a duplicate of this. Fiddler proxy, which is the debugger I use, shows no record of any attempt at a connection when it happens. Is anyone else using the most recent Nightly, have you encountered the problem again?

Firefox
Version 	40.0a1
Build ID 	20150510030207
Built from https://hg.mozilla.org/mozilla-central/rev/77d92f6d7679

Firefox
Version 	41.0a1
Build ID 	20150512030215
Built from https://hg.mozilla.org/mozilla-central/rev/8b64c75b0b86

Comment 82

[:Gijs (he/him)]

(In reply to Ray Satiro from comment #81)
> I just upgraded Nightly from 20150510030207 to 20150512030215 and I've seen
> a several sporadic 'Unable to find proxy server' messages similar to what I
> described in bug #1101776 which was marked as a duplicate of this. Fiddler
> proxy, which is the debugger I use, shows no record of any attempt at a
> connection when it happens. Is anyone else using the most recent Nightly,
> have you encountered the problem again?
> 
> Firefox
> Version 	40.0a1
> Build ID 	20150510030207
> Built from https://hg.mozilla.org/mozilla-central/rev/77d92f6d7679
> 
> Firefox
> Version 	41.0a1
> Build ID 	20150512030215
> Built from https://hg.mozilla.org/mozilla-central/rev/8b64c75b0b86

I don't use a proxy and don't have the setup to retest this quickly. If you're continuing to see this on Nightly, please file a new bug and try to find an exact regression range. Please feel free to CC me on it.