Closed Bug 1136775 Opened 9 years ago Closed 9 years ago

Firefox 36 doesn't load pages with XP SP2

Categories

(Core :: Networking: HTTP, defect)

Product:
Core
Component:
Networking: HTTP
Version:
36 Branch
Platform:
x86_64
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1138070

People

(Reporter: frederic, Unassigned)

References

Details

(Keywords: regression)

Attachments

(5 files)

pb_firefox_xp_sp2.jpg
354.46 KB, image/jpeg
Details
log.txt.zip
239.79 KB, application/zip
Details
Log file archived with WinZip
117.79 KB, application/x-stuffit
Details
log2.txt.zip
128.79 KB, application/zip
Details
log.txt
2.38 MB, text/plain
Details
Attached image pb_firefox_xp_sp2.jpg — 
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:35.0) Gecko/20100101 Firefox/35.0
Build ID: 20150125222008

Steps to reproduce:

When i update Firefox in Windows XP SP2, after udpate Firefox don't work.  Never http sites, internet or intranet works.


Actual results:

not  work.  I'm  block update.
Reporter: Do you have a proxy server configured ?
Component: Untriaged → Networking: HTTP
Flags: needinfo?(frederic)
Product: Firefox → Core
Summary: Firefox 36 don't work with XP SP2 → Firefox 36 don't load pages with XP SP2
Firefox 36 is the first version built with MSVS 2013.
Blocks: 1023941
Keywords: regression
So do anyone know what percentage of users that connects to Firefox update servers still use XP SP2?
I don't think this is related to bug 1023941. The browser would not be able to reach the about-dialog if that code were failing.
Fair enough.
No longer blocks: 1023941
See Also: → 1136673
There is two additional reports:
http://forums.mozfr.org/viewtopic.php?f=5&t=123088 (both french)
http://forums.mozfr.org/viewtopic.php?f=5&t=123108

This is an important regression. Tracking.
Status: UNCONFIRMED → NEW
status-firefox36: --- → affected
status-firefox37: --- → affected
tracking-firefox36: --- → +
tracking-firefox37: --- → +
Ever confirmed: true
Summary: Firefox 36 don't load pages with XP SP2 → Firefox 36 doesn't load pages with XP SP2
hard to do much without some info

1] can you reach about:buildconfig (an above comment references about: but I don't see any information in this bug about it)

2] start with an http_log and attach the results to this bug after you try and connect to a site and fail to do so. That ought to help us figure out more.
Could you provide instructions on how to get that http_log for those who aren't familiar?
Flags: needinfo?(mcmanus)
(In reply to Matthias Versen [:Matti] from comment #1)
> Reporter: Do you have a proxy server configured ?

No, not proxy, simply, automatic update.  before Ok, and now no connection. the web page not display.
tomorrow i test if problem persist, and if you want i can test all procedures to solve this.
Flags: needinfo?(frederic)
XP Pro SP3
No proxy
Set to use system  connection configuration. 
Crash reports fail 'cuz they can not connect to the net.
Removing and reinstalling  did not change anything. How can I attach a log file?
Attached file log.txt.zip — 
This log.txt 
OS Version  WIndows XP 32 Version 5.1  SP2
This may be related to bug 1093983 - I say that because it looks like DNS requests are failing in the log (attachment 8571227 [details]). One of the commenters in bug 1093983 suggested that certain DNS resolvers block clients that send type 'ANY' requests. This was, of course, news to us and we hadn't seen any failures yet.

To be sure, please go to "about:config". Search for network.dns.get-ttl and set it to false. Retry connecting to a site, and please report back here.
If Steve is right in comment 19, then the good news is that this is both 1) rare enough that it didn't happen on the /aurora/beta trainride; and 2) a bug that we could theoretically work-around with a pref hotfix.  The bad news is that without connectivity there's no hotfix, so the only way for affected users is to download a new binary :(
Note that ISPs could also fix this, by changing/upgrading their DNS servers to not fail when they see ANY queries.

Since ANY was being used on all versions of Windows IIUC, it's entirely possible this bug isn't specific to SP2.
benpowell@torchlake, you would follow the instructions for saving the http log file in comment 9, then on this page in bugzilla.mozilla.org, click "Add an attachment" (https://bugzilla.mozilla.org/attachment.cgi?bugid=1136775&action=enter)  and upload the file. Thanks for the help!
Flags: needinfo?(benpowell)
Flags: needinfo?(benpowell)

    
    

    
  
(In reply to Liz Henry :lizzard from comment #22)
> benpowell@torchlake, you would follow the instructions for saving the http
> log file in comment 9, then on this page in bugzilla.mozilla.org, click "Add
> an attachment"
> (https://bugzilla.mozilla.org/attachment.cgi?bugid=1136775&action=enter) 
> and upload the file. Thanks for the help!

Thanks for the link!!! My vision is not the best, the site unfamiliar and I could not find the attachment  button. I have zipped and uploaded the log file.

    
    

    
  
(In reply to Steve Workman [:sworkman] (please use needinfo) from comment #19)
> This may be related to bug 1093983 - I say that because it looks like DNS
> requests are failing in the log (attachment 8571227 [details]). One of the
> commenters in bug 1093983 suggested that certain DNS resolvers block clients
> that send type 'ANY' requests. This was, of course, news to us and we hadn't
> seen any failures yet.
> 
> To be sure, please go to "about:config". Search for network.dns.get-ttl and
> set it to false. Retry connecting to a site, and please report back here.

Im testing this.  When i modify network.dns.get-ttl to FALSE value, it's not working.
Its the same PC, then i post new log (After network.dns modify). log2.zip

    
    

    
  

      
      
      
      

        Attached file
          
        log2.txt.zip
        — 
      

    


  
OS  Windows XP Version 5.1 After modify  network.dns.get-tll to false value.

    
    

    
  
I guess this bug has the same root cause of bug 1138070.

    
    

    
  
(In reply to Masatoshi Kimura [:emk] from comment #27)
> I guess this bug has the same root cause of bug 1138070.

should we dup it? Is there a way to confirm or are you confident enough to dup?
Flags: needinfo?(VYV03354)

    
    

    
  
Pushed a change from bug 1138070 to try:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=91e52604f5fd
If this is a dupe, the patched binary will work.
Flags: needinfo?(VYV03354)

    
    

    
  
can you try the binary from comment 29?
Flags: needinfo?(frederic)

    
    

    
  
Looking at the log from comment #26 it does not look as the same problem.

    
    

    
  
(In reply to Patrick McManus [:mcmanus] from comment #30)
> can you try the binary from comment 29?

How to down this patched binary?
Flags: needinfo?(frederic)

    
    

    
  
1] all dns in the log fails and fails immediately

2] while this is likely related to the ttl code, I don't think the use ANY queries is the direct cause.. a] the first query (which doesn't use any) fails immediately, b] the reporter tried the pref switch, c] there is no evidence that clients are blacklisted rather certain queries might be firewalled - and the getaddrinfo call that produces the results wouldn't be firewalled as it uses a/4a

3] the patch in comment 29 is about ime.. probly not directly the issue, but..

4] the ttl code did introduce a call to LoadLibraryA() and the patch in comment 29 is about s/GetModuleHandleA/GetModuleHandleW() and that seems like far too big of a conincidence.. so there seems to be a good chance its the same root issue (as emk said) but needs a different patch.

