98406 2012-10-04 07:37:43 -0700 Lower minimum table size of WTF::HashTable to reduce memory usage. 2013-01-04 12:00:08 -0800 1 1 1 Unclassified WebKit Web Template Framework 528+ (Nightly build) Unspecified Unspecified RESOLVED FIXED InRadar, Performance P2 Normal --- 1 kling kling andersca benjamin dpranke ggaren koivisto naginenis psolanki rakuco simon.fraser webkit-bug-importer webkit.review.bot xan.lopez oldest_to_newest 734667 0 kling 2012-10-04 07:37:43 -0700 WTF's hash tables currently start out with a table size of 64 entries. A lot of this space ends up wasted, and my testing (PLT, JS benchmarks) indicates that we can bring it down as low as 8 without taking a performance hit. The memory savings from this would be borderline epic. Should there be a performance regression from this, individual hash tables can be tweaked to start out with a larger size. 734672 1 webkit-bug-importer 2012-10-04 07:38:39 -0700 <rdar://problem/12432140> 734676 2 167099 kling 2012-10-04 07:45:41 -0700 Created attachment 167099 Patch 734677 3 167099 andersca 2012-10-04 07:47:33 -0700 Comment on attachment 167099 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=167099&action=review > Source/WTF/wtf/HashTraits.h:54 > + // The starting table size. Can be overridden when we know beforehand that a hash table will have > + // at least N entries. I think putting the line break after "that" will look better. 734686 4 167101 kling 2012-10-04 07:53:16 -0700 Created attachment 167101 Bomb's away! 734701 5 ggaren 2012-10-04 08:10:17 -0700 I approve this message! 734929 6 167101 webkit.review.bot 2012-10-04 12:32:28 -0700 Comment on attachment 167101 Bomb's away! Rejecting attachment 167101 from commit-queue. New failing tests: editing/pasteboard/data-transfer-items.html Full output: http://queues.webkit.org/results/14152612 734934 7 167101 kling 2012-10-04 12:49:23 -0700 Comment on attachment 167101 Bomb's away! Clearing flags on attachment: 167101 Committed r130419: <http://trac.webkit.org/changeset/130419> 734936 8 kling 2012-10-04 12:49:35 -0700 All reviewed patches have been landed. Closing bug. 735068 9 rakuco 2012-10-04 15:22:38 -0700 Any chances of this having caused a regression in the JSC tests? http://build.webkit.org/builders/EFL%20Linux%2064-bit%20Debug/builds/6763/steps/jscore-test/logs/stdio The Apple, GTK+ and Qt bots are failing similarly as well after this commit. 735101 10 kling 2012-10-04 16:15:31 -0700 (In reply to comment #9) > Any chances of this having caused a regression in the JSC tests? > > http://build.webkit.org/builders/EFL%20Linux%2064-bit%20Debug/builds/6763/steps/jscore-test/logs/stdio > > The Apple, GTK+ and Qt bots are failing similarly as well after this commit. I haven't a clue why this goes wrong, debugging now.. Basically, the following JS will print FAIL: Math.min(1.0000000001,1) print( Infinity/Math.min(0,-0) == Infinity ? "FAIL" : "PASS" ) If the first call to Math.min() is removed, it works correctly. 735103 11 kling 2012-10-04 16:16:40 -0700 I should say that it fails because "Infinity/Math.min(0,-0)" returns -Infinity instead of Infinity, 735104 12 kling 2012-10-04 16:17:47 -0700 (In reply to comment #11) > I should say that it fails because "Infinity/Math.min(0,-0)" returns -Infinity instead of Infinity, Sigh. I should say that correctly. Infinity/Math.min(0,-0) returns Infinity instead of -Infinity. Unless the preceding call to Math.min(1.0000000001,1) is removed, in which case it correctly returns -Infinity. Back to debugging. 735155 13 simon.fraser 2012-10-04 17:19:31 -0700 This was a dup of bug 86279 :( 735172 14 dpranke 2012-10-04 17:34:13 -0700 Reverted r130419 for reason: broke editing/pasteboard/data-transfer-items.html on chromium Committed r130436: <http://trac.webkit.org/changeset/130436> 735177 15 dpranke 2012-10-04 17:36:12 -0700 http://test-results.appspot.com/dashboards/flakiness_dashboard.html#tests=editing%2Fpasteboard%2Fdata-transfer-items.html 736687 16 167101 kling 2012-10-08 08:11:26 -0700 Comment on attachment 167101 Bomb's away! Clearing flags on attachment: 167101 Committed r130643: <http://trac.webkit.org/changeset/130643> 736688 17 kling 2012-10-08 08:11:36 -0700 All reviewed patches have been landed. Closing bug. 743100 18 xan.lopez 2012-10-16 06:12:30 -0700 After some painful debug build bisecting (thanks Joanie!), it seems this is causing a very easy to trigger ASSERT in GTK+ debug builds: Program received signal SIGSEGV, Segmentation fault. 0x00007ffff47c8aa8 in WTF::HashTable<WTF::RefPtr<WebCore::PluginPackage>, WTF::RefPtr<WebCore::PluginPackage>, WTF::IdentityExtractor, WebCore::PluginPackageHash, WTF::HashTraits<WTF::RefPtr<WebCore::PluginPackage> >, WTF::HashTraits<WTF::RefPtr<WebCore::PluginPackage> > >::add<WTF::IdentityHashTranslator<WebCore::PluginPackageHash>, WTF::RefPtr<WebCore::PluginPackage>, WTF::RefPtr<WebCore::PluginPackage> > (this=0x1102a40, key=..., extra=...) at ../../Source/WTF/wtf/HashTable.h:894 894 ASSERT(result.iterator != end()); Missing separate debuginfos, use: debuginfo-install google-talkplugin-3.9.1.0-1.x86_64 (gdb) bt #0 0x00007ffff47c8aa8 in WTF::HashTable<WTF::RefPtr<WebCore::PluginPackage>, WTF::RefPtr<WebCore::PluginPackage>, WTF::IdentityExtractor, WebCore::PluginPackageHash, WTF::HashTraits<WTF::RefPtr<WebCore::PluginPackage> >, WTF::HashTraits<WTF::RefPtr<WebCore::PluginPackage> > >::add<WTF::IdentityHashTranslator<WebCore::PluginPackageHash>, WTF::RefPtr<WebCore::PluginPackage>, WTF::RefPtr<WebCore::PluginPackage> > (this=0x1102a40, key=..., extra=...) at ../../Source/WTF/wtf/HashTable.h:894 #1 0x00007ffff47c6379 in WTF::HashTable<WTF::RefPtr<WebCore::PluginPackage>, WTF::RefPtr<WebCore::PluginPackage>, WTF::IdentityExtractor, WebCore::PluginPackageHash, WTF::HashTraits<WTF::RefPtr<WebCore::PluginPackage> >, WTF::HashTraits<WTF::RefPtr<WebCore::PluginPackage> > >::add (this=0x1102a40, value=...) at ../../Source/WTF/wtf/HashTable.h:393 #2 0x00007ffff47c4153 in WTF::HashSet<WTF::RefPtr<WebCore::PluginPackage>, WebCore::PluginPackageHash, WTF::HashTraits<WTF::RefPtr<WebCore::PluginPackage> > >::add (this=0x1102a40, value=...) at ../../Source/WTF/wtf/HashSet.h:183 #3 0x00007ffff47c2833 in WebCore::PluginDatabase::add (this=0x1102a00, prpPackage=...) at ../../Source/WebCore/plugins/PluginDatabase.cpp:330 #4 0x00007ffff47c1a5c in WebCore::PluginDatabase::refresh (this=0x1102a00) at ../../Source/WebCore/plugins/PluginDatabase.cpp:146 #5 0x00007ffff47c15c3 in WebCore::PluginDatabase::installedPlugins (populate=true) at ../../Source/WebCore/plugins/PluginDatabase.cpp:75 #6 0x00007ffff3d0332e in PlatformStrategiesGtk::getPluginInfo (this=0x57bc30, page=0x5c2800, outPlugins=...) at ../../Source/WebKit/gtk/WebCoreSupport/PlatformStrategiesGtk.cpp:75 #7 0x00007ffff47cc74a in WebCore::PluginData::initPlugins (this=0x12d5060, page=0x5c2800) at ../../Source/WebCore/plugins/PluginData.cpp:77 #8 0x00007ffff47cc494 in WebCore::PluginData::PluginData (this=0x12d5060, page=0x5c2800) at ../../Source/WebCore/plugins/PluginData.cpp:36 #9 0x00007ffff4656c15 in WebCore::PluginData::create (page=0x5c2800) at ../../Source/WebCore/plugins/PluginData.h:74 #10 0x00007ffff4653704 in WebCore::Page::pluginData (this=0x5c2800) at ../../Source/WebCore/page/Page.cpp:463 #11 0x00007ffff47c0762 in WebCore::DOMPluginArray::pluginData (this=0x130f390) at ../../Source/WebCore/plugins/DOMPluginArray.cpp:97 #12 0x00007ffff47c0571 in WebCore::DOMPluginArray::canGetItemsForName (this=0x130f390, propertyName=...) at ../../Source/WebCore/plugins/DOMPluginArray.cpp:61 #13 0x00007ffff3e4f4c7 in WebCore::JSDOMPluginArray::canGetItemsForName (pluginArray=0x130f390, propertyName=...) at ../../Source/WebCore/bindings/js/JSDOMPluginArrayCustom.cpp:33 #14 0x00007ffff4d8959e in WebCore::JSDOMPluginArray::getOwnPropertySlot (cell=0x7fff9a5cf4e0, exec=0x7fffa0095250, propertyName=..., slot=...) at DerivedSources/WebCore/JSDOMPluginArray.cpp:154 #15 0x00007ffff7849ab3 in JSC::JSCell::fastGetOwnPropertySlot (this=0x7fff9a5cf4e0, exec=0x7fffa0095250, propertyName=..., slot=...) at ../../Source/JavaScriptCore/runtime/JSObject.h:1017 #16 0x00007ffff794d0ec in JSC::JSValue::get (this=0x7fffffffb830, exec=0x7fffa0095250, propertyName=..., slot=...) at ../../Source/JavaScriptCore/runtime/JSObject.h:1273 #17 0x00007ffff794d031 in JSC::JSValue::get (this=0x7fffffffb830, exec=0x7fffa0095250, propertyName=...) at ../../Source/JavaScriptCore/runtime/JSObject.h:1260 #18 0x00007ffff7a50121 in JSC::LLInt::getByVal (exec=0x7fffa0095250, baseValue=..., subscript=...) at ../../Source/JavaScriptCore/llint/LLIntSlowPaths.cpp:1031 #19 0x00007ffff7a49e73 in JSC::LLInt::llint_slow_path_get_by_val (exec=0x7fffa0095250, pc=0xe5bf28) at ../../Source/JavaScriptCore/llint/LLIntSlowPaths.cpp:1037 #20 0x00007ffff7a52bd6 in llint_op_get_by_val () from /home/xan/git/webkit/build/debug/.libs/libjavascriptcoregtk-3.0.so #21 0x00007fffffffb950 in ?? () #22 0x00007fff99195440 in ?? () #23 0x0000000000b29c90 in ?? () #24 0x00007fff99195580 in ?? () #25 0x00007fffffffb960 in ?? () #26 0x00007fff98576580 in ?? () #27 0x00007ffff7fe8ae0 in ?? () from /home/xan/git/webkit/build/debug/.libs/libjavascriptcoregtk-3.0.so #28 0x00007ffff7286be0 in ?? () from /home/xan/git/webkit/build/debug/.libs/libwebkitgtk-3.0.so #29 0x00007fffffffb990 in ?? () #30 0x00007fffa3fff380 in ?? () #31 0x00000000005ec7b8 in ?? () #32 0x00007fffa0095088 in ?? () #33 0x0000000000000000 in ?? () Not sure what's going on. Does some other value somewhere need to be tweaked to be in sync with this change? 743294 19 kling 2012-10-16 10:49:22 -0700 (In reply to comment #18) > After some painful debug build bisecting (thanks Joanie!), it seems this is causing a very easy to trigger ASSERT in GTK+ debug builds: > > Program received signal SIGSEGV, Segmentation fault. > 0x00007ffff47c8aa8 in WTF::HashTable<WTF::RefPtr<WebCore::PluginPackage>, WTF::RefPtr<WebCore::PluginPackage>, WTF::IdentityExtractor, WebCore::PluginPackageHash, WTF::HashTraits<WTF::RefPtr<WebCore::PluginPackage> >, WTF::HashTraits<WTF::RefPtr<WebCore::PluginPackage> > >::add<WTF::IdentityHashTranslator<WebCore::PluginPackageHash>, WTF::RefPtr<WebCore::PluginPackage>, WTF::RefPtr<WebCore::PluginPackage> > (this=0x1102a40, key=..., extra=...) at ../../Source/WTF/wtf/HashTable.h:894 > 894 ASSERT(result.iterator != end()); > Missing separate debuginfos, use: debuginfo-install google-talkplugin-3.9.1.0-1.x86_64 > (gdb) bt > #0 0x00007ffff47c8aa8 in WTF::HashTable<WTF::RefPtr<WebCore::PluginPackage>, WTF::RefPtr<WebCore::PluginPackage>, WTF::IdentityExtractor, WebCore::PluginPackageHash, WTF::HashTraits<WTF::RefPtr<WebCore::PluginPackage> >, WTF::HashTraits<WTF::RefPtr<WebCore::PluginPackage> > >::add<WTF::IdentityHashTranslator<WebCore::PluginPackageHash>, WTF::RefPtr<WebCore::PluginPackage>, WTF::RefPtr<WebCore::PluginPackage> > (this=0x1102a40, key=..., extra=...) at ../../Source/WTF/wtf/HashTable.h:894 > #1 0x00007ffff47c6379 in WTF::HashTable<WTF::RefPtr<WebCore::PluginPackage>, WTF::RefPtr<WebCore::PluginPackage>, WTF::IdentityExtractor, WebCore::PluginPackageHash, WTF::HashTraits<WTF::RefPtr<WebCore::PluginPackage> >, WTF::HashTraits<WTF::RefPtr<WebCore::PluginPackage> > >::add (this=0x1102a40, value=...) at ../../Source/WTF/wtf/HashTable.h:393 > #2 0x00007ffff47c4153 in WTF::HashSet<WTF::RefPtr<WebCore::PluginPackage>, WebCore::PluginPackageHash, WTF::HashTraits<WTF::RefPtr<WebCore::PluginPackage> > >::add (this=0x1102a40, value=...) at ../../Source/WTF/wtf/HashSet.h:183 > #3 0x00007ffff47c2833 in WebCore::PluginDatabase::add (this=0x1102a00, prpPackage=...) at ../../Source/WebCore/plugins/PluginDatabase.cpp:330 My guess is that this is caused by the rickety looking PluginPackageHash here: http://trac.webkit.org/browser/trunk/Source/WebCore/plugins/PluginPackage.h#L127 Notice that hash(x) will hash m_path and m_lastModified, while equal(x, y) will just compare m_description, meaning that two RefPtr<PluginPackage> that are "equal" according to PluginPackageHash will have different hashes. Badness will then happen if they end up in the same hash bucket, much like on bug 98627. I'm not sure what the correct fix is here, maybe someone with plug-in experience could weigh in. 743448 20 andersca 2012-10-16 12:59:15 -0700 (In reply to comment #19) > (In reply to comment #18) > > After some painful debug build bisecting (thanks Joanie!), it seems this is causing a very easy to trigger ASSERT in GTK+ debug builds: > > > > Program received signal SIGSEGV, Segmentation fault. > > 0x00007ffff47c8aa8 in WTF::HashTable<WTF::RefPtr<WebCore::PluginPackage>, WTF::RefPtr<WebCore::PluginPackage>, WTF::IdentityExtractor, WebCore::PluginPackageHash, WTF::HashTraits<WTF::RefPtr<WebCore::PluginPackage> >, WTF::HashTraits<WTF::RefPtr<WebCore::PluginPackage> > >::add<WTF::IdentityHashTranslator<WebCore::PluginPackageHash>, WTF::RefPtr<WebCore::PluginPackage>, WTF::RefPtr<WebCore::PluginPackage> > (this=0x1102a40, key=..., extra=...) at ../../Source/WTF/wtf/HashTable.h:894 > > 894 ASSERT(result.iterator != end()); > > Missing separate debuginfos, use: debuginfo-install google-talkplugin-3.9.1.0-1.x86_64 > > (gdb) bt > > #0 0x00007ffff47c8aa8 in WTF::HashTable<WTF::RefPtr<WebCore::PluginPackage>, WTF::RefPtr<WebCore::PluginPackage>, WTF::IdentityExtractor, WebCore::PluginPackageHash, WTF::HashTraits<WTF::RefPtr<WebCore::PluginPackage> >, WTF::HashTraits<WTF::RefPtr<WebCore::PluginPackage> > >::add<WTF::IdentityHashTranslator<WebCore::PluginPackageHash>, WTF::RefPtr<WebCore::PluginPackage>, WTF::RefPtr<WebCore::PluginPackage> > (this=0x1102a40, key=..., extra=...) at ../../Source/WTF/wtf/HashTable.h:894 > > #1 0x00007ffff47c6379 in WTF::HashTable<WTF::RefPtr<WebCore::PluginPackage>, WTF::RefPtr<WebCore::PluginPackage>, WTF::IdentityExtractor, WebCore::PluginPackageHash, WTF::HashTraits<WTF::RefPtr<WebCore::PluginPackage> >, WTF::HashTraits<WTF::RefPtr<WebCore::PluginPackage> > >::add (this=0x1102a40, value=...) at ../../Source/WTF/wtf/HashTable.h:393 > > #2 0x00007ffff47c4153 in WTF::HashSet<WTF::RefPtr<WebCore::PluginPackage>, WebCore::PluginPackageHash, WTF::HashTraits<WTF::RefPtr<WebCore::PluginPackage> > >::add (this=0x1102a40, value=...) at ../../Source/WTF/wtf/HashSet.h:183 > > #3 0x00007ffff47c2833 in WebCore::PluginDatabase::add (this=0x1102a00, prpPackage=...) at ../../Source/WebCore/plugins/PluginDatabase.cpp:330 > > My guess is that this is caused by the rickety looking PluginPackageHash here: http://trac.webkit.org/browser/trunk/Source/WebCore/plugins/PluginPackage.h#L127 > > Notice that hash(x) will hash m_path and m_lastModified, while equal(x, y) will just compare m_description, meaning that two RefPtr<PluginPackage> that are "equal" according to PluginPackageHash will have different hashes. Badness will then happen if they end up in the same hash bucket, much like on bug 98627. I'm not sure what the correct fix is here, maybe someone with plug-in experience could weigh in. Given how broken that hash is, I think you should just hard code the size to 64 for this hash table and file a FIXME bug. 799988 21 167099 eric 2013-01-04 00:43:07 -0800 Comment on attachment 167099 Patch Cleared Anders Carlsson's review+ from obsolete attachment 167099 so that this bug does not appear in http://webkit.org/pending-commit. 800475 22 psolanki 2013-01-04 12:00:08 -0800 The patch has been checked in and this bug is fixed. Moving back to Resolved. Xan, can you file a separate bug for the GTK assertion if it is still an issue? We should track that separately instead of reopening this bug. 167099 2012-10-04 07:45:41 -0700 2013-01-04 00:43:07 -0800 Patch bug-98406.diff text/plain 1615 kling ZGlmZiAtLWdpdCBhL1NvdXJjZS9XVEYvQ2hhbmdlTG9nIGIvU291cmNlL1dURi9DaGFuZ2VMb2cK aW5kZXggNDNjZjZjMi4uYmRkMzVkZCAxMDA2NDQKLS0tIGEvU291cmNlL1dURi9DaGFuZ2VMb2cK KysrIGIvU291cmNlL1dURi9DaGFuZ2VMb2cKQEAgLTEsMyArMSwxOSBAQAorMjAxMi0xMC0wNCAg QW5kcmVhcyBLbGluZyAgPGtsaW5nQHdlYmtpdC5vcmc+CisKKyAgICAgICAgTG93ZXIgbWluaW11 bSB0YWJsZSBzaXplIG9mIFdURjo6SGFzaFRhYmxlIHRvIHJlZHVjZSBtZW1vcnkgdXNhZ2UuCisg ICAgICAgIDxodHRwOi8vd2Via2l0Lm9yZy9iLzk4NDA2PgorICAgICAgICA8cmRhcjovL3Byb2Js ZW0vMTI0MzIxNDA+CisKKyAgICAgICAgUmV2aWV3ZWQgYnkgTk9CT0RZIChPT1BTISkuCisKKyAg ICAgICAgTG93ZXIgdGhlIGRlZmF1bHQgbWluaW11bVRhYmxlU2l6ZSBmb3IgV1RGIGhhc2ggdGFi bGVzIGZyb20gNjQgdG8gOCBlbnRyaWVzLgorICAgICAgICBUaGlzIHJlZHVjZXMgV2ViUHJvY2Vz cyBtZW1vcnkgY29uc3VtcHRpb24gYnkgfjE2TUIgb24gTWVtYnVzdGVyMyAoYSA2JSBwcm9ncmVz c2lvbiEpCisKKyAgICAgICAgTm8gc2lnbmlmaWNhbnQgbW92ZW1lbnQgb24gUExUIG9yIEpTQyBi ZW5jaG1hcmtzIG9uIG15IG1hY2hpbmUuIElmIHRoZXJlJ3MgYSBwZXJmIHJlZ3Jlc3Npb24gc29t ZXdoZXJlCisgICAgICAgIGZyb20gdGhpcywgd2UgY2FuIHR3ZWFrIGluZGl2aWR1YWwgdGFibGVz IHRvIGhhdmUgYSBsYXJnZXIgbWluaW11bVRhYmxlU2l6ZS4KKworICAgICAgICAqIHd0Zi9IYXNo VHJhaXRzLmg6CisKIDIwMTItMTAtMDMgIFl1cnkgU2VtaWtoYXRza3kgIDx5dXJ5c0BjaHJvbWl1 bS5vcmc+CiAKICAgICAgICAgUmVtb3ZlIE1lbW9yeUluc3RydW1lbnRhdGlvbjo6YWRkQ29sbGVj dGlvbkVsZW1lbnRzCmRpZmYgLS1naXQgYS9Tb3VyY2UvV1RGL3d0Zi9IYXNoVHJhaXRzLmggYi9T b3VyY2UvV1RGL3d0Zi9IYXNoVHJhaXRzLmgKaW5kZXggNDMwNTQzMC4uNjdjYmQ4NiAxMDA2NDQK LS0tIGEvU291cmNlL1dURi93dGYvSGFzaFRyYWl0cy5oCisrKyBiL1NvdXJjZS9XVEYvd3RmL0hh c2hUcmFpdHMuaApAQCAtNTAsNyArNTAsOSBAQCBuYW1lc3BhY2UgV1RGIHsKICAgICAgICAgLy8g VGhlIG5lZWRzRGVzdHJ1Y3Rpb24gZmxhZyBpcyB1c2VkIHRvIG9wdGltaXplIGRlc3RydWN0aW9u IGFuZCByZWhhc2hpbmcuCiAgICAgICAgIHN0YXRpYyBjb25zdCBib29sIG5lZWRzRGVzdHJ1Y3Rp b24gPSB0cnVlOwogCi0gICAgICAgIHN0YXRpYyBjb25zdCBpbnQgbWluaW11bVRhYmxlU2l6ZSA9 IDY0OworICAgICAgICAvLyBUaGUgc3RhcnRpbmcgdGFibGUgc2l6ZS4gQ2FuIGJlIG92ZXJyaWRk ZW4gd2hlbiB3ZSBrbm93IGJlZm9yZWhhbmQgdGhhdCBhIGhhc2ggdGFibGUgd2lsbCBoYXZlCisg ICAgICAgIC8vIGF0IGxlYXN0IE4gZW50cmllcy4KKyAgICAgICAgc3RhdGljIGNvbnN0IGludCBt aW5pbXVtVGFibGVTaXplID0gODsKICAgICB9OwogCiAgICAgLy8gRGVmYXVsdCBpbnRlZ2VyIHRy YWl0cyBkaXNhbGxvdyBib3RoIDAgYW5kIC0xIGFzIGtleXMgKG1heCB2YWx1ZSBpbnN0ZWFkIG9m IC0xIGZvciB1bnNpZ25lZCkuCg== 167101 2012-10-04 07:53:16 -0700 2012-10-08 08:11:26 -0700 Bomb's away! land-98406.diff text/plain 1616 kling ZGlmZiAtLWdpdCBhL1NvdXJjZS9XVEYvQ2hhbmdlTG9nIGIvU291cmNlL1dURi9DaGFuZ2VMb2cK aW5kZXggNDNjZjZjMi4uYWI4MzdkNiAxMDA2NDQKLS0tIGEvU291cmNlL1dURi9DaGFuZ2VMb2cK KysrIGIvU291cmNlL1dURi9DaGFuZ2VMb2cKQEAgLTEsMyArMSwxOSBAQAorMjAxMi0xMC0wNCAg QW5kcmVhcyBLbGluZyAgPGtsaW5nQHdlYmtpdC5vcmc+CisKKyAgICAgICAgTG93ZXIgbWluaW11 bSB0YWJsZSBzaXplIG9mIFdURjo6SGFzaFRhYmxlIHRvIHJlZHVjZSBtZW1vcnkgdXNhZ2UuCisg ICAgICAgIDxodHRwOi8vd2Via2l0Lm9yZy9iLzk4NDA2PgorICAgICAgICA8cmRhcjovL3Byb2Js ZW0vMTI0MzIxNDA+CisKKyAgICAgICAgUmV2aWV3ZWQgYnkgQW5kZXJzIENhcmxzc29uLgorCisg ICAgICAgIExvd2VyIHRoZSBkZWZhdWx0IG1pbmltdW1UYWJsZVNpemUgZm9yIFdURiBoYXNoIHRh YmxlcyBmcm9tIDY0IHRvIDggZW50cmllcy4KKyAgICAgICAgVGhpcyByZWR1Y2VzIFdlYlByb2Nl c3MgbWVtb3J5IGNvbnN1bXB0aW9uIGJ5IH4xNk1CIG9uIE1lbWJ1c3RlcjMgKGEgNiUgcHJvZ3Jl c3Npb24hKQorCisgICAgICAgIE5vIHNpZ25pZmljYW50IG1vdmVtZW50IG9uIFBMVCBvciBKU0Mg YmVuY2htYXJrcyBvbiBteSBtYWNoaW5lLiBJZiB0aGVyZSdzIGEgcGVyZiByZWdyZXNzaW9uIHNv bWV3aGVyZQorICAgICAgICBmcm9tIHRoaXMsIHdlIGNhbiB0d2VhayBpbmRpdmlkdWFsIHRhYmxl cyB0byBoYXZlIGEgbGFyZ2VyIG1pbmltdW1UYWJsZVNpemUuCisKKyAgICAgICAgKiB3dGYvSGFz aFRyYWl0cy5oOgorCiAyMDEyLTEwLTAzICBZdXJ5IFNlbWlraGF0c2t5ICA8eXVyeXNAY2hyb21p dW0ub3JnPgogCiAgICAgICAgIFJlbW92ZSBNZW1vcnlJbnN0cnVtZW50YXRpb246OmFkZENvbGxl Y3Rpb25FbGVtZW50cwpkaWZmIC0tZ2l0IGEvU291cmNlL1dURi93dGYvSGFzaFRyYWl0cy5oIGIv U291cmNlL1dURi93dGYvSGFzaFRyYWl0cy5oCmluZGV4IDQzMDU0MzAuLmJlOWY2ZTAgMTAwNjQ0 Ci0tLSBhL1NvdXJjZS9XVEYvd3RmL0hhc2hUcmFpdHMuaAorKysgYi9Tb3VyY2UvV1RGL3d0Zi9I YXNoVHJhaXRzLmgKQEAgLTUwLDcgKzUwLDkgQEAgbmFtZXNwYWNlIFdURiB7CiAgICAgICAgIC8v IFRoZSBuZWVkc0Rlc3RydWN0aW9uIGZsYWcgaXMgdXNlZCB0byBvcHRpbWl6ZSBkZXN0cnVjdGlv biBhbmQgcmVoYXNoaW5nLgogICAgICAgICBzdGF0aWMgY29uc3QgYm9vbCBuZWVkc0Rlc3RydWN0 aW9uID0gdHJ1ZTsKIAotICAgICAgICBzdGF0aWMgY29uc3QgaW50IG1pbmltdW1UYWJsZVNpemUg PSA2NDsKKyAgICAgICAgLy8gVGhlIHN0YXJ0aW5nIHRhYmxlIHNpemUuIENhbiBiZSBvdmVycmlk ZGVuIHdoZW4gd2Uga25vdyBiZWZvcmVoYW5kIHRoYXQKKyAgICAgICAgLy8gYSBoYXNoIHRhYmxl IHdpbGwgaGF2ZSBhdCBsZWFzdCBOIGVudHJpZXMuCisgICAgICAgIHN0YXRpYyBjb25zdCBpbnQg bWluaW11bVRhYmxlU2l6ZSA9IDg7CiAgICAgfTsKIAogICAgIC8vIERlZmF1bHQgaW50ZWdlciB0 cmFpdHMgZGlzYWxsb3cgYm90aCAwIGFuZCAtMSBhcyBrZXlzIChtYXggdmFsdWUgaW5zdGVhZCBv ZiAtMSBmb3IgdW5zaWduZWQpLgo=