<?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>153176</bug_id>
          
          <creation_ts>2016-01-15 19:58:08 -0800</creation_ts>
          <short_desc>[CMake][GTK][OSX] ThreadIdentifierData::initialize assertion fails because there are two copies of WTF in process (one as part of webkit2, one as part of jsc)</short_desc>
          <delta_ts>2016-03-14 08:05:04 -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>Web Template Framework</component>
          <version>WebKit Nightly Build</version>
          <rep_platform>Mac</rep_platform>
          <op_sys>OS X 10.11</op_sys>
          <bug_status>NEW</bug_status>
          <resolution></resolution>
          
          <see_also>https://trac.macports.org/ticket/50339</see_also>
          <bug_file_loc></bug_file_loc>
          <status_whiteboard></status_whiteboard>
          <keywords></keywords>
          <priority>P2</priority>
          <bug_severity>Normal</bug_severity>
          <target_milestone>---</target_milestone>
          
          <blocked>126492</blocked>
          <everconfirmed>1</everconfirmed>
          <reporter name="Jeremy Huddleston Sequoia">jeremyhu</reporter>
          <assigned_to name="Nobody">webkit-unassigned</assigned_to>
          <cc>achristensen</cc>
    
    <cc>bugs-noreply</cc>
    
    <cc>ethansherriff</cc>
    
    <cc>mcatanzaro</cc>
          

      

      

      

          <comment_sort_order>oldest_to_newest</comment_sort_order>  
          <long_desc isprivate="0" >
    <commentid>1156093</commentid>
    <comment_count>0</comment_count>
    <who name="Jeremy Huddleston Sequoia">jeremyhu</who>
    <bug_when>2016-01-15 19:58:08 -0800</bug_when>
    <thetext>Reported on MacPorts at https://trac.macports.org/ticket/50339

