49650 2010-11-17 00:56:27 -0800 REGRESSION: [Qt] QNetworkReply delivered by the unsupportedContent() signal does not contain downloaded data 2011-08-18 07:01:01 -0700 1 1 1 Unclassified WebKit Page Loading 528+ (Nightly build) All All RESOLVED WONTFIX Qt, QtTriaged P1 Critical --- 1 frank.fischer kling adawit ademar benjamin cmarcelo frank.fischer jhanssen kling laszlo.gombos luiz markus menard peter.hartmann sfcheng zecke oldest_to_newest 310156 0 frank.fischer 2010-11-17 00:56:27 -0800 It's not possible to get any data except meta data from the reply submitted with the unsupportedContent(QNetworkReply*) Signal since Qt 4.7. USECASE: - configure a webview to forward unsupported content - connect the signal with a propper slot - open the webview - klick on a download link (something with mime type "application/octet-stream" for example) - if the debugging steps into the slot connected to the unsupported content signal only meta data are available (not bad so far) - in the slot wait for finishing the reply (takes longer then usual as if no the reply does not have a connection anymore) - after the reply finished reply->size() will return 0 and also reply->header(QNetworkRequest::ContentLengthHeader) will return 0 310219 1 benjamin 2010-11-17 05:33:58 -0800 Could you please attach a simple test case so we can run in and just start to debug? 310260 2 74109 frank.fischer 2010-11-17 07:06:32 -0800 Created attachment 74109 3 src files containing a little usecase for the bug Here is a little test case provided with workaround (commented out). The problem is that this workaround only works for "GET" requests. But I expect some unsupportedContent after "POST" or "PUT" requests. Moreover I find it bad style to request twice the same just because the first request does not what it's expected to do. Until Qt 4.6.3 this worked fine without workaround and all. 310277 3 benjamin 2010-11-17 07:44:55 -0800 Moving to P1, quite a bad regression. Downloading the package of http://qt.nokia.com/downloads/qt-creator-source-package does not work. It might be a QNAM problem, I have no problem with KIO. 331623 4 jhanssen 2011-01-10 07:43:55 -0800 Initial investigation shows that the problem is related to the move from QueuedConnection to AutoConnection in QNetworkReplyHandler.cpp. The issue is that when DirectConnection is being used, QWebPage::unsupportedContent(QNetworkReply*) is being emitted in a slot connected to QTcpSocket::readyRead(). But if you open a modal dialog or just use a QEventLoop then the readyRead() signal emission won't return and thus the tcp packet is not ACK'ed. I'm not really sure how to solve this, not even sure it can be solved in WebKit without going back to QueuedConnection. 331691 5 benjamin 2011-01-10 10:43:07 -0800 Adding Holger, he knows those stuffs. 331700 6 zecke 2011-01-10 10:49:46 -0800 (In reply to comment #5) > Adding Holger, he knows those stuffs. Tricky. I don't have a fast answer and will need to take a look at it, I will try to find some time. 336804 7 sfcheng 2011-01-19 14:27:46 -0800 I am probably having the same problem here. I am implementing my own download manager by handling QWebPage::unsupportContent(QNetworkReply *reply). If I add a modal dialog in the handler to obtain the download confirmation with the user, the reply object will be no longer return any data. reply->isFinished() will return true after that. If no dialog is shown and I directly proceed to download the file, everything is fine. The same problem happens if I add some time delay with app event loop processing in the middle, for example: int nMilSeconds=100; QTime dieTime = QTime::currentTime().addMSecs(nMilSeconds); while( QTime::currentTime() < dieTime ) { qApp->sendPostedEvents(); qApp->processEvents(QEventLoop::AllEvents,nMilSeconds); } Jan, could you confirm whether this is the same problem as what you described? Have you guys have any update or workaround on this? Thanks a lot. Stephen. 337023 8 jhanssen 2011-01-19 18:30:51 -0800 (In reply to comment #7) > Jan, could you confirm whether this is the same problem as what you described? Have you guys have any update or workaround on this? That does sound like the same issue, yes. If you control your local WebKit source then you could always revert to using QueuedConnection in QNetworkReplyHandler.cpp, I believe the change to AutoConnection was done for performance reasons and you should have no other issues with doing this than things getting a bit slower. Another possible solution (though I can't say for sure this will work) could be to not open your dialog in a slot connected to unsupportContent(), but instead do a queued slot invokation (e.g. using a single-shot timer) and do the dialog execution there. 338662 9 sfcheng 2011-01-22 19:55:11 -0800 Jan, I tried your proposal of using a queued slot but it didn't work. Even if I convert the modal dialog into a non-modal dialog and initiate the file download when the dialog is closed, the reply object gets closed. Only if I hook proper receiving slots to signals such as readyRead(),finished(), downloadProgress() first (i.e., we are actually starting the download) and then show a modal dialog, the download goes fine. I guess when the app event loop starts and there are no receiving slots for the reply connection, the connection is automatically closed. If there is way to postpone processing events and signals from the reply connection object while keep pumping other app events, that'd work as well. I am still pretty green to QT and am not aware of such advanced techniques. I really would like to inform the user first before actually burning the bandwidth. I hope you guys can find some effective to resolve this issue in the next Qt release. Thanks a lot. 338698 10 benjamin 2011-01-23 08:37:07 -0800 (In reply to comment #9) > Jan, I tried your proposal of using a queued slot [...] This is no place to ask for support, especially to Jan Erik who is a benevolent contributor. You are free to comment if want to help fixing this in WebKit, but please use the forum (http://developer.qt.nokia.com/forums/viewforum/21/ ) to get workaround and the like. 370130 11 kling 2011-03-19 08:34:47 -0700 Taking and blocking 2.2 release on this. 370134 12 86264 kling 2011-03-19 08:59:32 -0700 Created attachment 86264 Proposed patch 370326 13 86264 menard 2011-03-21 04:19:25 -0700 Comment on attachment 86264 Proposed patch Looks good to me : r+ 370330 14 zecke 2011-03-21 04:42:36 -0700 No unit test? sorry to be the pain. 378728 15 86264 benjamin 2011-04-04 04:27:53 -0700 Comment on attachment 86264 Proposed patch What about testing with a custom QNam? This sounds like regression invitation otherwise. Some dude will come in two years, think this queued signal is legacy and remove it. :-D 384001 16 kling 2011-04-12 07:51:32 -0700 Righto. This should be fixed in Qt, reported: http://bugreports.qt.nokia.com/browse/QTBUG-18718 Leaving this open to track progress. 412819 17 luiz 2011-05-31 13:26:11 -0700 It seems to be a big problem that we should solve for QtWebKit-2.2. Don't you think that we should land the proposed patch until the problem is properly solved in QNAM? 412839 18 benjamin 2011-05-31 13:55:21 -0700 (In reply to comment #17) > It seems to be a big problem that we should solve for QtWebKit-2.2. > Don't you think that we should land the proposed patch until the problem is properly solved in QNAM? You are right, we should do that. I suggest to push that in trunk with a comment mentioning http://bugreports.qt.nokia.com/browse/QTBUG-18718 Then we cherry pick to 2.2. 412914 19 kling 2011-05-31 15:11:33 -0700 (In reply to comment #18) > (In reply to comment #17) > > It seems to be a big problem that we should solve for QtWebKit-2.2. > > Don't you think that we should land the proposed patch until the problem is properly solved in QNAM? > > You are right, we should do that. > > I suggest to push that in trunk with a comment mentioning http://bugreports.qt.nokia.com/browse/QTBUG-18718 > Then we cherry pick to 2.2. Candycakes! I'll land it with a comment, then. 413308 20 kling 2011-06-01 05:40:01 -0700 Committed r87797: <http://trac.webkit.org/changeset/87797> 413338 21 zecke 2011-06-01 06:43:30 -0700 Where is the unit/layout test? 414112 22 ademar 2011-06-02 07:45:15 -0700 Revision r87797 cherry-picked into qtwebkit-2.2 with commit 791c2c8 <http://gitorious.org/webkit/qtwebkit/commit/791c2c8> 414128 23 kling 2011-06-02 08:06:56 -0700 (In reply to comment #21) > Where is the unit/layout test? There is none, see comment in ChangeLog: No new tests since this doesn't fail for qrc:// or file:// URLs and our tests can't depend on http:// URLs. 414685 24 zecke 2011-06-03 00:12:58 -0700 (In reply to comment #23) > There is none, see comment in ChangeLog: > No new tests since this doesn't fail for qrc:// or file:// URLs and our tests can't depend on http:// URLs. Well, the underlying question is if you think test cases are optional or not. I really would prefer to not have double standards, accept if a fellow reviewer says it is not testable, but for ordinary contributors ask them to come up with unit tests... it is a bit saddening. 414755 25 benjamin 2011-06-03 03:15:23 -0700 (In reply to comment #24) > > There is none, see comment in ChangeLog: > > No new tests since this doesn't fail for qrc:// or file:// URLs and our tests can't depend on http:// URLs. > > Well, the underlying question is if you think test cases are optional or not. I really would prefer to not have double standards, accept if a fellow reviewer says it is not testable, but for ordinary contributors ask them to come up with unit tests... it is a bit saddening. Andreas and I share an office. He asked me to review that, I asked for test, and we discussed how we could test this. That is just not on the comments of this thread. Given testing this requires building too much test infrastructure, I agreed to push the work around for now while the network team looks at QNAM. It is just an exception for a workaround of a bug in Qt. I don't understand the drama. If I was unfair regarding testing for one of your patch, I appologize. 414758 26 kling 2011-06-03 03:20:26 -0700 (In reply to comment #24) > (In reply to comment #23) > > > There is none, see comment in ChangeLog: > > No new tests since this doesn't fail for qrc:// or file:// URLs and our tests can't depend on http:// URLs. > > Well, the underlying question is if you think test cases are optional or not. I really would prefer to not have double standards, accept if a fellow reviewer says it is not testable, but for ordinary contributors ask them to come up with unit tests... it is a bit saddening. If someone claims a change is untestable or especially nontrivial to test, I won't reject an otherwise correct patch over it. This is currently often the case with drag&drop bugs on Qt, since our DRT has major issues with d&d. If you have a way of testing this particular change, I'm all ears. 414853 27 zecke 2011-06-03 07:01:22 -0700 (In reply to comment #25) ... > Given testing this requires building too much test infrastructure, I agreed to push the work around for now while the network team looks at QNAM. > > It is just an exception for a workaround of a bug in Qt. I don't understand the drama. If I was unfair regarding testing for one of your patch, I appologize. Sorry, this might be a bit lengthy. So first of all I don't have any hard feelings and it is not me feeling treated unfairly in some other bug report or such. It is more a been there, done that moment. From the comments to this bug report I get the feeling (which of course can be wrong) is that you are rushing for a release and from my experience the sad truth is there are no such shortcuts. E.g. when Simon and me were working on the first QtWebKit release and we met in person (Qt DevDays, FOSS.IN, CCC event) we were so happy to avoid hitting the bugtracker, giving each other review in place. It was at a time where we did not have the DumpRenderTree, or much unit tests for QWebView/QWebFrame/QWebPage. There have been many moments were I regret to not have created a bug, not having put enough context into the bug report or not having done a (better) test. The next thing is that theory says one should not write stuff that one can not test (strategic defense initiative as the prime example), of course it is too late her right now. In any case even a not perfect test case helps us to progress... So yes the hint here... don't rush, don't give in to pressure... 414857 28 zecke 2011-06-03 07:12:39 -0700 (In reply to comment #26) > If you have a way of testing this particular change, I'm all ears. Now, my own lazynes strucks... so this was not tired, you might have been there already... a) Test that the unsupportedContent signal is a queued signal. The original bug was introduced by me when I moved away from QueuedConnection to get better performance. So the idea (not for the bugfix but to avoid future regressions) would be to test (by creating a new EventLoop) that some of the API signals are queued, leave a comment pointing to this bug report... so next time a smart-ass like me coming around to play with the way a signal is connected needs to ack the test failure... Maybe you have decided against such a test, it would be nice to know why. b) Create a simple http loading test... add a printf for the signal (when dumping frame load calls) inside the DRT for the unsupported content... now the vague part as I didn't try it yet... maybe add another printf inside FrameLoaderClientQt... and then a queued/non-queued signal would change the order of the printf... c) Create a simple http loading test (platform specific), handle unsupported content by returning a unit value/string, use XML HTTP Request to load this this content... print the magic string coming from DRT for this unsupported content.. 414871 29 benjamin 2011-06-03 07:30:33 -0700 (In reply to comment #28) > a) Test that the unsupportedContent signal is a queued signal. > > The original bug was introduced by me when I moved away from QueuedConnection to get better performance. So the idea (not for the bugfix but to avoid future regressions) would be to test (by creating a new EventLoop) that some of the API signals are queued, leave a comment pointing to this bug report... so next time a smart-ass like me coming around to play with the way a signal is connected needs to ack the test failure... Maybe you have decided against such a test, it would be nice to know why. > > b) Create a simple http loading test... add a printf for the signal (when dumping frame load calls) inside the DRT for the unsupported content... now the vague part as I didn't try it yet... maybe add another printf inside FrameLoaderClientQt... and then a queued/non-queued signal would change the order of the printf... But the thing is the queueing is just an ugly workaround. That is not what we want to test, we want to make sure unsupported content behave as it should. This is not the first time we have this kind of problem. We had some really weird timing issue with QNam over http. I just created https://bugs.webkit.org/show_bug.cgi?id=62012 following this thread. Pierre recently wrote a small HTTP server for testing some stuff, maybe he can pick this up. 427368 30 adawit 2011-06-25 09:10:40 -0700 Unfortunately, this patch causes a regression in kdewebkit because we need the unsupportedContent signal to be delivered as early as possible. This breaks KDE KIO's put-slave-on-hold functionality that allows applications to pass an active network connection to each other. 447201 31 ademar 2011-08-05 07:28:33 -0700 The Queued-signal workaround has been reverted in r92479 (see Bug #63582) because of a regression spotted in KDE's custom QNAM feature. I guess we have no choice but push for the real fix in Qt: http://bugreports.qt.nokia.com/browse/QTBUG-18718 447210 32 adawit 2011-08-05 07:55:21 -0700 (In reply to comment #31) > The Queued-signal workaround has been reverted in r92479 (see Bug #63582) because of a regression spotted in KDE's custom QNAM feature. > > I guess we have no choice but push for the real fix in Qt: http://bugreports.qt.nokia.com/browse/QTBUG-18718 In the meantime, people with this problem can workaround it by connecting to the unsupportedContent(QNetworkReply*) signal using the Qt::QueuedConnection connection type. 452999 33 ademar 2011-08-18 06:41:36 -0700 Since this has to be fixed in Qt (we won't do anything in the QtWebKit side) and there's a workaround available on the user's side, shouldn't this bug be closed here as WONTFIX? 453008 34 ademar 2011-08-18 07:01:01 -0700 (In reply to comment #33) > Since this has to be fixed in Qt (we won't do anything in the QtWebKit side) and there's a workaround available on the user's side, shouldn't this bug be closed here as WONTFIX? Better ask for forgiveness than permission: closing bug as WONTFIX here. I'll keep track of the associated Qt Bug. Bug 62012 is also of interest, it should allow us to test for this kind of problem in the future (there's a reference to this bug there). 74109 2010-11-17 07:06:32 -0800 2010-11-17 07:06:32 -0800 3 src files containing a little usecase for the bug bug_unsupportedContent.zip application/zip 1962 frank.fischer UEsDBBQAAAAIABCAcT37+ZOIkQEAAEIDAAAIAAAAbWFpbi5jcHB1UstOwzAQvFfqP1ggIadqSLhw 4FGp9ICQeFW8Dggh11klVlM7tTcNAvHvbF6laSGnzc7s7HjsfaVlmkfAzqZ4matgOs6yVEmByuhR v7cD3wilX5SOTPEX+oACc3chLIFdeGIsBNMnm24hBczmChEcBlSuFBTvSzxMKpbSyBa0j5eFsLEc MpkIywZUr17fvH7vq99j9G2aHjCRZeycaSg6fV4LlKPeaTVWEv2RNFqDRE4/Q/ZwdXk7vuapcFgf cpIaBxH3PJqsCNd3j3yZK6RWK7ORyaDy227/7fPOSgc4lqhW0IDlTEt4gdmzAhJq0qi1mnaXWtYk 1kbOPX8kouge7EJo0HSAKAbkjY4/op97a2ILrmZvyrQxrOnrKNbyNzQnYuBEdMjopq3S8QEFs+uj icklpvhnqrO8CmRCjq1Iu6Zb1voMqRERL18R30sQs5MgoMeizVyJQ2kWAYWpS4qjti8tCDTWdya3 EvxMyDk52dtaTXGoT+BHYRgO2XEYbhlLNu7OAuZW11cIHyAr4Pv0B1BLAwQUAAAACABPf3E996O9 G6wDAAAVCwAADgAAAHdlYnZpZXdfcXQuY3BwvVVbb9MwFH5H4j+YIpALoxkSAilsk0o3YFA2Qrk8 Tm5y2lpz7cw+aRkIfjvHuTRZ09KJB/LQOj6X7zs+33HuSx2rLAF2sITxpUQEhwEtFxKWF1fYmx3d vXP3Tu0V4cBYCKKTBWgcGpO27GeAS2Mvg6hcfIJUXbe83mQyiI7BXaJJR2AXMgZ3tMHltVRwLIUy 07UU0ji0IOb5NqPnG4y/EukwLBc8+iaTKeAjlgpLZLssZFFlK7eKyJ/0Vz4XqTVTC86xQ6ZhyaKP 5fsrYXn3Ze3oAFHqqePdJ0e07iNaOc4QuIcYlcYwfCcWwsVWpniixVhBssfQZvAPmfoZmqERyelc TMH9c5qPKptK7Vps6kQp5S+TvDZ2KWzyRbssTY1FSAZGIx0cX0ePjdYQIy+C99jo9M1Zf8izduQN WTzqki/OpKOI4flnPhM6UfBld5THbqP7TCtsRYdVdY9LjQS1am+FRzV+FSqDwl4V9Kslqd+VbirF rDkujExq71tWwaz/a2mw2M7P/6NXaVFWUfB9OWH7QcCizxdfTz6NTs/P2NFh4+1i8PZk8J4/22Mv 9th+lwWBh4OEjWFCY8uWEmcmw3v01Hg1q6uMpp/wi//Dikm50dR/ZRJjYzcaElCAMBQItm2m1JXK dIHdj2Pqygehadv6fRpcXuL68PugEznZMKeenYOcQttYiXgukHceLNj4mq43FrAH82LZ2SThnOFK RYlZ6htKuiKpPKcDLv436vf47zHr6o1GaGk4mdFKapjQhafFHOrjz6zi3R6awo2WLlWSCgo63Z4S eV/ayRppGndoGNK5jsQC/NYZmcuRQcs7VaXM2zpU1/r1HIYOjaUGDU0sUBrN2x7lRuXRZY8rRp4v va5V2aRer+qvCwNFvznL3b2aSC3dDBLuu/Iwjyz7cpVJpN1mitzcg+8Q8y0kXpFE+taKa7a0kqZY oGjOhEj6St2IlRO+8uw5+YMEzg4OaQ4Ll9WY14/DJAxjmkh2cMA6lW5oXnMwQRML8xSvex2yF85A AmtA/moW5GAbUKGBXBS8dfQ1+3ve1jMpUGtPz4/BN5W+p76mc01XVVnIGsb2ggYmUwnTBpnPmcMz NMVxbq6pVVdd205sKiDnn6evO7Fi3Y6+Lfs8V94TT59A/sq+ruDmUwTGyjgg2TQN7drrZf2SSPef 76gdF2r6oLPd64P4LufZnD/d3+++vMXncgshmrcY5AKSihl1AIWqvpq70HPnLSRXH/8KYsXzD1BL AwQUAAAACAAEf3E9E/W+iy8BAAB7AgAADAAAAHdlYnZpZXdfcXQuaH1S30vDMBB+F/wfDvbSDaEv 4sMmPmwOf4Fa0fWxdM1tBrOkJtcWGfNv97q2rq2yC+TId1++fJdkIFda4AqicD5d3M3D6DaKTk8G DEmNPZRxqROVCYTLgEJcPkjyA84LicVVv36TST94tmZt0blpbHuEHBMyJVgO4KjmRMXOQa0JY0iz pZIJNKdUpC2nOoLoaXo/n71O9jJV1JvGDByi0fSCUIo10gjS2KKm4aRL+254ZaFbanczAtZorb3h 1iJlVkOU1uhk1xZglLhlFOCUIdczlxsp4D3WQuGbdlmaGsvUmdHEFr3gEakw9uMFU/U1AlumX99/ Fa5NoZWJRWPP+5SaLs55X4IyR3EGNUCGYsVC/9kcg+9vcLNE647dwqHbLqta7RjdPztqIVes2P5Q P1BLAQIUABQAAAAIABCAcT37+ZOIkQEAAEIDAAAIAAAAAAAAAAAAIAAAAAAAAABtYWluLmNwcFBL AQIUABQAAAAIAE9/cT33o70brAMAABULAAAOAAAAAAAAAAAAIAAAALcBAAB3ZWJ2aWV3X3F0LmNw cFBLAQIUABQAAAAIAAR/cT0T9b6LLwEAAHsCAAAMAAAAAAAAAAAAIAAAAI8FAAB3ZWJ2aWV3X3F0 LmhQSwUGAAAAAAMAAwCsAAAA6AYAAAAA 86264 2011-03-19 08:59:32 -0700 2011-05-31 13:55:51 -0700 Proposed patch bug-49650.diff text/plain 2909 kling ZGlmZiAtLWdpdCBhL1NvdXJjZS9XZWJLaXQvcXQvQ2hhbmdlTG9nIGIvU291cmNlL1dlYktpdC9x dC9DaGFuZ2VMb2cKaW5kZXggZThhMjNkZi4uMTNkOWJmOSAxMDA2NDQKLS0tIGEvU291cmNlL1dl YktpdC9xdC9DaGFuZ2VMb2cKKysrIGIvU291cmNlL1dlYktpdC9xdC9DaGFuZ2VMb2cKQEAgLTEs MyArMSwyMCBAQAorMjAxMS0wMy0xOSAgQW5kcmVhcyBLbGluZyAgPGtsaW5nQHdlYmtpdC5vcmc+ CisKKyAgICAgICAgUmV2aWV3ZWQgYnkgTk9CT0RZIChPT1BTISkuCisKKyAgICAgICAgUkVHUkVT U0lPTjogW1F0XSBRTmV0d29ya1JlcGx5IGRlbGl2ZXJlZCBieSB0aGUgdW5zdXBwb3J0ZWRDb250 ZW50KCkgc2lnbmFsIGRvZXMgbm90IGNvbnRhaW4gZG93bmxvYWRlZCBkYXRhCisgICAgICAgIGh0 dHBzOi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD00OTY1MAorCisgICAgICAgIERl ZmVyIGVtaXNzaW9uIG9mIFFXZWJQYWdlOjp1bnN1cHBvcnRlZENvbnRlbnQoKSB1bnRpbCB3ZSdy ZSBiYWNrIGluIHRoZSBldmVudCBsb29wLgorICAgICAgICBUaGlzIGxldHMgdGhlIFFOQU0gYmFj a2VuZCBmaW5pc2ggd2l0aCB0aGUgcmVwbHkgd2l0aG91dCBoYW5kaW5nIG92ZXIgb3duZXJzaGlw IHRvIHRoZSB1c2VyIGNvZGUuCisKKyAgICAgICAgTm8gbmV3IHRlc3RzIHNpbmNlIHRoaXMgZG9l c24ndCBmYWlsIGZvciBxcmM6Ly8gb3IgZmlsZTovLyBVUkxzIGFuZCBvdXIgdGVzdHMgY2FuJ3Qg ZGVwZW5kIG9uIGh0dHA6Ly8gVVJMcy4KKworICAgICAgICAqIFdlYkNvcmVTdXBwb3J0L0ZyYW1l TG9hZGVyQ2xpZW50UXQuY3BwOgorICAgICAgICAoV2ViQ29yZTo6RnJhbWVMb2FkZXJDbGllbnRR dDo6c2V0RnJhbWUpOgorICAgICAgICAoV2ViQ29yZTo6RnJhbWVMb2FkZXJDbGllbnRRdDo6ZG93 bmxvYWQpOgorICAgICAgICAqIFdlYkNvcmVTdXBwb3J0L0ZyYW1lTG9hZGVyQ2xpZW50UXQuaDoK KwogMjAxMS0wMy0xNyAgQnJhZHkgRWlkc29uICA8YmVpZHNvbkBhcHBsZS5jb20+CiAKICAgICAg ICAgUmV2aWV3ZWQgYnkgU2FtIFdlaW5pZy4KZGlmZiAtLWdpdCBhL1NvdXJjZS9XZWJLaXQvcXQv V2ViQ29yZVN1cHBvcnQvRnJhbWVMb2FkZXJDbGllbnRRdC5jcHAgYi9Tb3VyY2UvV2ViS2l0L3F0 L1dlYkNvcmVTdXBwb3J0L0ZyYW1lTG9hZGVyQ2xpZW50UXQuY3BwCmluZGV4IDI3ZWQ3ZWQuLmIy ODYwYWEgMTAwNjQ0Ci0tLSBhL1NvdXJjZS9XZWJLaXQvcXQvV2ViQ29yZVN1cHBvcnQvRnJhbWVM b2FkZXJDbGllbnRRdC5jcHAKKysrIGIvU291cmNlL1dlYktpdC9xdC9XZWJDb3JlU3VwcG9ydC9G cmFtZUxvYWRlckNsaWVudFF0LmNwcApAQCAtMjM0LDYgKzIzNCw4IEBAIHZvaWQgRnJhbWVMb2Fk ZXJDbGllbnRRdDo6c2V0RnJhbWUoUVdlYkZyYW1lKiB3ZWJGcmFtZSwgRnJhbWUqIGZyYW1lKQog ICAgICAgICAgICAgbV93ZWJGcmFtZS0+cGFnZSgpLCBTSUdOQUwobG9hZFByb2dyZXNzKGludCkp KTsKICAgICBjb25uZWN0KHRoaXMsIFNJR05BTChsb2FkRmluaXNoZWQoYm9vbCkpLAogICAgICAg ICAgICAgbV93ZWJGcmFtZS0+cGFnZSgpLCBTSUdOQUwobG9hZEZpbmlzaGVkKGJvb2wpKSk7Cisg ICAgY29ubmVjdCh0aGlzLCBTSUdOQUwodW5zdXBwb3J0ZWRDb250ZW50KFFOZXR3b3JrUmVwbHkq KSksCisgICAgICAgICAgICBtX3dlYkZyYW1lLT5wYWdlKCksIFNJR05BTCh1bnN1cHBvcnRlZENv bnRlbnQoUU5ldHdvcmtSZXBseSopKSwgUXQ6OlF1ZXVlZENvbm5lY3Rpb24pOwogICAgIGNvbm5l Y3QodGhpcywgU0lHTkFMKGxvYWRGaW5pc2hlZChib29sKSksCiAgICAgICAgICAgICBtX3dlYkZy YW1lLCBTSUdOQUwobG9hZEZpbmlzaGVkKGJvb2wpKSk7CiAgICAgY29ubmVjdCh0aGlzLCBTSUdO QUwodGl0bGVDaGFuZ2VkKFFTdHJpbmcpKSwKQEAgLTEwMDAsNyArMTAwMiw3IEBAIHZvaWQgRnJh bWVMb2FkZXJDbGllbnRRdDo6ZG93bmxvYWQoV2ViQ29yZTo6UmVzb3VyY2VIYW5kbGUqIGhhbmRs ZSwgY29uc3QgV2ViQ29yCiAgICAgaWYgKHJlcGx5KSB7CiAgICAgICAgIFFXZWJQYWdlICpwYWdl ID0gbV93ZWJGcmFtZS0+cGFnZSgpOwogICAgICAgICBpZiAocGFnZS0+Zm9yd2FyZFVuc3VwcG9y dGVkQ29udGVudCgpKQotICAgICAgICAgICAgZW1pdCBwYWdlLT51bnN1cHBvcnRlZENvbnRlbnQo cmVwbHkpOworICAgICAgICAgICAgZW1pdCB1bnN1cHBvcnRlZENvbnRlbnQocmVwbHkpOwogICAg ICAgICBlbHNlCiAgICAgICAgICAgICByZXBseS0+YWJvcnQoKTsKICAgICB9CmRpZmYgLS1naXQg YS9Tb3VyY2UvV2ViS2l0L3F0L1dlYkNvcmVTdXBwb3J0L0ZyYW1lTG9hZGVyQ2xpZW50UXQuaCBi L1NvdXJjZS9XZWJLaXQvcXQvV2ViQ29yZVN1cHBvcnQvRnJhbWVMb2FkZXJDbGllbnRRdC5oCmlu ZGV4IDAzMzM1OTkuLmQ4ZjU2MjUgMTAwNjQ0Ci0tLSBhL1NvdXJjZS9XZWJLaXQvcXQvV2ViQ29y ZVN1cHBvcnQvRnJhbWVMb2FkZXJDbGllbnRRdC5oCisrKyBiL1NvdXJjZS9XZWJLaXQvcXQvV2Vi Q29yZVN1cHBvcnQvRnJhbWVMb2FkZXJDbGllbnRRdC5oCkBAIC00Myw2ICs0Myw4IEBACiAjaW5j bHVkZSA8UVVybD4KICNpbmNsdWRlIDxxb2JqZWN0Lmg+CiAjaW5jbHVkZSA8d3RmL0ZvcndhcmQu aD4KKworY2xhc3MgUU5ldHdvcmtSZXBseTsKIGNsYXNzIFFXZWJGcmFtZTsKIAogbmFtZXNwYWNl IFdlYkNvcmUgewpAQCAtNjgsNiArNzAsNyBAQCBzaWduYWxzOgogICAgIHZvaWQgbG9hZFByb2dy ZXNzKGludCBkKTsKICAgICB2b2lkIGxvYWRGaW5pc2hlZChib29sKTsKICAgICB2b2lkIHRpdGxl Q2hhbmdlZChjb25zdCBRU3RyaW5nJiB0aXRsZSk7CisgICAgdm9pZCB1bnN1cHBvcnRlZENvbnRl bnQoUU5ldHdvcmtSZXBseSopOwogCiBwdWJsaWM6CiAgICAgRnJhbWVMb2FkZXJDbGllbnRRdCgp Owo=