Closed Bug 1170928 Opened 6 years ago Closed 5 years ago

crash @ mozilla::net::Http2Session::ReadSegments(mozilla::net::nsAHttpSegmentReader*, unsigned int, unsigned int*) | mozilla::net::TLSFilterTransaction::WriteSegments(mozilla::net::nsAHttpSegmentWriter… | when internet connection is lost with http/2 pro

Categories

(Core :: Networking: HTTP, defect)

38 Branch
defect
Not set
critical

Tracking

()

RESOLVED DUPLICATE of bug 1283823
Tracking Status
firefox47 --- affected
firefox48 --- affected
firefox49 --- affected
firefox50 --- affected

People

(Reporter: kuba, Assigned: u408661)

References

Details

(Keywords: crash, Whiteboard: [spdy][necko-active])

Crash Data

Attachments

(1 file)

User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Firefox/38.0
Build ID: 20150525141253

Steps to reproduce:

How to reproduce:
1. install squid + nghttpx to get http/2 proxy
2. set firefox to use it using pac file
3. browse for a while, then unplug network cable
4. see Firefox crashed message after a few seconds.

Tested on Windows 8.1 64bit, Windows 7 32bit and Windows XP 32bit.
Please attach the information detailed in the following article.
https://developer.mozilla.org/docs/How_to_get_a_stacktrace_for_a_bug_report
Severity: normal → critical
Flags: needinfo?(kuba)
Keywords: crash
Thank you for the update.

(In reply to Jaromír Kuba from comment #2)
> bp-388da869-1cfe-48a1-b6f5-a557f2150604
> bp-9073208c-8255-4c09-9af7-9a8382150604
> bp-87eb7930-df8f-4b17-84c3-735522150604
> bp-9ba7f1a7-f894-4523-a71d-df38e2150603
> bp-484246af-7673-47f2-b26e-938ee2150603
> bp-bb81a224-4e4d-48ee-85f8-d29042150602

mozilla::net::Http2Session::ReadSegments(mozilla::net::nsAHttpSegmentReader*, unsigned int, unsigned int*)

> bp-6e7bd3e9-0f23-46d9-84ac-163f42150603

mozilla::net::TLSFilterTransaction::WriteSegments(mozilla::net::nsAHttpSegmentWriter*, unsigned int, unsigned int*)

> bp-eac92a0f-10e4-4285-9c02-e1c842150224

N.B.: Firefox 36, report dated 2015-02-24.
mozilla::net::SocketOutWrapper::OnReadSegment(char const*, unsigned int, unsigned int*)
Crash Signature: mozilla::net::Http2Session::ReadSegments(mozilla::net::nsAHttpSegmentReader*, unsigned int, unsigned int*) mozilla::net::TLSFilterTransaction::WriteSegments(mozilla::net::nsAHttpSegmentWriter*, unsigned int, unsigned int*) mozilla::net::SocketOutWrapper…
Component: Untriaged → Networking: HTTP
Product: Firefox → Core
Summary: Firefox crashes when internet connection is lost and http/2 proxy is used → crash @ mozilla::net::Http2Session::ReadSegments(mozilla::net::nsAHttpSegmentReader*, unsigned int, unsigned int*) | mozilla::net::TLSFilterTransaction::WriteSegments(mozilla::net::nsAHttpSegmentWriter… | when internet connection is lost with http/2 proxy
nick is going to try and fit it in..
Assignee: nobody → hurley
Whiteboard: [spdy]
Flags: needinfo?(hurley)
I encountered frequent crashes with the nghttpx + squid h2 proxy setup, especially when I was playing YouTube movie.
My stacktrace is very similar to https://crash-stats.mozilla.com/report/index/6e7bd3e9-0f23-46d9-84ac-163f42150603
Although, my OS is Linux amd64, and Firefox 43.0.1.
Note that I've never unplugged network cable when I got crashes.  Firefox just crashed with normal browsing (youtube).
I'm actively working on this, though having trouble reproducing this exact behavior. I do, however, get firefox to hang when doing a CONNECT over an h2 proxy, so that's fun. I can make the hang occur even just by typing into the URL bar - I suspect the channel opened by the search suggestions bits is hanging, though I'm not even sure I have search suggestions turned on for the profile I'm using for this bug. More details as they become apparent.
Flags: needinfo?(hurley)
Tatsuhiro, would it be possible for you to share your nghttpx + squid configs? Like I said in my previous comment, I can get all kinds of *other* issues (all of which will probably need to be fixed) to happen with my config, but still not the one this bug is about. I'd like to see if it's an issue with my config or if I'm just super-unlucky and not even getting to the point of the crash you and others are seeing.
Flags: needinfo?(tatsuhiro.t)
Here is my nghttpx.conf:

frontend=*,3000
backend=127.0.0.1,3128
private-key-file=server.key
certificate-file=server.crt
http2-proxy=yes

nghttpx listens port 3000.  server.key and server.crt are server's certificate and private key file. The certificate is self-signed, and imported to Firefox to trust it (I know what I'm doing).
squid is running the same host on port 3128.  I use debian sid default squid.conf.
Flags: needinfo?(tatsuhiro.t)
Attached file squid.conf
One thing I noticed is that I've got frequent crashes if I watch movie while logged in youtube.
OTOH, if I watch movie in "Private Browsing" mode without logged in, no crash has been observed so far.
I sometimes encountered very strange request from Firefox while using HTTP/2 proxy:

CONNECT clients1.google.com:80 HTTP/1.1
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:43.0) Gecko/20100101 Firefox/43.0
Proxy-Connection: keep-alive
Connection: keep-alive
Host: clients1.google.com:80

nghttpx supports both HTTP/2 and HTTP/1 in frontend connection.  Usually, Firefox uses HTTP/2.
But the above request was sent from HTTP/1 connection.  Somehow Firefox decided to play around HTTP/1.

I'm not sure this is related to this issue.  But anyway I reported here just in case..
After upgrading 44.0 today on Linux, I have experienced no crash so far.
The strange requests above still appear.  Could be a different bug.
nick, what's the status here?
Whiteboard: [spdy] → [spdy][necko-assigned]
(In reply to Patrick McManus [:mcmanus] from comment #14)
> nick, what's the status here?

Still in progress, been a bit on the back burner to give my brain a rest from it. Planning on picking it back up in the latter half of this week.
Whiteboard: [spdy][necko-assigned] → [spdy][necko-active]
Depends on: 1253699
Duplicate of this bug: 1272798
Wonder whether there is much progress here?

I was asked on Twitter whether we are going to fix this: https://twitter.com/chemhack/status/742330364484571136 (Chinese). The guy said their support team in general asks their users to switch to Chrome to avoid meeting this issue, which may indicate it is a very frequent issue for proxy users.
(In reply to Xidorn Quan [:xidorn] (UTC+1) from comment #17)
> Wonder whether there is much progress here?

No progress yet - I'm hoping to make some in London this week (when I'm not in meetings).

> I was asked on Twitter whether we are going to fix this:
> https://twitter.com/chemhack/status/742330364484571136 (Chinese). The guy
> said their support team in general asks their users to switch to Chrome to
> avoid meeting this issue, which may indicate it is a very frequent issue for
> proxy users.

Interesting, this is the first I've heard of widespread http2 proxy usage (which is partially why I haven't prioritized this more). Do we know what proxy is being used in these cases and/or what kinds of user behavior is causing the crash to manifest so often?
Flags: needinfo?(bugzilla)
They are using nghttp2+squid as well. It is said that they are still able to reproduce this crash on at least Firefox 45 with the same stack backtrace. He also mentioned that Tatsuhiro Tsujikawa above is the author of nghttp2.
Flags: needinfo?(bugzilla)
Crash Signature: mozilla::net::Http2Session::ReadSegments(mozilla::net::nsAHttpSegmentReader*, unsigned int, unsigned int*) mozilla::net::TLSFilterTransaction::WriteSegments(mozilla::net::nsAHttpSegmentWriter*, unsigned int, unsigned int*) mozilla::net::SocketOutWrapper… → [@ mozilla::net::Http2Session::ReadSegments(mozilla::net::nsAHttpSegmentReader*, unsigned int, unsigned int*) ] [@ mozilla::net::TLSFilterTransaction::WriteSegments(mozilla::net::nsAHttpSegmentWriter*, unsigned int, unsigned int*) ] [@ mozilla::net::Soc…
Nghttpx + Squid work together very well, I am not aware of any other http2 proxy solution widely deployed. Http2 proxy has many advantages over classic http proxy, so it is becoming quite popular. This error disqualifies Firefox in eyes of proxy Firefox users, forcing them to migrate to Chromium-based browsers. PS.: Happy birtday to this bug, it has been reported a year ago. :-)
[Tracking Requested - why for this release]:
the volume for this crash is now starkly rising in the last days with the release of zenmate 5.5.3 (also see bug 1283823). the signature is #10 with 1.36% of all crashes on 48.0b5 currently.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(In reply to Tatsuhiro Tsujikawa from comment #6)
> Note that I've never unplugged network cable when I got crashes.  Firefox
> just crashed with normal browsing (youtube).

I've been able to get a semi-reliable repro by playing youtube and doing ifdown on the interface while its playing.. fwiw
if anyone can reproduce this with nghttp can you try the build in https://bugzilla.mozilla.org/show_bug.cgi?id=1283823#c7

I suspect the builds are dups of each other, especially as the STR in this bug can be used to repro it with zenmate and the signature in the other bug..
Flags: needinfo?(kuba)
(In reply to Patrick McManus [:mcmanus] from comment #23)
> if anyone can reproduce this with nghttp can you try the build in
> https://bugzilla.mozilla.org/show_bug.cgi?id=1283823#c7
> 
> I suspect the builds are dups of each other, especially as the STR in this
> bug can be used to repro it with zenmate and the signature in the other bug..

Above mentioned nightly build works for me (fingers crossed), I am unable to force crash anymore. Tested VPN on/off during page load, disabling/enabling lan, switching from lan to wi-fi and back, changing wi-fi hotspot during transfrer, plug/unplug cable, etc. Above mentioned resulted in crash in Firefox 47.0.1, nice work.
thanks kuba
Status: NEW → RESOLVED
Closed: 5 years ago
Flags: needinfo?(kuba)
Resolution: --- → DUPLICATE
Duplicate of bug: 1283823
Un-track this based on comment #25.
You need to log in before you can comment on or make changes to this bug.