<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<!DOCTYPE bugzilla SYSTEM "https://bugs.webkit.org/page.cgi?id=bugzilla.dtd">

<bugzilla version="5.0.4.1"
          urlbase="https://bugs.webkit.org/"
          
          maintainer="admin@webkit.org"
>

    <bug>
          <bug_id>180285</bug_id>
          
          <creation_ts>2017-12-01 14:57:23 -0800</creation_ts>
          <short_desc>WebSocketChannel should ensure its client is live when calling it in error case</short_desc>
          <delta_ts>2017-12-04 10:24:00 -0800</delta_ts>
          <reporter_accessible>1</reporter_accessible>
          <cclist_accessible>1</cclist_accessible>
          <classification_id>1</classification_id>
          <classification>Unclassified</classification>
          <product>WebKit</product>
          <component>WebCore Misc.</component>
          <version>WebKit Nightly Build</version>
          <rep_platform>Unspecified</rep_platform>
          <op_sys>Unspecified</op_sys>
          <bug_status>RESOLVED</bug_status>
          <resolution>FIXED</resolution>
          
          
          <bug_file_loc></bug_file_loc>
          <status_whiteboard></status_whiteboard>
          <keywords>InRadar</keywords>
          <priority>P2</priority>
          <bug_severity>Normal</bug_severity>
          <target_milestone>---</target_milestone>
          
          
          <everconfirmed>1</everconfirmed>
          <reporter name="youenn fablet">youennf</reporter>
          <assigned_to name="youenn fablet">youennf</assigned_to>
          <cc>achristensen</cc>
    
    <cc>commit-queue</cc>
    
    <cc>darin</cc>
    
    <cc>ggaren</cc>
    
    <cc>webkit-bug-importer</cc>
          

      

      

      

          <comment_sort_order>oldest_to_newest</comment_sort_order>  
          <long_desc isprivate="0" >
    <commentid>1377084</commentid>
    <comment_count>0</comment_count>
    <who name="youenn fablet">youennf</who>
    <bug_when>2017-12-01 14:57:23 -0800</bug_when>
    <thetext>WebSocketChannel should ensure its client is live when calling it in error case</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1377085</commentid>
    <comment_count>1</comment_count>
      <attachid>328164</attachid>
    <who name="youenn fablet">youennf</who>
    <bug_when>2017-12-01 14:58:29 -0800</bug_when>
    <thetext>Created attachment 328164
Patch</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1377086</commentid>
    <comment_count>2</comment_count>
    <who name="youenn fablet">youennf</who>
    <bug_when>2017-12-01 14:59:08 -0800</bug_when>
    <thetext>rdar://problem/32896043</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1377510</commentid>
    <comment_count>3</comment_count>
      <attachid>328164</attachid>
    <who name="Darin Adler">darin</who>
    <bug_when>2017-12-03 14:15:48 -0800</bug_when>
    <thetext>Comment on attachment 328164
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=328164&amp;action=review

&gt; Source/WebCore/ChangeLog:8
&gt; +        No observable change of behavior.

That is strange. Can the pointer be null or not?</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1377600</commentid>
    <comment_count>4</comment_count>
    <who name="youenn fablet">youennf</who>
    <bug_when>2017-12-03 21:20:33 -0800</bug_when>
    <thetext>(In reply to Darin Adler from comment #3)
&gt; Comment on attachment 328164 [details]
&gt; Patch
&gt; 
&gt; View in context:
&gt; https://bugs.webkit.org/attachment.cgi?id=328164&amp;action=review
&gt; 
&gt; &gt; Source/WebCore/ChangeLog:8
&gt; &gt; +        No observable change of behavior.
&gt; 
&gt; That is strange. Can the pointer be null or not?

I believe it does.
What I mean by no observable change of behavior is that this will not remove any error event trigger at JS level.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1377605</commentid>
    <comment_count>5</comment_count>
      <attachid>328164</attachid>
    <who name="WebKit Commit Bot">commit-queue</who>
    <bug_when>2017-12-03 21:40:51 -0800</bug_when>
    <thetext>Comment on attachment 328164
Patch

Clearing flags on attachment: 328164

Committed r225469: &lt;https://trac.webkit.org/changeset/225469&gt;</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1377606</commentid>
    <comment_count>6</comment_count>
    <who name="WebKit Commit Bot">commit-queue</who>
    <bug_when>2017-12-03 21:40:53 -0800</bug_when>
    <thetext>All reviewed patches have been landed.  Closing bug.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1377750</commentid>
    <comment_count>7</comment_count>
      <attachid>328164</attachid>
    <who name="Geoffrey Garen">ggaren</who>
    <bug_when>2017-12-04 10:21:00 -0800</bug_when>
    <thetext>Comment on attachment 328164
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=328164&amp;action=review

&gt;&gt;&gt; Source/WebCore/ChangeLog:8
&gt;&gt;&gt; +        No observable change of behavior.
&gt;&gt; 
&gt;&gt; That is strange. Can the pointer be null or not?
&gt; 
&gt; I believe it does.
&gt; What I mean by no observable change of behavior is that this will not remove any error event trigger at JS level.

I think a clearer statement here is that we believe this fixes a common crash seen in diagnostic logging. (That is an observable change in behavior.) But we don&apos;t have a reproducible test case for the crash. The pointer can be null because disconnect() and didCloseSocketStream() set it to null.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1377751</commentid>
    <comment_count>8</comment_count>
    <who name="Geoffrey Garen">ggaren</who>
    <bug_when>2017-12-04 10:21:32 -0800</bug_when>
    <thetext>&gt; I think a clearer statement here is that we believe this fixes a common
&gt; crash seen in diagnostic logging. (That is an observable change in
&gt; behavior.) But we don&apos;t have a reproducible test case for the crash. The
&gt; pointer can be null because disconnect() and didCloseSocketStream() set it
&gt; to null.

... Youenn, have you tried to write a test case that invokes disconnect() or didCloseSocketStream()?</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1377755</commentid>
    <comment_count>9</comment_count>
    <who name="youenn fablet">youennf</who>
    <bug_when>2017-12-04 10:24:00 -0800</bug_when>
    <thetext>(In reply to Geoffrey Garen from comment #8)
&gt; &gt; I think a clearer statement here is that we believe this fixes a common
&gt; &gt; crash seen in diagnostic logging. (That is an observable change in
&gt; &gt; behavior.) But we don&apos;t have a reproducible test case for the crash. The
&gt; &gt; pointer can be null because disconnect() and didCloseSocketStream() set it
&gt; &gt; to null.
&gt; 
&gt; ... Youenn, have you tried to write a test case that invokes disconnect() or
&gt; didCloseSocketStream()?

I haven&apos;t tried but will do.</thetext>
  </long_desc>
      
          <attachment
              isobsolete="0"
              ispatch="1"
              isprivate="0"
          >
            <attachid>328164</attachid>
            <date>2017-12-01 14:58:29 -0800</date>
            <delta_ts>2017-12-03 21:40:51 -0800</delta_ts>
            <desc>Patch</desc>
            <filename>bug-180285-20171201145828.patch</filename>
            <type>text/plain</type>
            <size>1652</size>
            <attacher name="youenn fablet">youennf</attacher>
            
              <data encoding="base64">U3VidmVyc2lvbiBSZXZpc2lvbjogMjI1NDEyCmRpZmYgLS1naXQgYS9Tb3VyY2UvV2ViQ29yZS9D
aGFuZ2VMb2cgYi9Tb3VyY2UvV2ViQ29yZS9DaGFuZ2VMb2cKaW5kZXggNjJjNjY2YTI0ZWRhNWM1
ZjZmN2YyZDBjZjQwNDFmMTQ1MWIxOGY3Ni4uZjhkYWIzZjgxOTUxYjFiMjllNjFiMGVkZGE3YzQ4
N2M2ZTg1NGQwNyAxMDA2NDQKLS0tIGEvU291cmNlL1dlYkNvcmUvQ2hhbmdlTG9nCisrKyBiL1Nv
dXJjZS9XZWJDb3JlL0NoYW5nZUxvZwpAQCAtMSw1ICsxLDE4IEBACiAyMDE3LTEyLTAxICBZb3Vl
bm4gRmFibGV0ICA8eW91ZW5uQGFwcGxlLmNvbT4KIAorICAgICAgICBXZWJTb2NrZXRDaGFubmVs
IHNob3VsZCBlbnN1cmUgaXRzIGNsaWVudCBpcyBsaXZlIHdoZW4gY2FsbGluZyBpdCBpbiBlcnJv
ciBjYXNlCisgICAgICAgIGh0dHBzOi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD0x
ODAyODUKKworICAgICAgICBSZXZpZXdlZCBieSBOT0JPRFkgKE9PUFMhKS4KKworICAgICAgICBO
byBvYnNlcnZhYmxlIGNoYW5nZSBvZiBiZWhhdmlvci4KKyAgICAgICAgVGhpcyBtYWtlcyBpdCBj
b25zaXN0ZW50IHdpdGggb3RoZXIgY2FsbHMgb2YgZGlkUmVjZWl2ZU1lc3NhZ2VFcnJvci4KKwor
ICAgICAgICAqIE1vZHVsZXMvd2Vic29ja2V0cy9XZWJTb2NrZXRDaGFubmVsLmNwcDoKKyAgICAg
ICAgKFdlYkNvcmU6OldlYlNvY2tldENoYW5uZWw6OmZhaWwpOgorCisyMDE3LTEyLTAxICBZb3Vl
bm4gRmFibGV0ICA8eW91ZW5uQGFwcGxlLmNvbT4KKwogICAgICAgICBJbXBsZW1lbnQgaHR0cHM6
Ly93M2MuZ2l0aHViLmlvL1NlcnZpY2VXb3JrZXIvI2NsaWVudHMtZ2V0CiAgICAgICAgIGh0dHBz
Oi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD0xODAxNjcKIApkaWZmIC0tZ2l0IGEv
U291cmNlL1dlYkNvcmUvTW9kdWxlcy93ZWJzb2NrZXRzL1dlYlNvY2tldENoYW5uZWwuY3BwIGIv
U291cmNlL1dlYkNvcmUvTW9kdWxlcy93ZWJzb2NrZXRzL1dlYlNvY2tldENoYW5uZWwuY3BwCmlu
ZGV4IDM5ZjMxMDA3Zjg0OTVlYjEwZTM1OWNlYzJmODFjNGE2M2ZlYWY4NGYuLmE1OWI0NjllM2M5
YzVmNWM5OTY0NWY5MGQyNGY2OGUzY2E5MzFkZGMgMTAwNjQ0Ci0tLSBhL1NvdXJjZS9XZWJDb3Jl
L01vZHVsZXMvd2Vic29ja2V0cy9XZWJTb2NrZXRDaGFubmVsLmNwcAorKysgYi9Tb3VyY2UvV2Vi
Q29yZS9Nb2R1bGVzL3dlYnNvY2tldHMvV2ViU29ja2V0Q2hhbm5lbC5jcHAKQEAgLTIzMiw3ICsy
MzIsOCBAQCB2b2lkIFdlYlNvY2tldENoYW5uZWw6OmZhaWwoY29uc3QgU3RyaW5nJiByZWFzb24p
CiAgICAgbV9kZWZsYXRlRnJhbWVyLmRpZEZhaWwoKTsKICAgICBtX2hhc0NvbnRpbnVvdXNGcmFt
ZSA9IGZhbHNlOwogICAgIG1fY29udGludW91c0ZyYW1lRGF0YS5jbGVhcigpOwotICAgIG1fY2xp
ZW50LT5kaWRSZWNlaXZlTWVzc2FnZUVycm9yKCk7CisgICAgaWYgKG1fY2xpZW50KQorICAgICAg
ICBtX2NsaWVudC0+ZGlkUmVjZWl2ZU1lc3NhZ2VFcnJvcigpOwogCiAgICAgaWYgKG1faGFuZGxl
ICYmICFtX2Nsb3NlZCkKICAgICAgICAgbV9oYW5kbGUtPmRpc2Nvbm5lY3QoKTsgLy8gV2lsbCBj
YWxsIGRpZENsb3NlU29ja2V0U3RyZWFtKCkgYnV0IG1heWJlIG5vdCBzeW5jaHJvbm91c2x5Lgo=
</data>

          </attachment>
      

    </bug>

</bugzilla>