Fennec crashes on page load when connected with SPDY proxy

RESOLVED FIXED in mozilla32

Status

()

Core
Networking
RESOLVED FIXED
3 years ago
3 years ago

People

(Reporter: esawin, Assigned: mcmanus)

Tracking

unspecified
mozilla32
ARM
Android
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(3 attachments)

(Reporter)

Description

3 years ago
Created attachment 8427030 [details]
CNN crash trace

Firefox for Android consistently crashes when loading some pages through a secure SPDY proxy.

STR
1. Configure SPDY proxy using PAC.
2. Open web page (e.g. http://cnn.com or https://github.com).

Expected
The web page loads (tunneled through the proxy).

Actual
The web page loads partially then the client crashes.

Tested with node-spdyproxy (https://github.com/igrigorik/node-spdyproxy) on Firefox for Android 32.0a1 (2014-05-22).

Stack traces are attached.
(Reporter)

Comment 1

3 years ago
Created attachment 8427031 [details]
GitHub crash trace
(Reporter)

Comment 2

3 years ago
Additional info

The certificate used was self-signed and proxy configuration was as described in https://github.com/eamsen/node-gonzales#configuration.
I can confirm the github issue is an http/1 pipelining interaction. (the spdy connect tunnel forms a http/1 connection with github and we pipeline over that.. totally reasonable). I have a potential fix, but need more time to test it.

its possible the cnn issue is related - but I haven't yet diagnosed it.
i've reproduced both crash scenarios just by enabling pipeline settings on desktop and the patch at try seems to fix them. esawin - can you confirm from that build?

https://tbpl.mozilla.org/?tree=Try&rev=772e4ba42266
Created attachment 8427483 [details] [diff] [review]
problem with https proxying and http pipelines
Attachment #8427483 - Flags: review?(hurley)
Assignee: nobody → mcmanus
Status: NEW → ASSIGNED
Duplicate of this bug: 1015210
(Reporter)

Comment 7

3 years ago
(In reply to Patrick McManus [:mcmanus] from comment #4)
> i've reproduced both crash scenarios just by enabling pipeline settings on
> desktop and the patch at try seems to fix them. esawin - can you confirm
> from that build?
> 
> https://tbpl.mozilla.org/?tree=Try&rev=772e4ba42266

With the patch, cnn.com loads, but loading github.com crashes. Here is the not-so-useful dump:

0x7e0cd61a in EqualStringsHelper (str1=0x87cf6c10, str2=<optimized out>) at /home/esawin/work/src/js/src/jit/IonCaches.cpp:2955
2955        JS_ASSERT(str1->length() == str2->length());
(gdb) bt
#0  0x7e0cd61a in EqualStringsHelper (str1=0x87cf6c10, str2=<optimized out>) at /home/esawin/work/src/js/src/jit/IonCaches.cpp:2955
#1  0x885a73cc in ?? ()
#2  0x885a73cc in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) info registers
r0             0x79     121
r1             0x2710   10000
r2             0x77700290       2003829392
r3             0x7b     123
r4             0x87cf6c10       2278517776
r5             0x0      0
r6             0x83a00210       2208301584
r7             0x33     51
r8             0x34     52
r9             0x87cf6c10       2278517776
r10            0x1      1
r11            0x777008c0       2003830976
r12            0x2      2
sp             0x77700708       0x77700708
lr             0x7e0c276d       2114725741
pc             0x7e0cd61a       0x7e0cd61a <EqualStringsHelper(JSString*, JSString*)+158>
cpsr           0x20010030       536936496
Attachment #8427483 - Flags: review?(hurley) → review+
This patch fixes a definite problem, so let's get it in the tree

 https://hg.mozilla.org/integration/mozilla-inbound/rev/294813ad96ad

there isn't an obvious reason to suggest the stack in comment 7 is directly related. 

Marking as leave-open to address that issue. :esawin it would be awesome if you could retest when this hits nightly, if for no other reason than you have a corruped stack and maybe we'll end up with a more useful data point.
https://hg.mozilla.org/mozilla-central/rev/294813ad96ad
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla32
I meant to mark this leave-open per comment 8
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Reporter)

Comment 11

3 years ago
(In reply to Patrick McManus [:mcmanus] from comment #8)
> This patch fixes a definite problem, so let's get it in the tree
> 
>  https://hg.mozilla.org/integration/mozilla-inbound/rev/294813ad96ad
> 
> there isn't an obvious reason to suggest the stack in comment 7 is directly
> related. 
> 
> Marking as leave-open to address that issue. :esawin it would be awesome if
> you could retest when this hits nightly, if for no other reason than you
> have a corruped stack and maybe we'll end up with a more useful data point.

Not reproducible on Nightly (2014-05-30), both websites (CNN and GitHub) load without crashing.
Thanks for the quick fix!
Thanks - keep me posted of anything interesting.. 1014600 and 1015898 are still open on this feature..
Status: REOPENED → RESOLVED
Last Resolved: 3 years ago3 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.