783643 - firefox can't open any URL after suspend to RAM

Status: RESOLVED WORKSFORME

(Firefox :: Untriaged, defect)

Description

[Alexander]

User Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20100101 Firefox/14.0.1 Iceweasel/14.0.1
Build ID: 20120717133201

Steps to reproduce:

I'm experiencing someting similar to bug 470274 but I'm using 14.0.1 packaged for debian stable (Actually I see this issue since at least FF13). I have gmail and zimbra opened all the time as well other web sites (I usually have around 10 active tabs). When I resume after suspend to ram, almost always firefox can't open anything. UI is responsive but no page opens as if there is no Internet connection. But there is because other browsers can open pages at the same time. Also if I restart firefox, it starts working. 

Restarting firefox means killing the firefox process, because File->quit closes the FF windows but do not terminate firefox completely.

Looking at  bug 470274 I tried to play with offline mode. When I got FF in this bad state I enabled offline mode, one page immediately opened but any further attempts to open any page yielded an error that page can't be opened in offline mode. Trying to disable offline mode didn't help and nothing I tried made FF leave offline mode.

So to me it seems offline mode has something to do with the issue.

Comment 1

[Andre Klapper]

> other browsers can open pages at the same time. if I restart firefox, it starts working. 

> File->quit closes the FF windows but do not terminate firefox completely.

That also sounds like a bug. Maybe running it under strace might show some reasons?

Comment 2

[Alexander]

the problem with quitting where I have to kill firefox happens only with the problem opening pages. I guess it is stuck waiting on some IO. I will try to reproduce running under strace.

Comment 3

[[:Aleksej]]

Could this be related to bug 781754?

Comment 4

[Alexander]

Might be, I think I have had such problems. Unfortunately I can't reproduce for the last few days. Perhaps it depends on what pages I have opened at the time. Since I don't remember what I had opened I can only wait and see when the problem arise again. gmail and zimbra are not a problem it seems.

Comment 5

[Alexander]

Attachment: strace from firefox when quitting after hibernate

I think I just reproduced. I attached strace and clicked file->quit. It hanged at one point so I killed the process as you can see in the attached ff.trace.gz.

Comment 6

[Alexander]

same problem I see with version 15.0

Comment 7

[Wayne Mery (:wsmwk)]

can you reproduce this in safe mode?
Using a newer version?  (like 17 or 18 from
http://www.mozilla.org/en-US/firefox/channel/ )

Comment 8

[Alexander]

Hello Wayne,

I tried with safe-mode of my current version - 16. It reproduces. Please let me know if anybody is going to do anything about this bug if I test with latest version. I really don't have the time to try it out just for the protocol. Since the bug seems to be ignored since v14 I'm a little bit discouraged, I hope you understand.

Comment 9

[Alexander]

I did some more observations. I see that at the times the problem occurs I am seeing stale connections in ESTABLISHED state. If I wait for these connections to disappear after some time (I think less than half an hour), then FF starts working again. Strange is that the number of stale connections does not matter. They might be 2 or 20, the (a)effect is the same.

Here is part of netstat -avnp output:
tcp        0      0 192.168.2.102:33966     80.123.47.44:80         ESTABLISHED 20302/firefox-bin
tcp        0      0 192.168.2.102:51201     173.199.80.157:80       ESTABLISHED 20302/firefox-bin
tcp        1      0 192.168.2.102:52283     171.1.71.18:443       CLOSE_WAIT  20302/firefox-bin
tcp        0      0 192.168.2.102:35196     83.13.37.9:80          ESTABLISHED 20302/firefox-bin
tcp        0      0 192.168.2.102:58571     64.162.13.173:80        ESTABLISHED 20302/firefox-bin

So after the connections terminate (due to timeouts perhaps), FF starts serving pages again. The bad thing is that cutter, killcx and tcpkill cannot kill these connections. I am guessing these connections are out of the conntrack cache. btw sometimes the connections are to networks that are not accessible any more (i.e. VPN that is no longer connected). The latest kernel I have tried with is 3.2.0-0.bpo.4-686-pae #1 SMP Debian 3.2.32-1~bpo60+1

My opinion is that this is not a problem only in FF because IMO such connections should be terminated by kernel already. But having FF blocking on stale connections is a bug by itself. Additionally I'm noticing blocks when using GSSAPI kerberos auth which also makes browser very inconvenient to use while loading sites with such auth.

Please let me know if I can provide any other useful information.

Comment 10

[Wayne Mery (:wsmwk)]

you might skim this llist of bug reports and tell us if anything strikes your fancy

https://bugzilla.mozilla.org/buglist.cgi?type1-0-0=nowordssubstr;list_id=5035351;short_desc=%20;field0-0-0=short_desc;type0-0-1=substring;field0-0-1=short_desc;type1-0-1=nowordssubstr;resolution=---;resolution=FIXED;value1-0-1=orange%20test;classification=Client%20Software;classification=Components;chfieldto=Now;query_format=advanced;chfieldfrom=2011-09-01;value1-0-0=orange%20test;short_desc_type=allwordssubstr;value0-0-1=stand%20by;type0-0-0=anywordssubstr;value0-0-0=resum%20sleep%20suspend%20wake%20waking%20standby%20woke%20waki%20slept%20hibernat%20ACPI%20hybern;field1-0-0=short_desc;product=Core;product=Firefox;product=Toolkit;field1-0-1=status_whiteboard

Comment 11

[Alexander]

I switched to fedora 18 and haven't seen this issue manifest anymore. I'm not sure if that is related to using network manager for managing networks, newer kernel or libraries. I'll report back if I hit this problem again. The debian installation I used before is nuked so it's not possible to reproduce anymore.

Comment 12

[Wayne Mery (:wsmwk)]

WFM per reporter