1014589 - Fennec crashes on page load when connected with SPDY proxy

Status: RESOLVED FIXED

(Core :: Networking, defect)

Description

[Eugen Sawin [:esawin]]

Attachment: 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.

Comment 1

[Eugen Sawin [:esawin]]

Attachment: GitHub crash trace

Comment 2

[Eugen Sawin [:esawin]]

Additional info

The certificate used was self-signed and proxy configuration was as described in https://github.com/eamsen/node-gonzales#configuration.

Comment 3

[Patrick McManus [:mcmanus]]

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.

Comment 4

[Patrick McManus [:mcmanus]]

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

Comment 5

[Patrick McManus [:mcmanus]]

Attachment: problem with https proxying and http pipelines

Comment 7

[Eugen Sawin [:esawin]]

(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

Comment 8

[Patrick McManus [:mcmanus]]

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.

Comment 9

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/294813ad96ad

Comment 10

[Patrick McManus [:mcmanus]]

I meant to mark this leave-open per comment 8

Comment 11

[Eugen Sawin [:esawin]]

(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!

Comment 12

[Patrick McManus [:mcmanus]]

Thanks - keep me posted of anything interesting.. 1014600 and 1015898 are still open on this feature..