After working through various build issues (bug #152641, bug #152720, bug #153117, bug #153120, bug #153138), we get a successful build, but the resulting library aborts at initialization.

The issue is in ThreadIdentifierData::initialize(ThreadIdentifier id), we&apos;re failing the RELEASE_ASSERT.  m_key is PTHREAD_KEYS_MAX for some reason.

void ThreadIdentifierData::initialize(ThreadIdentifier id)
{
    ASSERT(!identifier());
    // Ideally we&apos;d have this as a release assert everywhere, but that would hurt performane.
    // Having this release assert here means that we will catch &quot;didn&apos;t call
    // WTF::initializeThreading() soon enough&quot; bugs in release mode.
    RELEASE_ASSERT(m_key != PTHREAD_KEYS_MAX);
    pthread_setspecific(m_key, new ThreadIdentifierData(id));
}

---

I didn&apos;t quite believe it, so I changed the RELEASE_ASSERT to a real assert(), and sure enough:

Assertion failed: (m_key != PTHREAD_KEYS_MAX), function identifier, file /.../webkitgtk-2.11.3/Source/WTF/wtf/ThreadIdentifierDataPthreads.cpp, line 64.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1156123</commentid>
    <comment_count>1</comment_count>
    <who name="Jeremy Huddleston Sequoia">jeremyhu</who>
    <bug_when>2016-01-15 22:16:48 -0800</bug_when>
    <thetext>Oh... that&apos;s not surprising at all.  It&apos;s set to that value initially:

namespace WTF {
pthread_key_t ThreadIdentifierData::m_key = PTHREAD_KEYS_MAX;
...

So why the assertion?  Don&apos;t we expect it to be PTHREAD_KEYS_MAX initially?</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1156125</commentid>
    <comment_count>2</comment_count>
    <who name="Jeremy Huddleston Sequoia">jeremyhu</who>
    <bug_when>2016-01-15 22:24:55 -0800</bug_when>
    <thetext>m_key is supposed to be setup in WTF::ThreadIdentifierData::initializeOnce(), which is called by initializeThreading WTF::initializeThreading().  I&apos;m guessing WTF::initializeThreading() isn&apos;t getting called like we&apos;d expect.

Who is responsible for calling WTF::initializeThreading()?  I don&apos;t see it being called anywhere in the library.  I see it called in main() in some things in WTF/benchmarks.  Is the client responsible for calling that?  It seems odd that the library doesn&apos;t handle it.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1156126</commentid>
    <comment_count>3</comment_count>
    <who name="Jeremy Huddleston Sequoia">jeremyhu</who>
    <bug_when>2016-01-15 22:44:49 -0800</bug_when>
    <thetext>Oh, I missed it.

JSC::initializeThreading() calls WTF::initializeThreading(), and JSC::initializeThreading() is the first thing called by WebKit2::InitializeWebKit2

namespace JSC {
void initializeThreading()
{
    static std::once_flag initializeThreadingOnceFlag;

    std::call_once(initializeThreadingOnceFlag, []{
        WTF::double_conversion::initialize();
        WTF::initializeThreading();
...

---

void InitializeWebKit2()
{
#if PLATFORM(COCOA)
    InitWebCoreSystemInterface();
#endif
#if PLATFORM(IOS)
    InitWebCoreThreadSystemInterface();
#endif

    JSC::initializeThreading();
    WTF::initializeMainThread();
...

So that all looks OK, BUT the issue comes because of 2-level name-spacing.  Here&apos;s the backtrace:

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib              0x00007fff8ac13f06 __pthread_kill + 10
1   libsystem_pthread.dylib             0x00007fff8fa204ec pthread_kill + 90
2   libsystem_c.dylib                   0x00007fff8b86e6e7 abort + 129
3   libsystem_c.dylib                   0x00007fff8b835df8 __assert_rtn + 321
4   libwebkit2gtk-4.0.37.dylib          0x000000010b27cb54 WTF::ThreadIdentifierData::identifier() + 68
5   libwebkit2gtk-4.0.37.dylib          0x000000010b27db3d WTF::currentThread() + 13
6   libwebkit2gtk-4.0.37.dylib          0x000000010b222e32 WTF::initializeMainThread() + 34
7   libwebkit2gtk-4.0.37.dylib          0x0000000108e0236e WebKit::InitializeWebKit2() + 14

libwebkit2gtk&apos;s WTF::initializeMainThread() was never called.

libjavascriptcoregtk has its own copy of WTF::initializeMainThread(), and THAT was what was called:


webkitgtk-2.11.3/lib $ nm libjavascriptcoregtk-4.0.dylib | grep initializeOnce
0000000000ac29a0 T __ZN3WTF20ThreadIdentifierData14initializeOnceEv
0000000000e3f9f0 b __ZZN3WTF12_GLOBAL__N_112myThreadDataEvE14initializeOnce
0000000000e3fa30 b __ZZN3WTF12_GLOBAL__N_112myThreadDataEvE14initializeOnce

webkitgtk-2.11.3/lib $ nm libwebkit2gtk-4.0.dylib | grep initializeOnce
0000000002634a00 T __ZN3WTF20ThreadIdentifierData14initializeOnceEv
0000000003702500 b __ZZN3WTF12_GLOBAL__N_112myThreadDataEvE14initializeOnce
00000000037024b0 b __ZZN3WTF12_GLOBAL__N_112myThreadDataEvE14initializeOnce</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1156224</commentid>
    <comment_count>4</comment_count>
    <who name="Jeremy Huddleston Sequoia">jeremyhu</who>
    <bug_when>2016-01-16 14:17:21 -0800</bug_when>
    <thetext>In webkit-gtk 2.4.x, WTF is not exported by libwebkitgtk.  It&apos;s exported by libjavascriptcoregtk.  Thus, I suspect the appropriate fix is to remove WTF from libwebkit2gtk.  This was likely fallout from the autoconf -&gt; cmake transition.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1156231</commentid>
    <comment_count>5</comment_count>
    <who name="Michael Catanzaro">mcatanzaro</who>
    <bug_when>2016-01-16 15:30:20 -0800</bug_when>
    <thetext>(In reply to comment #4)
&gt; In webkit-gtk 2.4.x, WTF is not exported by libwebkitgtk.  It&apos;s exported by
&gt; libjavascriptcoregtk.  Thus, I suspect the appropriate fix is to remove WTF
&gt; from libwebkit2gtk.  This was likely fallout from the autoconf -&gt; cmake
&gt; transition.

Sounds fine to me. In Source/WebKit2/CMakeLists.txt, try removing JavaScriptCore (which depends on WTF) from here:

set(WebKit2_LIBRARIES
    JavaScriptCore
    WebCore
)

Then see if it builds....</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1156258</commentid>
    <comment_count>6</comment_count>
    <who name="Jeremy Huddleston Sequoia">jeremyhu</who>
    <bug_when>2016-01-16 21:16:58 -0800</bug_when>
    <thetext>That does nothing because WebCore also depends on JavaScriptCore.

Also removing JavaScriptCore and WTF from WebCore gets us a link line that lacks both  libjavascriptcoregtk-4.0.18.3.2.dylib and libWTFGTK.a.  Thus we fail because we need to link against libjavascriptcoregtk-4.0.18.3.2.dylib (but not libWTFGTK).

Just removing WTF from WebCore_LIBRARIES doesn&apos;t work either.  We still end up linking against both.

Just removing both JavaScriptCore and WTF from WebCore_LIBRARIES doesn&apos;t work either.  We still end up linking against both.

I can&apos;t see how to get the build system to link against libjavascriptcoregtk but not libWTFGTK.

cmake drives me crazy...</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1156264</commentid>
    <comment_count>7</comment_count>
    <who name="Jeremy Huddleston Sequoia">jeremyhu</who>
    <bug_when>2016-01-16 22:10:06 -0800</bug_when>
    <thetext>I&apos;m giving up on trying to beat cmake into submission.  Our workaround for now is just to edit link.txt after running cmake.  ie:

sed -i &apos;&apos; &quot;s|../../lib/libWTFGTK.a||&quot; Source/WebKit2/CMakeFiles/WebKit2.dir/link.txt</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1156265</commentid>
    <comment_count>8</comment_count>
    <who name="Jeremy Huddleston Sequoia">jeremyhu</who>
    <bug_when>2016-01-16 22:12:06 -0800</bug_when>
    <thetext>Although it looks like I need to do the same for WebKitWebProcess and other places where it&apos;s linked in statically.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1156267</commentid>
    <comment_count>9</comment_count>
    <who name="Jeremy Huddleston Sequoia">jeremyhu</who>
    <bug_when>2016-01-16 22:19:46 -0800</bug_when>
    <thetext>It looks like this goes well beyond just WTF.  Most of the executables are linking against both the dylibs and static archives.  For example MiniBrowser is linking

libwebkit2gtk-4.0.37.13.0.dylib
libjavascriptcoregtk-4.0.18.3.2.dylib
libbmalloc.a 
libWebCoreGTK.a
libANGLESupport.a
libGObjectDOMBindings.a
libWebCorePlatformGTK.a
libWTFGTK.a

Why does cmake not realize that the functionality provided by those static archives is already rolled into the dylibs that it built?  Depending on JavaScriptCore should just result in linking that dylib, not linking that dylib *AND* all the static archives that went into that dylib.

Have I mentioned how much I dislike cmake?</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1156284</commentid>
    <comment_count>10</comment_count>
    <who name="Michael Catanzaro">mcatanzaro</who>
    <bug_when>2016-01-17 09:04:34 -0800</bug_when>
    <thetext>(In reply to comment #9)
&gt; It looks like this goes well beyond just WTF.  Most of the executables are
&gt; linking against both the dylibs and static archives.  For example
&gt; MiniBrowser is linking
&gt; 
&gt; libwebkit2gtk-4.0.37.13.0.dylib
&gt; libjavascriptcoregtk-4.0.18.3.2.dylib
&gt; libbmalloc.a 
&gt; libWebCoreGTK.a
&gt; libANGLESupport.a
&gt; libGObjectDOMBindings.a
&gt; libWebCorePlatformGTK.a
&gt; libWTFGTK.a
&gt; 
&gt; Why does cmake not realize that the functionality provided by those static
&gt; archives is already rolled into the dylibs that it built?  Depending on
&gt; JavaScriptCore should just result in linking that dylib, not linking that
&gt; dylib *AND* all the static archives that went into that dylib.
&gt; 
&gt; Have I mentioned how much I dislike cmake?

Clearly we need to figure out what&apos;s up here. The static libraries are &quot;convenience libs&quot; which are never installed: they&apos;re only there to make reasoning about the build system easier, and so that we can catch layering violations between the libraries. MiniBrowser should only be linking to libwebkit2gtk-4.0.37.13.0.dylib and libjavascriptcoregtk-4.0.18.3.2.dylib.

I wonder if the Mac port is having any similar linking problems?</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1156287</commentid>
    <comment_count>11</comment_count>
    <who name="Michael Catanzaro">mcatanzaro</who>
    <bug_when>2016-01-17 09:37:40 -0800</bug_when>
    <thetext>Taking a quick look over https://cmake.org/cmake/help/v3.4/command/target_link_libraries.html

I think this might be what the PUBLIC, PRIVATE, and INTERFACE specifiers are for. What if, in Source/JavaScriptCore/CMakeLists.txt, instead of this:

target_link_libraries(JavaScriptCore ${JavaScriptCore_LIBRARIES})

You were to replace it with:

target_link_libraries(JavaScriptCore PRIVATE ${JavaScriptCore_LIBRARIES})

Perhaps that would fix this?

Similarly (for Source/WebKit2/CMakeLists.txt):

set(WebKit2_LIBRARIES
    PRIVATE WebCore
    INTERFACE JavaScriptCore
)</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1156291</commentid>
    <comment_count>12</comment_count>
    <who name="Michael Catanzaro">mcatanzaro</who>
    <bug_when>2016-01-17 09:50:54 -0800</bug_when>
    <thetext>(In reply to comment #11)
&gt; set(WebKit2_LIBRARIES
&gt;     PRIVATE WebCore
&gt;     INTERFACE JavaScriptCore
&gt; )

Hm, putting the visibility specifiers inside the lists is probably not going to work; you might need to split it up into WebKit2_PRIVATE_LIBRARIES, WebKit2_PUBLIC_LIBRARIES, and WebKit2_INTERFACE_LIBRARIES.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1156323</commentid>
    <comment_count>13</comment_count>
    <who name="Michael Catanzaro">mcatanzaro</who>
    <bug_when>2016-01-17 13:38:22 -0800</bug_when>
    <thetext>*** Bug 153093 has been marked as a duplicate of this bug. ***</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1174300</commentid>
    <comment_count>14</comment_count>
      <attachid>273923</attachid>
    <who name="Philip Chimento">philip.chimento</who>
    <bug_when>2016-03-13 21:17:37 -0700</bug_when>
    <thetext>Created attachment 273923
Doesn&apos;t fix the problem

I&apos;ve been trying to correct this, but have been trying various combinations of PUBLIC, PRIVATE, and INTERFACE all weekend (and waiting most times for WebCore to rebuild, as cmake doesn&apos;t seem to be able to determine that all I&apos;ve changed is the linking libraries). Attached is a work-in-progress patch (not formatted for committing) of what I have now, which doesn&apos;t fix the crash.

I think the problem is that I don&apos;t understand how the various convenience libraries should be linked together. From the other comments here, it seems it should be something like this:

WTF -&gt; convenience library, linked into JavaScriptCore
    -&gt; symbols used from JavaScriptCore, WebCore, and WebKit2

JavaScriptCore -&gt; public, uses and exports WTF symbols

WebCore -&gt; convenience library, linked into WebKit2
        -&gt; uses WTF and JavaScriptCore symbols
        -&gt; symbols used from WebKit2

WebKit2 -&gt; public, uses WTF, JavaScriptCore, WebCore symbols

I _think_ that&apos;s what I&apos;ve implemented in the patch, but I still end up with JavaScriptCore and WebKit2 each containing their own copy of WTF.

Advice would be appreciated.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1174458</commentid>
    <comment_count>15</comment_count>
    <who name="Michael Catanzaro">mcatanzaro</who>
    <bug_when>2016-03-14 08:05:04 -0700</bug_when>
    <thetext>(In reply to comment #14)
&gt; WTF -&gt; convenience library, linked into JavaScriptCore
&gt;     -&gt; symbols used from JavaScriptCore, WebCore, and WebKit2
&gt; 
&gt; JavaScriptCore -&gt; public, uses and exports WTF symbols
&gt; 
&gt; WebCore -&gt; convenience library, linked into WebKit2
&gt;         -&gt; uses WTF and JavaScriptCore symbols
&gt;         -&gt; symbols used from WebKit2
&gt; 
&gt; WebKit2 -&gt; public, uses WTF, JavaScriptCore, WebCore symbols

Yes, that&apos;s all correct.</thetext>
  </long_desc>
      
          <attachment
              isobsolete="0"
              ispatch="1"
              isprivate="0"
          >
            <attachid>273923</attachid>
            <date>2016-03-13 21:17:37 -0700</date>
            <delta_ts>2016-03-13 21:17:37 -0700</delta_ts>
            <desc>Doesn&apos;t fix the problem</desc>
            <filename>1.patch</filename>
            <type>text/plain</type>
            <size>2844</size>
            <attacher name="Philip Chimento">philip.chimento</attacher>
            
              <data encoding="base64">LS0tIC4vU291cmNlL0phdmFTY3JpcHRDb3JlL0NNYWtlTGlzdHMudHh0Lm9yaWcJMjAxNi0wMy0x
MyAxMDo1OTo0OC4wMDAwMDAwMDAgLTA3MDAKKysrIC4vU291cmNlL0phdmFTY3JpcHRDb3JlL0NN
YWtlTGlzdHMudHh0CTIwMTYtMDMtMTMgMTk6Mjk6MDEuMDAwMDAwMDAwIC0wNzAwCkBAIC04NzIs
MTAgKzg3MiwxMyBAQAogKQogCiBzZXQoSmF2YVNjcmlwdENvcmVfTElCUkFSSUVTCi0gICAgV1RG
JHtERUJVR19TVUZGSVh9CiAgICAgJHtJQ1VfSTE4Tl9MSUJSQVJJRVN9CiApCiAKK3NldChKYXZh
U2NyaXB0Q29yZV9QVUJMSUNfTElCUkFSSUVTCisgICAgV1RGJHtERUJVR19TVUZGSVh9CispCisK
IHNldChKYXZhU2NyaXB0Q29yZV9TQ1JJUFRTX1NPVVJDRVNfRElSICIke0pBVkFTQ1JJUFRDT1JF
X0RJUn0vU2NyaXB0cyIpCiAKICMgR2xvYmJpbmcgcmVsaWVzIG9uIHRoZSBmYWN0IHRoYXQgZ2Vu
ZXJhdG9yLXNwZWNpZmljIGZpbGUgbmFtZXMgYXJlIHByZWZpeGVkIHdpdGggdGhlaXIgZGlyZWN0
b3J5LgpAQCAtMTMxMyw3ICsxMzE2LDEwIEBACiBpbmNsdWRlX2RpcmVjdG9yaWVzKCR7SmF2YVNj
cmlwdENvcmVfSU5DTFVERV9ESVJFQ1RPUklFU30pCiBpbmNsdWRlX2RpcmVjdG9yaWVzKFNZU1RF
TSAke0phdmFTY3JpcHRDb3JlX1NZU1RFTV9JTkNMVURFX0RJUkVDVE9SSUVTfSkKIGFkZF9saWJy
YXJ5KEphdmFTY3JpcHRDb3JlICR7SmF2YVNjcmlwdENvcmVfTElCUkFSWV9UWVBFfSAke0phdmFT
Y3JpcHRDb3JlX0hFQURFUlN9ICR7SmF2YVNjcmlwdENvcmVfU09VUkNFU30pCi10YXJnZXRfbGlu
a19saWJyYXJpZXMoSmF2YVNjcmlwdENvcmUgJHtKYXZhU2NyaXB0Q29yZV9MSUJSQVJJRVN9KQor
dGFyZ2V0X2xpbmtfbGlicmFyaWVzKEphdmFTY3JpcHRDb3JlCisgICAgUFJJVkFURSAke0phdmFT
Y3JpcHRDb3JlX0xJQlJBUklFU30KKyAgICBQVUJMSUMgJHtKYXZhU2NyaXB0Q29yZV9QVUJMSUNf
TElCUkFSSUVTfQorKQogc2V0X3RhcmdldF9wcm9wZXJ0aWVzKEphdmFTY3JpcHRDb3JlIFBST1BF
UlRJRVMgQ09NUElMRV9ERUZJTklUSU9OUyAiQlVJTERJTkdfSmF2YVNjcmlwdENvcmUiKQogc2V0
X3RhcmdldF9wcm9wZXJ0aWVzKEphdmFTY3JpcHRDb3JlIFBST1BFUlRJRVMgRk9MREVSICJKYXZh
U2NyaXB0Q29yZSIpCiAKLS0tIC4vU291cmNlL1dlYkNvcmUvQ01ha2VMaXN0cy50eHQub3JpZwky
MDE2LTAzLTEzIDEwOjU1OjMyLjAwMDAwMDAwMCAtMDcwMAorKysgLi9Tb3VyY2UvV2ViQ29yZS9D
TWFrZUxpc3RzLnR4dAkyMDE2LTAzLTEzIDIwOjI0OjI1LjAwMDAwMDAwMCAtMDcwMApAQCAtMjk1
Nyw4ICsyOTU3LDEwIEBACiAKIHNldChXZWJDb3JlX0xJQlJBUklFUwogICAgICR7SUNVX0xJQlJB
UklFU30KKykKKworc2V0KFdlYkNvcmVfSU5URVJGQUNFX0xJQlJBUklFUwogICAgIEphdmFTY3Jp
cHRDb3JlJHtERUJVR19TVUZGSVh9Ci0gICAgV1RGJHtERUJVR19TVUZGSVh9CiApCiAKIGlmIChF
TkFCTEVfRU5DUllQVEVEX01FRElBIE9SIEVOQUJMRV9FTkNSWVBURURfTUVESUFfVjIpCkBAIC0z
ODEyLDcgKzM4MTQsMTAgQEAKICAgICBXRUJLSVRfU0VUX0VYVFJBX0NPTVBJTEVSX0ZMQUdTKEFO
R0xFU3VwcG9ydCBJR05PUkVDWFhfV0FSTklOR1MpCiBlbmRpZiAoKQogCi10YXJnZXRfbGlua19s
aWJyYXJpZXMoV2ViQ29yZSAke1dlYkNvcmVfTElCUkFSSUVTfSkKK3RhcmdldF9saW5rX2xpYnJh
cmllcyhXZWJDb3JlCisgICAgUFJJVkFURSAke1dlYkNvcmVfTElCUkFSSUVTfQorICAgIElOVEVS
RkFDRSAke1dlYkNvcmVfSU5URVJGQUNFX0xJQlJBUklFU30KKykKIAogaWYgKFNIQVJFRF9DT1JF
KQogICAgIHNldF90YXJnZXRfcHJvcGVydGllcyhXZWJDb3JlIFBST1BFUlRJRVMgVkVSU0lPTiAk
e1BST0pFQ1RfVkVSU0lPTn0gU09WRVJTSU9OICR7UFJPSkVDVF9WRVJTSU9OX01BSk9SfSkKLS0t
IC4vU291cmNlL1dlYktpdDIvQ01ha2VMaXN0cy50eHQub3JpZwkyMDE2LTAzLTEzIDEwOjU1OjEw
LjAwMDAwMDAwMCAtMDcwMAorKysgLi9Tb3VyY2UvV2ViS2l0Mi9DTWFrZUxpc3RzLnR4dAkyMDE2
LTAzLTEzIDIxOjA4OjM2LjAwMDAwMDAwMCAtMDcwMApAQCAtNzI2LDcgKzcyNiw3IEBACiApCiAK
IHNldChXZWJLaXQyX0xJQlJBUklFUwotICAgIEphdmFTY3JpcHRDb3JlCisgICAgJHtJQ1VfTElC
UkFSSUVTfQogICAgIFdlYkNvcmUKICkKIApAQCAtNzYxLDcgKzc2MSw3IEBACiAKIGFkZF9kZXBl
bmRlbmNpZXMoV2ViS2l0MiBXZWJDb3JlICR7V0VCS0lUMl9FWFRSQV9ERVBFTkRFTkNJRVN9KQog
YWRkX3dlYmtpdDJfcHJlZml4X2hlYWRlcihXZWJLaXQyKQotdGFyZ2V0X2xpbmtfbGlicmFyaWVz
KFdlYktpdDIgJHtXZWJLaXQyX0xJQlJBUklFU30pCit0YXJnZXRfbGlua19saWJyYXJpZXMoV2Vi
S2l0MiBQUklWQVRFICR7V2ViS2l0Ml9MSUJSQVJJRVN9KQogc2V0X3RhcmdldF9wcm9wZXJ0aWVz
KFdlYktpdDIgUFJPUEVSVElFUyBGT0xERVIgIldlYktpdCIpCiAKICMgU3VwcHJlc3MgdW51c2Vk
IHBhcmFtZXRlciB3YXJuaW5ncyBmb3Igc291cmNlcyBpbiBXZWJLaXQyLgotLS0gLi9Ub29scy9N
aW5pQnJvd3Nlci9ndGsvQ01ha2VMaXN0cy50eHQub3JpZwkyMDE2LTAzLTEzIDEwOjU4OjQyLjAw
MDAwMDAwMCAtMDcwMAorKysgLi9Ub29scy9NaW5pQnJvd3Nlci9ndGsvQ01ha2VMaXN0cy50eHQJ
MjAxNi0wMy0xMiAyMDoyNTo0MS4wMDAwMDAwMDAgLTA4MDAKQEAgLTM4LDYgKzM4LDcgQEAKICAg
ICBXZWJLaXQyCiAgICAgJHtHVEszX0xJQlJBUklFU30KICAgICAke0dMSUJfTElCUkFSSUVTfQor
ICAgICR7TElCU09VUF9MSUJSQVJJRVN9CiApCiAKIGFkZF9jdXN0b21fY29tbWFuZCgK
</data>

          </attachment>
      

    </bug>

</bugzilla>