Steve - could you make a try build that uses loadlibraryw (like https://bug1138070.bugzilla.mozilla.org/attachment.cgi?id=8571959) for the reporter to try? Is that crazy?
Flags: needinfo?(sworkman)

    
    

    
  
(In reply to Patrick McManus [:mcmanus] from comment #34)
> Steve - could you make a try build that uses loadlibraryw (like
> https://bug1138070.bugzilla.mozilla.org/attachment.cgi?id=8571959) for the
> reporter to try? Is that crazy?

Try is closed currently (?!). Will try again after lunch.

Don't know if it's crazy; worth a try. I'll read a little more to see if I understand what's going on.
Flags: needinfo?(sworkman)

    
    

    
  
(In reply to Patrick McManus [:mcmanus] from comment #34)
> 4] the ttl code did introduce a call to LoadLibraryA() and the patch in
> comment 29 is about s/GetModuleHandleA/GetModuleHandleW() and that seems
> like far too big of a conincidence.. so there seems to be a good chance its
> the same root issue (as emk said) but needs a different patch.

The problem was that GetModuleHandleA was called inside a hooks function that is called from a internal kernel function. It does not mean you can not call LoadLibraryA at all.
The hook function will be called *everytime* the kernel tried to get a PE header. So the hook function can affect everywhere, including this bug.
So I don't think the different patch is needed.

    
    

    
  
To be clear, here is the patch:
https://hg.mozilla.org/try/rev/19ed33006d9b
No IME code at all.

    
    

    
  
:emk - interesting, thanks!

    
    

    
  

      
      
      
      

        Attached file
          
        log.txt
        — 
      

    


  

    
    

    
  
Another log provided by a French user (Win XP SP2) affected by the same issue.

    
    

    
  
(In reply to Masatoshi Kimura [:emk] from comment #37)
> Frederic, can you try with the following binary?
> https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/VYV03354@nifty.ne.
> jp-91e52604f5fd/try-win32/firefox-39.0a1.en-US.win32.installer.exe


Ok, this biuld (Firefox 39.0a1 2015-03-03) work on the machine that 36 does not work.
Same machine that com26 and log attachment  log2.txt.
Flags: needinfo?(frederic)

    
    

    
  
(In reply to Frederic GRAVIER from comment #42)
> (In reply to Masatoshi Kimura [:emk] from comment #37)
> > Frederic, can you try with the following binary?
> > https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/VYV03354@nifty.ne.
> > jp-91e52604f5fd/try-win32/firefox-39.0a1.en-US.win32.installer.exe
> 
> 
> Ok, this biuld (Firefox 39.0a1 2015-03-03) work on the machine that 36 does
> not work.
> Same machine that com26 and log attachment  log2.txt.

Thank you, then I can declare this is a dupe of bug 1138070.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE

    
    

    
  
Do anyone know why XP SP2 is still common in France and Japan?

    
    

    
  
Maybe they are enterprise computers. Many firms have business applications working only on outdated OSes like Windows XP, and they don't want to spend money and time to upgrade apps and hardware.

    
    

    
  
I don't think the majority of them are running XP SP2 though.

    
    

    
  
(In reply to Yuhong Bao from comment #48)
> I don't think the majority of them are running XP SP2 though.

Yes, but enough of them do.

    
    

    
  
(In reply to Ehsan Akhgari (not reviewing patches, not reading bugmail, needinfo? me!) from comment #49)
> (In reply to Yuhong Bao from comment #48)
> > I don't think the majority of them are running XP SP2 though.
> 
> Yes, but enough of them do.

I was talking about "enterprise computers".

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: