<?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>172267</bug_id>
          
          <creation_ts>2017-05-18 03:11:23 -0700</creation_ts>
          <short_desc>[Win] error LNK2005: WebCore::JSNode::checkSubClassPatchpoint() already defined in WebKit.lib</short_desc>
          <delta_ts>2017-05-19 23:55:43 -0700</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></keywords>
          <priority>P2</priority>
          <bug_severity>Normal</bug_severity>
          <target_milestone>---</target_milestone>
          <dependson>172098</dependson>
          
          <everconfirmed>1</everconfirmed>
          <reporter name="Fujii Hironori">fujii</reporter>
          <assigned_to name="Fujii Hironori">fujii</assigned_to>
          <cc>achristensen</cc>
    
    <cc>bfulgham</cc>
    
    <cc>commit-queue</cc>
    
    <cc>pvollan</cc>
    
    <cc>ysuzuki</cc>
          

      

      

      

          <comment_sort_order>oldest_to_newest</comment_sort_order>  
          <long_desc isprivate="0" >
    <commentid>1310039</commentid>
    <comment_count>0</comment_count>
    <who name="Fujii Hironori">fujii</who>
    <bug_when>2017-05-18 03:11:23 -0700</bug_when>
    <thetext>AppleWin port and WinCairo port builds are broken.

&gt; FAILED: bin64/TestWebKitLib.dll lib64/TestWebKitLib.lib 
&gt; cmd.exe /C &quot;cd . &amp;&amp; C:\tools\cmake\bin\cmake.exe -E vs_link_dll --intdir=Tools\TestWebKitAPI\CMakeFiles\TestWebKitLib.dir --manifests  -- &quot;C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\VC\Tools\MSVC\14.10.25017\bin\HostX64\x64\link.exe&quot; /nologo @CMakeFiles/TestWebKitLib.rsp  /out:bin64\TestWebKitLib.dll /implib:lib64\TestWebKitLib.lib /pdb:bin64\TestWebKitLib.pdb /dll /version:0.0 /machine:x64 /DEBUG /OPT:ICF /OPT:REF /INCREMENTAL:NO   &amp;&amp; cd .&quot;
&gt; WebCore.lib(JSNodeDOMJIT.cpp.obj) : error LNK2005: &quot;public: static class WTF::RefPtr&lt;class JSC::DOMJIT::Patchpoint&gt; __cdecl WebCore::JSNode::checkSubClassPatchpoint(void)&quot; (?checkSubClassPatchpoint@JSNode@WebCore@@SA?AV?$RefPtr@VPatchpoint@DOMJIT@JSC@@@WTF@@XZ) already defined in WebKit.lib(WebKit.dll)
&gt; 
&gt; WebCore.lib(JSDocumentDOMJIT.cpp.obj) : error LNK2005: &quot;public: static class WTF::RefPtr&lt;class JSC::DOMJIT::Patchpoint&gt; __cdecl WebCore::JSDocument::checkSubClassPatchpoint(void)&quot; (?checkSubClassPatchpoint@JSDocument@WebCore@@SA?AV?$RefPtr@VPatchpoint@DOMJIT@JSC@@@WTF@@XZ) already defined in WebKit.lib(WebKit.dll)
&gt; 
&gt;    Creating library lib64\TestWebKitLib.lib and object lib64\TestWebKitLib.exp
&gt; 
&gt; bin64\TestWebKitLib.dll : fatal error LNK1169: one or more multiply defined symbols found
&gt; 
&gt; LINK failed. with 1169
&gt; [60/60] Linking CXX shared library bin64\TestWebCoreLib.dll
&gt; FAILED: bin64/TestWebCoreLib.dll lib64/TestWebCoreLib.lib 
&gt; cmd.exe /C &quot;cd . &amp;&amp; C:\tools\cmake\bin\cmake.exe -E vs_link_dll --intdir=Tools\TestWebKitAPI\CMakeFiles\TestWebCoreLib.dir --manifests  -- &quot;C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\VC\Tools\MSVC\14.10.25017\bin\HostX64\x64\link.exe&quot; /nologo @CMakeFiles/TestWebCoreLib.rsp  /out:bin64\TestWebCoreLib.dll /implib:lib64\TestWebCoreLib.lib /pdb:bin64\TestWebCoreLib.pdb /dll /version:0.0 /machine:x64 /DEBUG /OPT:ICF /OPT:REF /INCREMENTAL:NO   &amp;&amp; cd .&quot;
&gt; WebCore.lib(JSNodeDOMJIT.cpp.obj) : error LNK2005: &quot;public: static class WTF::RefPtr&lt;class JSC::DOMJIT::Patchpoint&gt; __cdecl WebCore::JSNode::checkSubClassPatchpoint(void)&quot; (?checkSubClassPatchpoint@JSNode@WebCore@@SA?AV?$RefPtr@VPatchpoint@DOMJIT@JSC@@@WTF@@XZ) already defined in WebKit.lib(WebKit.dll)
&gt; 
&gt; WebCore.lib(JSDocumentDOMJIT.cpp.obj) : error LNK2005: &quot;public: static class WTF::RefPtr&lt;class JSC::DOMJIT::Patchpoint&gt; __cdecl WebCore::JSDocument::checkSubClassPatchpoint(void)&quot; (?checkSubClassPatchpoint@JSDocument@WebCore@@SA?AV?$RefPtr@VPatchpoint@DOMJIT@JSC@@@WTF@@XZ) already defined in WebKit.lib(WebKit.dll)
&gt; 
&gt;    Creating library lib64\TestWebCoreLib.lib and object lib64\TestWebCoreLib.exp</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1310040</commentid>
    <comment_count>1</comment_count>
    <who name="Fujii Hironori">fujii</who>
    <bug_when>2017-05-18 03:13:11 -0700</bug_when>
    <thetext>WEBCORE_EXPORT is defined for dllexport in WebCore. This is strange becuase WebCore is a static library in Windows port.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1310056</commentid>
    <comment_count>2</comment_count>
    <who name="Fujii Hironori">fujii</who>
    <bug_when>2017-05-18 03:43:21 -0700</bug_when>
    <thetext>This has happened since https://trac.webkit.org/changeset/217031</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1310065</commentid>
    <comment_count>3</comment_count>
    <who name="Yusuke Suzuki">ysuzuki</who>
    <bug_when>2017-05-18 05:04:34 -0700</bug_when>
    <thetext>Hmmmm, it is very storange. These functions are only defined once in JSNodeDOMJIT.cpp &amp; JSDocumentDOMJIT.cpp. And other ports just build it correctly.
Do you know the special things done for WebCore.lib &amp; WebKit.lib in Windows?</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1310069</commentid>
    <comment_count>4</comment_count>
    <who name="Yusuke Suzuki">ysuzuki</who>
    <bug_when>2017-05-18 05:20:18 -0700</bug_when>
    <thetext>(In reply to Yusuke Suzuki from comment #3)
&gt; Hmmmm, it is very storange. These functions are only defined once in
&gt; JSNodeDOMJIT.cpp &amp; JSDocumentDOMJIT.cpp. And other ports just build it
&gt; correctly.
&gt; Do you know the special things done for WebCore.lib &amp; WebKit.lib in Windows?

And I also note that JSEventDOMJIT.cpp, JSElementDOMJIT.cpp and JSDocumentFragmentDOMJIT.cpp also have similar `checkSubClassPatchpoint` functions. But they do not cause linker errors according to the log.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1310391</commentid>
    <comment_count>5</comment_count>
    <who name="Fujii Hironori">fujii</who>
    <bug_when>2017-05-18 19:03:43 -0700</bug_when>
    <thetext>By checking with dumpbin, I&apos;ve confirmed checkSubClassPatchpoint was exported from WebKit.dll.
I&apos;m guessing a following simple scenario.

1) JSDocumentDOMJIT.cpp was compiled with dllexport in WebCore
2) The linker included JSDocumentDOMJIT.cpp.obj into WebKit.dll
3) The linker found some dllexport-marked symbols in JSDocumentDOMJIT.cpp.obj and exported them from WebKit.dll

I admit that this hypothesis doesn&apos;t explain comment 4.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1310493</commentid>
    <comment_count>6</comment_count>
    <who name="Per Arne Vollan">pvollan</who>
    <bug_when>2017-05-18 23:39:16 -0700</bug_when>
    <thetext>Perhaps we shouldn&apos;t link with both WebKit.lib and WebCore.lib? In theory, I guess TestWebCoreLib only needs to link with WebCore.lib, and TestWebKitLib only needs to link with WebKit.lib. I would expect to get many other linker errors if this was the case, though.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1310515</commentid>
    <comment_count>7</comment_count>
    <who name="Yusuke Suzuki">ysuzuki</who>
    <bug_when>2017-05-19 01:34:55 -0700</bug_when>
    <thetext>(In reply to Fujii Hironori from comment #5)
&gt; By checking with dumpbin, I&apos;ve confirmed checkSubClassPatchpoint was
&gt; exported from WebKit.dll.
&gt; I&apos;m guessing a following simple scenario.
&gt; 
&gt; 1) JSDocumentDOMJIT.cpp was compiled with dllexport in WebCore
&gt; 2) The linker included JSDocumentDOMJIT.cpp.obj into WebKit.dll
&gt; 3) The linker found some dllexport-marked symbols in
&gt; JSDocumentDOMJIT.cpp.obj and exported them from WebKit.dll
&gt; 
&gt; I admit that this hypothesis doesn&apos;t explain comment 4.

Right. I&apos;ve just checked the generated JSNode.cpp in DerivedSoure.
And I&apos;ve found that, whole JSNode class is annotated by WEBCORE_EXPORT,
while JSDocumentFragment is not.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1310517</commentid>
    <comment_count>8</comment_count>
      <attachid>310635</attachid>
    <who name="Fujii Hironori">fujii</who>
    <bug_when>2017-05-19 01:50:16 -0700</bug_when>
    <thetext>Created attachment 310635
WIP patch

(In reply to Per Arne Vollan from comment #6)
&gt; Perhaps we shouldn&apos;t link with both WebKit.lib and WebCore.lib? In theory, I
&gt; guess TestWebCoreLib only needs to link with WebCore.lib, and TestWebKitLib
&gt; only needs to link with WebKit.lib. I would expect to get many other linker
&gt; errors if this was the case, though.

Sounds good!
Unfortunately, my WIP patch reports a following linkage error.

&gt; ------ Build started: Project: TestWebCoreLib, Configuration: Debug x64 ------
&gt;      Creating library C:/webkit/ga/WebKitBuild/Debug/lib64/TestWebCoreLib.lib and object C:/webkit/ga/WebKitBuild/Debug/lib64/TestWebCoreLib.exp
&gt; WebCore.lib(ImageWin.obj) : error LNK2019: unresolved external symbol &quot;class WTF::RefPtr&lt;class WebCore::SharedBuffer&gt; __cdecl loadResourceIntoBuffer(char const *)&quot; (?loadResourceIntoBuffer@@YA?AV?$RefPtr@VSharedBuffer@WebCore@@@WTF@@PEBD@Z) referenced in function &quot;public: static class WTF::Ref&lt;class WebCore::Image&gt; __cdecl WebCore::Image::loadPlatformResource(char const *)&quot; (?loadPlatformResource@Image@WebCore@@SA?AV?$Ref@VImage@WebCore@@@WTF@@PEBD@Z)
&gt; C:\webkit\ga\WebKitBuild\Debug\bin64\TestWebCoreLib.dll : fatal error LNK1120: 1 unresolved externals
&gt; ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

There is a layer violation.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1310522</commentid>
    <comment_count>9</comment_count>
    <who name="Per Arne Vollan">pvollan</who>
    <bug_when>2017-05-19 01:59:04 -0700</bug_when>
    <thetext>(In reply to Fujii Hironori from comment #8)
&gt; Created attachment 310635 [details]
&gt; WIP patch
&gt; 
&gt; (In reply to Per Arne Vollan from comment #6)
&gt; &gt; Perhaps we shouldn&apos;t link with both WebKit.lib and WebCore.lib? In theory, I
&gt; &gt; guess TestWebCoreLib only needs to link with WebCore.lib, and TestWebKitLib
&gt; &gt; only needs to link with WebKit.lib. I would expect to get many other linker
&gt; &gt; errors if this was the case, though.
&gt; 
&gt; Sounds good!
&gt; Unfortunately, my WIP patch reports a following linkage error.
&gt; 
&gt; &gt; ------ Build started: Project: TestWebCoreLib, Configuration: Debug x64 ------
&gt; &gt;      Creating library C:/webkit/ga/WebKitBuild/Debug/lib64/TestWebCoreLib.lib and object C:/webkit/ga/WebKitBuild/Debug/lib64/TestWebCoreLib.exp
&gt; &gt; WebCore.lib(ImageWin.obj) : error LNK2019: unresolved external symbol &quot;class WTF::RefPtr&lt;class WebCore::SharedBuffer&gt; __cdecl loadResourceIntoBuffer(char const *)&quot; (?loadResourceIntoBuffer@@YA?AV?$RefPtr@VSharedBuffer@WebCore@@@WTF@@PEBD@Z) referenced in function &quot;public: static class WTF::Ref&lt;class WebCore::Image&gt; __cdecl WebCore::Image::loadPlatformResource(char const *)&quot; (?loadPlatformResource@Image@WebCore@@SA?AV?$Ref@VImage@WebCore@@@WTF@@PEBD@Z)
&gt; &gt; C:\webkit\ga\WebKitBuild\Debug\bin64\TestWebCoreLib.dll : fatal error LNK1120: 1 unresolved externals
&gt; &gt; ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
&gt; 
&gt; There is a layer violation.

Nice work! I suggest soft linking the loadResourceIntoBuffer function.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1310523</commentid>
    <comment_count>10</comment_count>
    <who name="Yusuke Suzuki">ysuzuki</who>
    <bug_when>2017-05-19 02:00:42 -0700</bug_when>
    <thetext>(In reply to Per Arne Vollan from comment #9)
&gt; (In reply to Fujii Hironori from comment #8)
&gt; &gt; Created attachment 310635 [details]
&gt; &gt; WIP patch
&gt; &gt; 
&gt; &gt; (In reply to Per Arne Vollan from comment #6)
&gt; &gt; &gt; Perhaps we shouldn&apos;t link with both WebKit.lib and WebCore.lib? In theory, I
&gt; &gt; &gt; guess TestWebCoreLib only needs to link with WebCore.lib, and TestWebKitLib
&gt; &gt; &gt; only needs to link with WebKit.lib. I would expect to get many other linker
&gt; &gt; &gt; errors if this was the case, though.
&gt; &gt; 
&gt; &gt; Sounds good!
&gt; &gt; Unfortunately, my WIP patch reports a following linkage error.
&gt; &gt; 
&gt; &gt; &gt; ------ Build started: Project: TestWebCoreLib, Configuration: Debug x64 ------
&gt; &gt; &gt;      Creating library C:/webkit/ga/WebKitBuild/Debug/lib64/TestWebCoreLib.lib and object C:/webkit/ga/WebKitBuild/Debug/lib64/TestWebCoreLib.exp
&gt; &gt; &gt; WebCore.lib(ImageWin.obj) : error LNK2019: unresolved external symbol &quot;class WTF::RefPtr&lt;class WebCore::SharedBuffer&gt; __cdecl loadResourceIntoBuffer(char const *)&quot; (?loadResourceIntoBuffer@@YA?AV?$RefPtr@VSharedBuffer@WebCore@@@WTF@@PEBD@Z) referenced in function &quot;public: static class WTF::Ref&lt;class WebCore::Image&gt; __cdecl WebCore::Image::loadPlatformResource(char const *)&quot; (?loadPlatformResource@Image@WebCore@@SA?AV?$Ref@VImage@WebCore@@@WTF@@PEBD@Z)
&gt; &gt; &gt; C:\webkit\ga\WebKitBuild\Debug\bin64\TestWebCoreLib.dll : fatal error LNK1120: 1 unresolved externals
&gt; &gt; &gt; ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
&gt; &gt; 
&gt; &gt; There is a layer violation.
&gt; 
&gt; Nice work! I suggest soft linking the loadResourceIntoBuffer function.

Yeah, that&apos;s great!
In the meantime, I&apos;ll land the original patch by extracting checkSubClassPatchpoint from JSNode / JSDocument and move it to WebCore::checkSubClassPatchpointFor{JSNode,JSDocument}.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1310541</commentid>
    <comment_count>11</comment_count>
      <attachid>310639</attachid>
    <who name="Fujii Hironori">fujii</who>
    <bug_when>2017-05-19 02:47:10 -0700</bug_when>
    <thetext>Created attachment 310639
Patch

This is a layer violation and TestWebCore is just a unit test. I&apos;d like to suggest to add a stub in TestWebCoreLib. How do you think this?</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1310590</commentid>
    <comment_count>12</comment_count>
    <who name="Per Arne Vollan">pvollan</who>
    <bug_when>2017-05-19 07:03:50 -0700</bug_when>
    <thetext>(In reply to Fujii Hironori from comment #11)
&gt; Created attachment 310639 [details]
&gt; Patch
&gt; 
&gt; This is a layer violation and TestWebCore is just a unit test. I&apos;d like to
&gt; suggest to add a stub in TestWebCoreLib. How do you think this?

That sounds good! It seems the build problem on Win EWS is unrelated to this patch.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1310817</commentid>
    <comment_count>13</comment_count>
    <who name="Fujii Hironori">fujii</who>
    <bug_when>2017-05-19 15:33:37 -0700</bug_when>
    <thetext>Win EWS gets green. Could anyone review this?</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1310982</commentid>
    <comment_count>14</comment_count>
      <attachid>310639</attachid>
    <who name="Per Arne Vollan">pvollan</who>
    <bug_when>2017-05-19 23:27:00 -0700</bug_when>
    <thetext>Comment on attachment 310639
Patch

Looks good! R=me.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1310987</commentid>
    <comment_count>15</comment_count>
      <attachid>310639</attachid>
    <who name="WebKit Commit Bot">commit-queue</who>
    <bug_when>2017-05-19 23:55:41 -0700</bug_when>
    <thetext>Comment on attachment 310639
Patch

Clearing flags on attachment: 310639

Committed r217184: &lt;http://trac.webkit.org/changeset/217184&gt;</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1310988</commentid>
    <comment_count>16</comment_count>
    <who name="WebKit Commit Bot">commit-queue</who>
    <bug_when>2017-05-19 23:55:43 -0700</bug_when>
    <thetext>All reviewed patches have been landed.  Closing bug.</thetext>
  </long_desc>
      
          <attachment
              isobsolete="1"
              ispatch="1"
              isprivate="0"
          >
            <attachid>310635</attachid>
            <date>2017-05-19 01:50:16 -0700</date>
            <delta_ts>2017-05-19 02:47:05 -0700</delta_ts>
            <desc>WIP patch</desc>
            <filename>Bug172267.patch</filename>
            <type>text/plain</type>
            <size>985</size>
            <attacher name="Fujii Hironori">fujii</attacher>
            
              <data encoding="base64">ZGlmZiAtLWdpdCBhL1Rvb2xzL1Rlc3RXZWJLaXRBUEkvUGxhdGZvcm1XaW4uY21ha2UgYi9Ub29s
cy9UZXN0V2ViS2l0QVBJL1BsYXRmb3JtV2luLmNtYWtlCmluZGV4IGY2OWVmNzUyZDhmLi4yNDdi
MjJmZWQyNCAxMDA2NDQKLS0tIGEvVG9vbHMvVGVzdFdlYktpdEFQSS9QbGF0Zm9ybVdpbi5jbWFr
ZQorKysgYi9Ub29scy9UZXN0V2ViS2l0QVBJL1BsYXRmb3JtV2luLmNtYWtlCkBAIC0zNiw3ICsz
Niw2IEBAIHNldCh0ZXN0X3dlYmNvcmVfTElCUkFSSUVTCiAgICAgVXNwMTAKICAgICBXZWJDb3Jl
JHtERUJVR19TVUZGSVh9CiAgICAgV2ViQ29yZURlcml2ZWRTb3VyY2VzJHtERUJVR19TVUZGSVh9
Ci0gICAgV2ViS2l0JHtERUJVR19TVUZGSVh9CiAgICAgV2luZG93c0NvZGVjcwogICAgIGd0ZXN0
CiApCkBAIC0xNDAsNiArMTM5LDExIEBAIGlmICgke1dURl9QTEFURk9STV9XSU5fQ0FJUk99KQog
ICAgICkKIGVuZGlmICgpCiAKK3NldCh0ZXN0X3dlYmtpdF9MSUJSQVJJRVMKKyAgICBXZWJDb3Jl
VGVzdFN1cHBvcnQKKyAgICBXZWJLaXQke0RFQlVHX1NVRkZJWH0KKyAgICBndGVzdAorKQogYWRk
X2xpYnJhcnkoVGVzdFdlYktpdExpYiBTSEFSRUQKICAgICAke3Rlc3RfbWFpbl9TT1VSQ0VTfQog
ICAgICR7VEVTVFdFQktJVEFQSV9ESVJ9L1Rlc3RzQ29udHJvbGxlci5jcHAKQEAgLTE0OCw3ICsx
NTIsNyBAQCBhZGRfbGlicmFyeShUZXN0V2ViS2l0TGliIFNIQVJFRAogICAgICR7VEVTVFdFQktJ
VEFQSV9ESVJ9L3dpbi9Ib3N0V2luZG93LmNwcAogKQogCi10YXJnZXRfbGlua19saWJyYXJpZXMo
VGVzdFdlYktpdExpYiAke3Rlc3Rfd2ViY29yZV9MSUJSQVJJRVN9KQordGFyZ2V0X2xpbmtfbGli
cmFyaWVzKFRlc3RXZWJLaXRMaWIgJHt0ZXN0X3dlYmtpdF9MSUJSQVJJRVN9KQogCiBhZGRfZXhl
Y3V0YWJsZShUZXN0V2ViS2l0CiAgICAgJHtUT09MU19ESVJ9L3dpbi9ETExMYXVuY2hlci9ETExM
YXVuY2hlck1haW4uY3BwCg==
</data>

          </attachment>
          <attachment
              isobsolete="0"
              ispatch="1"
              isprivate="0"
          >
            <attachid>310639</attachid>
            <date>2017-05-19 02:47:10 -0700</date>
            <delta_ts>2017-05-19 23:55:41 -0700</delta_ts>
            <desc>Patch</desc>
            <filename>bug-172267-20170519184708.patch</filename>
            <type>text/plain</type>
            <size>4406</size>
            <attacher name="Fujii Hironori">fujii</attacher>
            
              <data encoding="base64">U3VidmVyc2lvbiBSZXZpc2lvbjogMjE3MDM2CmRpZmYgLS1naXQgYS9Ub29scy9DaGFuZ2VMb2cg
Yi9Ub29scy9DaGFuZ2VMb2cKaW5kZXggYTE1YzdkNDA1ZGUzMDc1MmNiYzBjY2NlM2E4NGM2ZmFj
MzQ4NGVmOC4uYmE5Y2U4MGU5MTk4ZDg5MmRmNDFhN2EwMzdhZDRmMjVmNmI3MWYwNyAxMDA2NDQK
LS0tIGEvVG9vbHMvQ2hhbmdlTG9nCisrKyBiL1Rvb2xzL0NoYW5nZUxvZwpAQCAtMSwzICsxLDI0
IEBACisyMDE3LTA1LTE5ICBGdWppaSBIaXJvbm9yaSAgPEhpcm9ub3JpLkZ1amlpQHNvbnkuY29t
PgorCisgICAgICAgIFtXaW5dIGVycm9yIExOSzIwMDU6IFdlYkNvcmU6OkpTTm9kZTo6Y2hlY2tT
dWJDbGFzc1BhdGNocG9pbnQoKSBhbHJlYWR5IGRlZmluZWQgaW4gV2ViS2l0LmxpYgorICAgICAg
ICBodHRwczovL2J1Z3Mud2Via2l0Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9MTcyMjY3CisKKyAgICAg
ICAgUmV2aWV3ZWQgYnkgTk9CT0RZIChPT1BTISkuCisKKyAgICAgICAgVGVzdFdlYkNvcmVMaWIg
YW5kIFRlc3RXZWJLaXRMaWIgaGF2ZSBsaW5rZWQgYm90aCBXZWJDb3JlIGFuZCBXZWJLaXQuCisg
ICAgICAgIFRlc3RXZWJDb3JlTGliIHNob3VsZCBsaW5rIG9ubHkgd2l0aCBXZWJDb3JlLiBBbmQs
IFRlc3RXZWJLaXRMaWIKKyAgICAgICAgc2hvdWxkIGxpbmsgb25seSB3aXRoIFdlYktpdC4KKwor
ICAgICAgICBVbmZvcnR1bmF0ZWx5LCB0aGVyZSBpcyBhIGxheWVyIHZpb2xhdGlvbiBhdCB0aGUg
bW9tZW50LgorICAgICAgICBXZWJDb3JlOjpJbWFnZTo6bG9hZFBsYXRmb3JtUmVzb3VyY2UgbmVl
ZHMgbG9hZFJlc291cmNlSW50b0J1ZmZlcgorICAgICAgICBpbiBXZWJLaXQuIFRoaXMgY2hhbmdl
IGNvbnRhaW5zIGEgc3R1YiBvZiBsb2FkUmVzb3VyY2VJbnRvQnVmZmVyCisgICAgICAgIGluIFRl
c3RXZWJDb3JlTGliIGZvciB0aGUgd29ya2Fyb3VuZC4KKworICAgICAgICAqIFRlc3RXZWJLaXRB
UEkvUGxhdGZvcm1XaW4uY21ha2U6IERvIG5vdCBsaW5rIFdlYktpdCB0bworICAgICAgICBUZXN0
V2ViQ29yZUxpYi4gRG8gbm90IGxpbmsgV2ViQ29yZSB0byBUZXN0V2ViS2l0TGliLgorICAgICAg
ICAqIFRlc3RXZWJLaXRBUEkvd2luL1Rlc3RXZWJDb3JlU3R1YnMuY3BwOiBBZGRlZC4KKyAgICAg
ICAgKGxvYWRSZXNvdXJjZUludG9CdWZmZXIpOiBBZGRlZCBhIHN0dWIuCisKIDIwMTctMDUtMTcg
IFJ5YW4gSGFkZGFkICA8cnlhbmhhZGRhZEBhcHBsZS5jb20+CiAKICAgICAgICAgVW5yZXZpZXdl
ZCwgcm9sbGluZyBvdXQgcjIxNzAxNC4KZGlmZiAtLWdpdCBhL1Rvb2xzL1Rlc3RXZWJLaXRBUEkv
UGxhdGZvcm1XaW4uY21ha2UgYi9Ub29scy9UZXN0V2ViS2l0QVBJL1BsYXRmb3JtV2luLmNtYWtl
CmluZGV4IGY2OWVmNzUyZDhmNTNlMzQyOWMwNGEwNTRmNjEyMDZmMGMzZDlhM2MuLmE3OWFhNmQ0
NWRjMGIxOWEzMDdjZWU5YzhkODdmNDE1YWRiODE3NDUgMTAwNjQ0Ci0tLSBhL1Rvb2xzL1Rlc3RX
ZWJLaXRBUEkvUGxhdGZvcm1XaW4uY21ha2UKKysrIGIvVG9vbHMvVGVzdFdlYktpdEFQSS9QbGF0
Zm9ybVdpbi5jbWFrZQpAQCAtMzYsMTMgKzM2LDEzIEBAIHNldCh0ZXN0X3dlYmNvcmVfTElCUkFS
SUVTCiAgICAgVXNwMTAKICAgICBXZWJDb3JlJHtERUJVR19TVUZGSVh9CiAgICAgV2ViQ29yZURl
cml2ZWRTb3VyY2VzJHtERUJVR19TVUZGSVh9Ci0gICAgV2ViS2l0JHtERUJVR19TVUZGSVh9CiAg
ICAgV2luZG93c0NvZGVjcwogICAgIGd0ZXN0CiApCiAKIHNldChUZXN0V2ViQ29yZUxpYl9TT1VS
Q0VTCiAgICAgJHt0ZXN0X21haW5fU09VUkNFU30KKyAgICB3aW4vVGVzdFdlYkNvcmVTdHVicy5j
cHAKICAgICAke1RFU1RXRUJLSVRBUElfRElSfS9UZXN0c0NvbnRyb2xsZXIuY3BwCiAgICAgJHtU
RVNUV0VCS0lUQVBJX0RJUn0vVGVzdHMvV2ViQ29yZS9BZmZpbmVUcmFuc2Zvcm0uY3BwCiAgICAg
JHtURVNUV0VCS0lUQVBJX0RJUn0vVGVzdHMvV2ViQ29yZS9DYWxjdWxhdGlvblZhbHVlLmNwcApA
QCAtMTQwLDYgKzE0MCwxMSBAQCBpZiAoJHtXVEZfUExBVEZPUk1fV0lOX0NBSVJPfSkKICAgICAp
CiBlbmRpZiAoKQogCitzZXQodGVzdF93ZWJraXRfTElCUkFSSUVTCisgICAgV2ViQ29yZVRlc3RT
dXBwb3J0CisgICAgV2ViS2l0JHtERUJVR19TVUZGSVh9CisgICAgZ3Rlc3QKKykKIGFkZF9saWJy
YXJ5KFRlc3RXZWJLaXRMaWIgU0hBUkVECiAgICAgJHt0ZXN0X21haW5fU09VUkNFU30KICAgICAk
e1RFU1RXRUJLSVRBUElfRElSfS9UZXN0c0NvbnRyb2xsZXIuY3BwCkBAIC0xNDgsNyArMTUzLDcg
QEAgYWRkX2xpYnJhcnkoVGVzdFdlYktpdExpYiBTSEFSRUQKICAgICAke1RFU1RXRUJLSVRBUElf
RElSfS93aW4vSG9zdFdpbmRvdy5jcHAKICkKIAotdGFyZ2V0X2xpbmtfbGlicmFyaWVzKFRlc3RX
ZWJLaXRMaWIgJHt0ZXN0X3dlYmNvcmVfTElCUkFSSUVTfSkKK3RhcmdldF9saW5rX2xpYnJhcmll
cyhUZXN0V2ViS2l0TGliICR7dGVzdF93ZWJraXRfTElCUkFSSUVTfSkKIAogYWRkX2V4ZWN1dGFi
bGUoVGVzdFdlYktpdAogICAgICR7VE9PTFNfRElSfS93aW4vRExMTGF1bmNoZXIvRExMTGF1bmNo
ZXJNYWluLmNwcApkaWZmIC0tZ2l0IGEvVG9vbHMvVGVzdFdlYktpdEFQSS93aW4vVGVzdFdlYkNv
cmVTdHVicy5jcHAgYi9Ub29scy9UZXN0V2ViS2l0QVBJL3dpbi9UZXN0V2ViQ29yZVN0dWJzLmNw
cApuZXcgZmlsZSBtb2RlIDEwMDY0NAppbmRleCAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw
MDAwMDAwMDAwMDAwLi4xZjkzMGYyZTRjMWIxZjE4MWY0Nzc3M2ZiNDczZDA0NjNhNGVjZmI5Ci0t
LSAvZGV2L251bGwKKysrIGIvVG9vbHMvVGVzdFdlYktpdEFQSS93aW4vVGVzdFdlYkNvcmVTdHVi
cy5jcHAKQEAgLTAsMCArMSwzMiBAQAorLyoKKyAqIENvcHlyaWdodCAoQykgMjAxNyBTb255IElu
dGVyYWN0aXZlIEVudGVydGFpbm1lbnQgSW5jLgorICoKKyAqIFJlZGlzdHJpYnV0aW9uIGFuZCB1
c2UgaW4gc291cmNlIGFuZCBiaW5hcnkgZm9ybXMsIHdpdGggb3Igd2l0aG91dAorICogbW9kaWZp
Y2F0aW9uLCBhcmUgcGVybWl0dGVkIHByb3ZpZGVkIHRoYXQgdGhlIGZvbGxvd2luZyBjb25kaXRp
b25zCisgKiBhcmUgbWV0OgorICogMS4gIFJlZGlzdHJpYnV0aW9ucyBvZiBzb3VyY2UgY29kZSBt
dXN0IHJldGFpbiB0aGUgYWJvdmUgY29weXJpZ2h0CisgKiAgICAgbm90aWNlLCB0aGlzIGxpc3Qg
b2YgY29uZGl0aW9ucyBhbmQgdGhlIGZvbGxvd2luZyBkaXNjbGFpbWVyLgorICogMi4gIFJlZGlz
dHJpYnV0aW9ucyBpbiBiaW5hcnkgZm9ybSBtdXN0IHJlcHJvZHVjZSB0aGUgYWJvdmUgY29weXJp
Z2h0CisgKiAgICAgbm90aWNlLCB0aGlzIGxpc3Qgb2YgY29uZGl0aW9ucyBhbmQgdGhlIGZvbGxv
d2luZyBkaXNjbGFpbWVyIGluIHRoZQorICogICAgIGRvY3VtZW50YXRpb24gYW5kL29yIG90aGVy
IG1hdGVyaWFscyBwcm92aWRlZCB3aXRoIHRoZSBkaXN0cmlidXRpb24uCisgKiAKKyAqIFRISVMg
U09GVFdBUkUgSVMgUFJPVklERUQgQlkgQVBQTEUgSU5DLiBBTkQgSVRTIENPTlRSSUJVVE9SUyBg
YEFTIElTJycgQU5EIEFOWQorICogRVhQUkVTUyBPUiBJTVBMSUVEIFdBUlJBTlRJRVMsIElOQ0xV
RElORywgQlVUIE5PVCBMSU1JVEVEIFRPLCBUSEUgSU1QTElFRAorICogV0FSUkFOVElFUyBPRiBN
RVJDSEFOVEFCSUxJVFkgQU5EIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFIEFSRQor
ICogRElTQ0xBSU1FRC4gSU4gTk8gRVZFTlQgU0hBTEwgQVBQTEUgSU5DLiBPUiBJVFMgQ09OVFJJ
QlVUT1JTIEJFIExJQUJMRSBGT1IgQU5ZCisgKiBESVJFQ1QsIElORElSRUNULCBJTkNJREVOVEFM
LCBTUEVDSUFMLCBFWEVNUExBUlksIE9SIENPTlNFUVVFTlRJQUwgREFNQUdFUworICogKElOQ0xV
RElORywgQlVUIE5PVCBMSU1JVEVEIFRPLCBQUk9DVVJFTUVOVCBPRiBTVUJTVElUVVRFIEdPT0RT
IE9SIFNFUlZJQ0VTOworICogTE9TUyBPRiBVU0UsIERBVEEsIE9SIFBST0ZJVFM7IE9SIEJVU0lO
RVNTIElOVEVSUlVQVElPTikgSE9XRVZFUiBDQVVTRUQgQU5EIE9OCisgKiBBTlkgVEhFT1JZIE9G
IExJQUJJTElUWSwgV0hFVEhFUiBJTiBDT05UUkFDVCwgU1RSSUNUIExJQUJJTElUWSwgT1IgVE9S
VAorICogKElOQ0xVRElORyBORUdMSUdFTkNFIE9SIE9USEVSV0lTRSkgQVJJU0lORyBJTiBBTlkg
V0FZIE9VVCBPRiBUSEUgVVNFIE9GIFRISVMKKyAqIFNPRlRXQVJFLCBFVkVOIElGIEFEVklTRUQg
T0YgVEhFIFBPU1NJQklMSVRZIE9GIFNVQ0ggREFNQUdFLgorICovCisjaW5jbHVkZSAiY29uZmln
LmgiCisKKyNpbmNsdWRlICJTaGFyZWRCdWZmZXIuaCIKKworUmVmUHRyPFdlYkNvcmU6OlNoYXJl
ZEJ1ZmZlcj4gbG9hZFJlc291cmNlSW50b0J1ZmZlcihjb25zdCBjaGFyKikKK3sKKyAgICByZXR1
cm4gbnVsbHB0cjsKK30KKwo=
</data>

          </attachment>
      

    </bug>

</bugzilla>