36424 2019-03-26 15:40:22 +0300 i586 FTBFS: 2.3.2-alt1 не пересобирается посредством gcc8 по-умолчанию 2019-04-10 14:47:12 +0300 1 1 4 Development Sisyphus libslang2 unstable all Linux CLOSED FIXED P3 normal --- 1 asy asy aen asy darktemplaralt iv ldv rider vsu qa-sisyphus oldest_to_newest 180019 0 asy 2019-03-26 15:40:22 +0300 С момента появления gcc8 в Сизифе не проходит тестовая пересборка: возникает ошибка в двух тестах: "2 tests failed: array.sl array.slc". Пересобирается, если для i586 указать сборку посредством gcc7, либо собирать посредством gcc8 с параметром -O0: https://lists.altlinux.org/pipermail/devel/2019-March/207351.html 180020 1 ldv 2019-03-26 15:55:09 +0300 Надо исправить пакет slang2. 180021 2 ldv 2019-03-26 15:56:13 +0300 Только у пакета slang2 нет мантейнера. 180046 3 asy 2019-03-26 20:31:16 +0300 (In reply to comment #2) > Только у пакета slang2 нет мантейнера. Это не хорошо... А на сколько плохи варианты с gcc7, либо с -O0 для i586 на время отсутствия мантейнера? 180048 4 ldv 2019-03-26 21:25:30 +0300 (In reply to comment #3) > (In reply to comment #2) > > > Только у пакета slang2 нет мантейнера. > > Это не хорошо... А на сколько плохи варианты с gcc7, либо с -O0 для i586 на > время отсутствия мантейнера? Очень плохи. 180573 5 asy 2019-04-08 08:56:35 +0300 (In reply to comment #1) > Надо исправить пакет slang2. Вот тут http://lists.jedsoft.org/lists/slang-users/2019/0000001.html есть патч, с ним тесты проходят (на i586, остальное не смотрел пока). Но автор предполагает, что проблема всё же в оптимизаторе GCC. 180582 6 repository-robot 2019-04-08 11:31:15 +0300 slang2-2.3.2-alt2 -> sisyphus: Mon Apr 08 2019 Sergey Y. Afonin <asy@altlinux.ru> 2.3.2-alt2 - fixed gcc8 optimization on i586 (ALT #36424) 180583 7 aen 2019-04-08 11:35:02 +0300 Спасибо! 180600 8 ldv 2019-04-08 14:20:05 +0300 (In reply to comment #5) > (In reply to comment #1) > > > Надо исправить пакет slang2. > > Вот тут http://lists.jedsoft.org/lists/slang-users/2019/0000001.html есть патч, > с ним тесты проходят (на i586, остальное не смотрел пока). Но автор > предполагает, что проблема всё же в оптимизаторе GCC. Автор не умеет азы знаковой целочисленной арифметики: просто не в курсе, что результат знакового целочисленного переполнения не определён. Прискорбно. 180601 9 darktemplaralt 2019-04-08 14:26:31 +0300 (В ответ на комментарий №8) > (In reply to comment #5) > > (In reply to comment #1) > > > > > Надо исправить пакет slang2. > > > > Вот тут http://lists.jedsoft.org/lists/slang-users/2019/0000001.html есть патч, > > с ним тесты проходят (на i586, остальное не смотрел пока). Но автор > > предполагает, что проблема всё же в оптимизаторе GCC. > > Автор не умеет азы знаковой целочисленной арифметики: просто не в курсе, что > результат знакового целочисленного переполнения не определён. Прискорбно. Не менее прискорбно и состояние кодогенерации в gcc-8, которое часто (заметно чаще, чем прошлые версии) уравнивает "неопределённое поведение" с генерацией мусора. 180603 10 ldv 2019-04-08 14:36:01 +0300 (In reply to comment #9) > (В ответ на комментарий №8) > > (In reply to comment #5) > > > (In reply to comment #1) > > > > > > > Надо исправить пакет slang2. > > > > > > Вот тут http://lists.jedsoft.org/lists/slang-users/2019/0000001.html есть патч, > > > с ним тесты проходят (на i586, остальное не смотрел пока). Но автор > > > предполагает, что проблема всё же в оптимизаторе GCC. > > > > Автор не умеет азы знаковой целочисленной арифметики: просто не в курсе, что > > результат знакового целочисленного переполнения не определён. Прискорбно. > > Не менее прискорбно и состояние кодогенерации в gcc-8, которое часто (заметно > чаще, чем прошлые версии) уравнивает "неопределённое поведение" с генерацией > мусора. Это публичная позиция проекта gcc. В каждой новой версии gcc появляются новые оптимизации, часть из них полагается на отсутствие UB. Не хотите мусора - либо убирайте UB, либо выключайте оптимизацию. 180616 11 asy 2019-04-08 16:26:14 +0300 (In reply to comment #8) > Автор не умеет азы знаковой целочисленной арифметики: просто не в курсе, что > результат знакового целочисленного переполнения не определён. Прискорбно. А может быть автор в курсе, что в этом месте не может быть переполнения ввиду наличия каких-то иных условий в других частях кода? Оптимизация, как я понимаю, в new_num_elements/dims[i] упёрлась? 180617 12 ldv 2019-04-08 16:31:26 +0300 (In reply to comment #11) > (In reply to comment #8) > > > Автор не умеет азы знаковой целочисленной арифметики: просто не в курсе, что > > результат знакового целочисленного переполнения не определён. Прискорбно. > > А может быть автор в курсе, что в этом месте не может быть переполнения Нет, он же проверяет результат переполнения. А результат этот не определён. Вы видели патч, который приложили? Там изменена проверка того самого результата переполнения, который не определён. 180620 13 asy 2019-04-08 16:58:10 +0300 (In reply to comment #12) > Нет, он же проверяет результат переполнения. А результат этот не определён. > Вы видели патч, который приложили? Там изменена проверка того самого > результата переполнения, который не определён. Видел. Добавлением проверки new_num_elements на отрицательное значение, которого в принципе может и не ожидаться никогда, но это надо уже код смотреть подробно, а то вдруг я напрасно предполагаю. Хотя там есть SLuindex_Type и не очень тогда понятно, почему автор им не воспользовался, если отрицательное значение не ожидается. Такой вот патч тоже помогает, как минимум в сборке: --- a/slang/src/slarray.c +++ b/slang/src/slarray.c @@ -366,7 +366,7 @@ SLang_create_array1 (SLtype type, int read_only, VOID_STAR data, num_elements = 1; for (i = 0; i < num_dims; i++) { - SLindex_Type new_num_elements; + SLuindex_Type new_num_elements; at->dims[i] = dims[i]; new_num_elements = dims[i] * num_elements; if (dims[i] && (new_num_elements/dims[i] != num_elements)) Или gcc8 как-то проверяет, что new_num_elements действительно может уйти в отрицательное значение, а не просто предполагат на основе фрагмента кода? 180622 14 iv 2019-04-08 17:27:38 +0300 (In reply to comment #13) > Или gcc8 как-то проверяет, что new_num_elements действительно может уйти в > отрицательное значение, а не просто предполагат на основе фрагмента кода? Не очень важно, что делает gcc; просто не нужно использовать результат, значение которого не определено. Правильно было бы как-то так, наверное: - if (dims[i] && (new_num_elements/dims[i] != num_elements)) + if (dims[i] && (INT_MAX/dims[i] < num_elements)) если бы мы могли сказать, что SLindex_Type всегда int. Там, кстати, ниже, около строки 400, ещё одна похожая проверка: http://git.altlinux.org/gears/s/slang2.git?p=slang2.git;a=blob;f=slang/src/slarray.c;h=d26aaece9c67711a96904e3bcf73f5b53b7bcc6c;hb=sisyphus#l399 Подозреваю, что там такого ещё много. 180632 15 ldv 2019-04-08 18:06:38 +0300 Зачем там вообще знаковая арифметика? Неужели num_elements может легально принимать отрицательные значения? Почему вообще num_elements знаковый? 180634 16 vsu 2019-04-08 19:33:02 +0300 (В ответ на комментарий №14) > - if (dims[i] && (new_num_elements/dims[i] != num_elements)) > + if (dims[i] && (INT_MAX/dims[i] < num_elements)) Есть вероятность, что даже такая проверка уже не поможет после того, как код с undefined behavior уже выполнен (при вычислении new_num_elements произошло переполнение). > Подозреваю, что там такого ещё много. Да, и не только в этом файле. Если подходить к данному вопросу формально, то даже арифметические операции в slarith.inc, выполняемые при интерпретации кода на SLang, нужно как-то защищать от переполнения (хотя с этим кодом оптимизатор вряд ли способен сделать что-то неожиданное). Либо нужно собирать весь этот код с -fwrapv (или вообще -fno-strict-overflow — кто знает, что они там делают с указателями), поскольку имеющиеся там проверки на переполнение рассчитаны именно на такое поведение компилятора. 180635 17 ldv 2019-04-08 19:41:20 +0300 (In reply to comment #16) > (В ответ на комментарий №14) > Либо нужно собирать весь этот код с -fwrapv (или вообще -fno-strict-overflow — > кто знает, что они там делают с указателями), поскольку имеющиеся там проверки > на переполнение рассчитаны именно на такое поведение компилятора. Я бы рекомендовал -fno-strict-overflow для всех таких пакетов. 180638 18 asy 2019-04-08 20:40:53 +0300 (In reply to comment #16) > Есть вероятность, что даже такая проверка уже не поможет после того, как код с > undefined behavior уже выполнен (при вычислении new_num_elements произошло > переполнение). Кстати да, действительно. Что-то я на if зациклился. А почему тогда у компилятора оптимизатор срабатывать начинает при добавлении ещё одной проверки с вероятно неопределённым значением? Или это просто "так получилось"? 180640 19 asy 2019-04-08 21:07:58 +0300 (In reply to comment #17) > Я бы рекомендовал -fno-strict-overflow для всех таких пакетов. То есть, это делает поведение предсказуемым в плане однозначного получения отрицательного значения при переполнении? 180648 20 8091 asy 2019-04-09 08:36:41 +0300 Created attachment 8091 slarray-ub.patch Автор согласен с ситуацией в плане ub и предлагает такой вариант. 180649 21 iv 2019-04-09 08:44:27 +0300 (In reply to comment #20) > Created an attachment (id=8091) [details] > slarray-ub.patch > > Автор согласен с ситуацией в плане ub и предлагает такой вариант. Из check_overflow_mult_ui я не понял условия > (a/(SLuindex_Type)b) > UINT_MAX) 180650 22 asy 2019-04-09 09:00:55 +0300 (In reply to comment #21) > Из check_overflow_mult_ui я не понял условия > > > (a/(SLuindex_Type)b) > UINT_MAX) В том плане, каким образом результат может превысить UINT_MAX, если a имеет тип UINT? 180664 23 asy 2019-04-09 14:09:05 +0300 (In reply to comment #21) > Из check_overflow_mult_ui я не понял условия > > > (a/(SLuindex_Type)b) > UINT_MAX) Видимо должно быть так: (a > UINT_MAX/(SLuindex_Type)b) 180665 24 asy 2019-04-09 14:17:09 +0300 (In reply to comment #8) > Автор не умеет азы знаковой целочисленной арифметики: просто не в курсе, что > результат знакового целочисленного переполнения не определён. Прискорбно. Кстати, если посмотреть краткое резюме на сайте, он астрофизик и работает по специальности. И, наверное, имеет какое-то право не уследить за изменениями в C/C++. Надо просто подсказать иногда. 180691 25 8094 asy 2019-04-09 21:52:37 +0300 Created attachment 8094 slarray-ub.patch Патч со скорректированным if (см. Comment #23) 180719 26 asy 2019-04-10 14:47:12 +0300 Дубль два: * Tue Apr 09 2019 Sergey Y. Afonin <asy@altlinux> 2.3.2-alt3 - added slang-2.3.2-slarray-ub.patch (fixed UB in slarray, ALT #36424#c25) - added -fno-strict-overflow to %optflags (ALT #36424#c17) И забыл про %% у optflags - развернулся в changelog. Надо будет добавить в следующий раз. 8091 2019-04-09 08:36:41 +0300 2019-04-09 21:52:37 +0300 slarray-ub.patch slang-2.3.2-slarray-ub.patch text/plain 2819 asy ZGlmZiAtLWdpdCBhL3NyYy9zbGFycmF5LmMgYi9zcmMvc2xhcnJheS5jCmluZGV4IGQyNmFhZWMu LjZjMzM4YjUgMTAwNjQ0Ci0tLSBhL3NyYy9zbGFycmF5LmMKKysrIGIvc3JjL3NsYXJyYXkuYwpA QCAtMjIsNiArMjIsNyBAQCBVU0EuCiAKICNpbmNsdWRlICJzbGluY2x1ZC5oIgogI2luY2x1ZGUg PG1hdGguaD4KKyNpbmNsdWRlIDxsaW1pdHMuaD4KIAogLyogI2RlZmluZSBTTF9BUFBfV0FOVFNf Rk9SRUFDSCAqLwogI2luY2x1ZGUgInNsYW5nLmgiCkBAIC0zMTIsNiArMzEzLDI2IEBAIHZvaWQg U0xhbmdfZnJlZV9hcnJheSAoU0xhbmdfQXJyYXlfVHlwZSAqYXQpCiAgICBmcmVlX2FycmF5IChh dCk7CiB9CiAKKy8qIEhlcmUsIGEgYW5kIGIgYXJlIGFzc3VtZWQgdG8gYmUgbm9uLW5lZ2F0aXZl ICovCitzdGF0aWMgaW50IGNoZWNrX292ZXJmbG93X211bHRfaSAoU0xpbmRleF9UeXBlIGEsIFNM aW5kZXhfVHlwZSBiLCBTTGluZGV4X1R5cGUgKmNwKQoreworICAgaWYgKChhIDwgMCkgfHwgKGIg PCAwKSB8fCAoKGIgPiAwKSAmJiAoYSA+IElOVF9NQVgvYikpKQorICAgICByZXR1cm4gLTE7CisK KyAgICpjcCA9IGEqYjsKKworICAgcmV0dXJuIDA7Cit9CisKK3N0YXRpYyBpbnQgY2hlY2tfb3Zl cmZsb3dfbXVsdF91aSAoU0x1aW5kZXhfVHlwZSBhLCBTTGluZGV4X1R5cGUgYiwgU0x1aW5kZXhf VHlwZSAqY3ApCit7CisgICBpZiAoKGIgPCAwKSB8fCAoKGIgPiAwKSAmJiAoYS8oU0x1aW5kZXhf VHlwZSliKSA+IFVJTlRfTUFYKSkKKyAgICAgcmV0dXJuIC0xOworCisgICAqY3AgPSBhKihTTHVp bmRleF9UeXBlKWI7CisgICByZXR1cm4gMDsKK30KKwogU0xhbmdfQXJyYXlfVHlwZSAqCiBTTGFu Z19jcmVhdGVfYXJyYXkxIChTTHR5cGUgdHlwZSwgaW50IHJlYWRfb25seSwgVk9JRF9TVEFSIGRh dGEsCiAJCSAgICAgU0xpbmRleF9UeXBlICpkaW1zLCB1bnNpZ25lZCBpbnQgbnVtX2RpbXMsIGlu dCBub19pbml0KQpAQCAtMzY2LDE2ICszODcsMTQgQEAgU0xhbmdfY3JlYXRlX2FycmF5MSAoU0x0 eXBlIHR5cGUsIGludCByZWFkX29ubHksIFZPSURfU1RBUiBkYXRhLAogICAgbnVtX2VsZW1lbnRz ID0gMTsKICAgIGZvciAoaSA9IDA7IGkgPCBudW1fZGltczsgaSsrKQogICAgICB7Ci0JU0xpbmRl eF9UeXBlIG5ld19udW1fZWxlbWVudHM7CiAJYXQtPmRpbXNbaV0gPSBkaW1zW2ldOwotCW5ld19u dW1fZWxlbWVudHMgPSBkaW1zW2ldICogbnVtX2VsZW1lbnRzOwotCWlmIChkaW1zW2ldICYmIChu ZXdfbnVtX2VsZW1lbnRzL2RpbXNbaV0gIT0gbnVtX2VsZW1lbnRzKSkKKworCWlmICgtMSA9PSBj aGVja19vdmVyZmxvd19tdWx0X2kgKG51bV9lbGVtZW50cywgZGltc1tpXSwgJm51bV9lbGVtZW50 cykpCiAJICB7CiAJICAgICB0aHJvd19zaXplX2Vycm9yIChTTF9JbmRleF9FcnJvcik7CiAJICAg ICBmcmVlX2FycmF5IChhdCk7CiAJICAgICByZXR1cm4gTlVMTDsKIAkgIH0KLQludW1fZWxlbWVu dHMgPSBuZXdfbnVtX2VsZW1lbnRzOwogICAgICB9CiAKICAgIC8qIE5vdyBzZXQgdGhlIHJlc3Qg b2YgdGhlIHVudXNlZCBkaW1lbnNpb25zIHRvIDEuICBUaGlzIG1ha2VzIGl0IGVhc2llcgpAQCAt Mzk1LDggKzQxNCwxMCBAQCBTTGFuZ19jcmVhdGVfYXJyYXkxIChTTHR5cGUgdHlwZSwgaW50IHJl YWRfb25seSwgVk9JRF9TVEFSIGRhdGEsCiAJcmV0dXJuIGF0OwogICAgICB9CiAKLSAgIHNpemUg PSAobnVtX2VsZW1lbnRzICogc2l6ZW9mX3R5cGUpOwotICAgaWYgKChzaXplL3NpemVvZl90eXBl ICE9IG51bV9lbGVtZW50cykgfHwgKHNpemUgPCAwKSkKKyAgIC8qIFNMbWFsbG9jIGlzIGN1cnJl bnRseSBsaW1pdGVkIHRvIHRoZSB1c2Ugb2YgdW5zaWduZWQgaW50ZWdlcnMuCisgICAgKiBTbyBp bmNsdWRlIHRoZSBzaXplIG9mIHRoZSB0eXBlIGFzIHdlbGwuCisgICAgKi8KKyAgIGlmICgtMSA9 PSBjaGVja19vdmVyZmxvd19tdWx0X2kgKG51bV9lbGVtZW50cywgc2l6ZW9mX3R5cGUsICZzaXpl KSkKICAgICAgewogCXRocm93X3NpemVfZXJyb3IgKFNMX0lOVkFMSURfUEFSTSk7CiAJZnJlZV9h cnJheSAoYXQpOwpAQCAtMTEwMyw3ICsxMTI0LDYgQEAgY29udmVydF9uYXN0eV9pbmRleF9vYmpz IChTTGFuZ19BcnJheV9UeXBlICphdCwKICAgIHRvdGFsX251bV9lbGVtZW50cyA9IDE7CiAgICBm b3IgKGkgPSAwOyBpIDwgbnVtX2luZGljZXM7IGkrKykKICAgICAgewotCVNMdWluZGV4X1R5cGUg bmV3X3RvdGFsX251bV9lbGVtZW50czsKIAlTTGFuZ19PYmplY3RfVHlwZSAqb2JqID0gaW5kZXhf b2JqcyArIGk7CiAJcmFuZ2VfZGVsdGFfYnVmIFtpXSA9IDA7CiAKQEAgLTExNDUsMTMgKzExNjUs MTEgQEAgY29udmVydF9uYXN0eV9pbmRleF9vYmpzIChTTGFuZ19BcnJheV9UeXBlICphdCwKIAkg ICAgICAgfQogCSAgfQogCi0JbmV3X3RvdGFsX251bV9lbGVtZW50cyA9IHRvdGFsX251bV9lbGVt ZW50cyAqIG1heF9kaW1zW2ldOwotCWlmIChtYXhfZGltc1tpXSAmJiAobmV3X3RvdGFsX251bV9l bGVtZW50cy9tYXhfZGltc1tpXSAhPSB0b3RhbF9udW1fZWxlbWVudHMpKQorCWlmICgtMSA9PSBj aGVja19vdmVyZmxvd19tdWx0X3VpICh0b3RhbF9udW1fZWxlbWVudHMsIG1heF9kaW1zW2ldLCAm dG90YWxfbnVtX2VsZW1lbnRzKSkKIAkgIHsKIAkgICAgIHRocm93X3NpemVfZXJyb3IgKFNMX0lO VkFMSURfUEFSTSk7CiAJICAgICByZXR1cm4gLTE7CiAJICB9Ci0gICAgICAgdG90YWxfbnVtX2Vs ZW1lbnRzID0gbmV3X3RvdGFsX251bV9lbGVtZW50czsKICAgICAgfQogCiAgICAqbnVtX2VsZW1l bnRzID0gdG90YWxfbnVtX2VsZW1lbnRzOwo= 8094 2019-04-09 21:52:37 +0300 2019-04-09 21:52:37 +0300 slarray-ub.patch slang-2.3.2-slarray-ub.patch text/plain 2819 asy ZGlmZiAtLWdpdCBhL3NyYy9zbGFycmF5LmMgYi9zcmMvc2xhcnJheS5jCmluZGV4IGQyNmFhZWMu LjZjMzM4YjUgMTAwNjQ0Ci0tLSBhL3NyYy9zbGFycmF5LmMKKysrIGIvc3JjL3NsYXJyYXkuYwpA QCAtMjIsNiArMjIsNyBAQCBVU0EuCiAKICNpbmNsdWRlICJzbGluY2x1ZC5oIgogI2luY2x1ZGUg PG1hdGguaD4KKyNpbmNsdWRlIDxsaW1pdHMuaD4KIAogLyogI2RlZmluZSBTTF9BUFBfV0FOVFNf Rk9SRUFDSCAqLwogI2luY2x1ZGUgInNsYW5nLmgiCkBAIC0zMTIsNiArMzEzLDI2IEBAIHZvaWQg U0xhbmdfZnJlZV9hcnJheSAoU0xhbmdfQXJyYXlfVHlwZSAqYXQpCiAgICBmcmVlX2FycmF5IChh dCk7CiB9CiAKKy8qIEhlcmUsIGEgYW5kIGIgYXJlIGFzc3VtZWQgdG8gYmUgbm9uLW5lZ2F0aXZl ICovCitzdGF0aWMgaW50IGNoZWNrX292ZXJmbG93X211bHRfaSAoU0xpbmRleF9UeXBlIGEsIFNM aW5kZXhfVHlwZSBiLCBTTGluZGV4X1R5cGUgKmNwKQoreworICAgaWYgKChhIDwgMCkgfHwgKGIg PCAwKSB8fCAoKGIgPiAwKSAmJiAoYSA+IElOVF9NQVgvYikpKQorICAgICByZXR1cm4gLTE7CisK KyAgICpjcCA9IGEqYjsKKworICAgcmV0dXJuIDA7Cit9CisKK3N0YXRpYyBpbnQgY2hlY2tfb3Zl cmZsb3dfbXVsdF91aSAoU0x1aW5kZXhfVHlwZSBhLCBTTGluZGV4X1R5cGUgYiwgU0x1aW5kZXhf VHlwZSAqY3ApCit7CisgICBpZiAoKGIgPCAwKSB8fCAoKGIgPiAwKSAmJiAoYSA+IFVJTlRfTUFY LyhTTHVpbmRleF9UeXBlKWIpKSkKKyAgICAgcmV0dXJuIC0xOworCisgICAqY3AgPSBhKihTTHVp bmRleF9UeXBlKWI7CisgICByZXR1cm4gMDsKK30KKwogU0xhbmdfQXJyYXlfVHlwZSAqCiBTTGFu Z19jcmVhdGVfYXJyYXkxIChTTHR5cGUgdHlwZSwgaW50IHJlYWRfb25seSwgVk9JRF9TVEFSIGRh dGEsCiAJCSAgICAgU0xpbmRleF9UeXBlICpkaW1zLCB1bnNpZ25lZCBpbnQgbnVtX2RpbXMsIGlu dCBub19pbml0KQpAQCAtMzY2LDE2ICszODcsMTQgQEAgU0xhbmdfY3JlYXRlX2FycmF5MSAoU0x0 eXBlIHR5cGUsIGludCByZWFkX29ubHksIFZPSURfU1RBUiBkYXRhLAogICAgbnVtX2VsZW1lbnRz ID0gMTsKICAgIGZvciAoaSA9IDA7IGkgPCBudW1fZGltczsgaSsrKQogICAgICB7Ci0JU0xpbmRl eF9UeXBlIG5ld19udW1fZWxlbWVudHM7CiAJYXQtPmRpbXNbaV0gPSBkaW1zW2ldOwotCW5ld19u dW1fZWxlbWVudHMgPSBkaW1zW2ldICogbnVtX2VsZW1lbnRzOwotCWlmIChkaW1zW2ldICYmIChu ZXdfbnVtX2VsZW1lbnRzL2RpbXNbaV0gIT0gbnVtX2VsZW1lbnRzKSkKKworCWlmICgtMSA9PSBj aGVja19vdmVyZmxvd19tdWx0X2kgKG51bV9lbGVtZW50cywgZGltc1tpXSwgJm51bV9lbGVtZW50 cykpCiAJICB7CiAJICAgICB0aHJvd19zaXplX2Vycm9yIChTTF9JbmRleF9FcnJvcik7CiAJICAg ICBmcmVlX2FycmF5IChhdCk7CiAJICAgICByZXR1cm4gTlVMTDsKIAkgIH0KLQludW1fZWxlbWVu dHMgPSBuZXdfbnVtX2VsZW1lbnRzOwogICAgICB9CiAKICAgIC8qIE5vdyBzZXQgdGhlIHJlc3Qg b2YgdGhlIHVudXNlZCBkaW1lbnNpb25zIHRvIDEuICBUaGlzIG1ha2VzIGl0IGVhc2llcgpAQCAt Mzk1LDggKzQxNCwxMCBAQCBTTGFuZ19jcmVhdGVfYXJyYXkxIChTTHR5cGUgdHlwZSwgaW50IHJl YWRfb25seSwgVk9JRF9TVEFSIGRhdGEsCiAJcmV0dXJuIGF0OwogICAgICB9CiAKLSAgIHNpemUg PSAobnVtX2VsZW1lbnRzICogc2l6ZW9mX3R5cGUpOwotICAgaWYgKChzaXplL3NpemVvZl90eXBl ICE9IG51bV9lbGVtZW50cykgfHwgKHNpemUgPCAwKSkKKyAgIC8qIFNMbWFsbG9jIGlzIGN1cnJl bnRseSBsaW1pdGVkIHRvIHRoZSB1c2Ugb2YgdW5zaWduZWQgaW50ZWdlcnMuCisgICAgKiBTbyBp bmNsdWRlIHRoZSBzaXplIG9mIHRoZSB0eXBlIGFzIHdlbGwuCisgICAgKi8KKyAgIGlmICgtMSA9 PSBjaGVja19vdmVyZmxvd19tdWx0X2kgKG51bV9lbGVtZW50cywgc2l6ZW9mX3R5cGUsICZzaXpl KSkKICAgICAgewogCXRocm93X3NpemVfZXJyb3IgKFNMX0lOVkFMSURfUEFSTSk7CiAJZnJlZV9h cnJheSAoYXQpOwpAQCAtMTEwMyw3ICsxMTI0LDYgQEAgY29udmVydF9uYXN0eV9pbmRleF9vYmpz IChTTGFuZ19BcnJheV9UeXBlICphdCwKICAgIHRvdGFsX251bV9lbGVtZW50cyA9IDE7CiAgICBm b3IgKGkgPSAwOyBpIDwgbnVtX2luZGljZXM7IGkrKykKICAgICAgewotCVNMdWluZGV4X1R5cGUg bmV3X3RvdGFsX251bV9lbGVtZW50czsKIAlTTGFuZ19PYmplY3RfVHlwZSAqb2JqID0gaW5kZXhf b2JqcyArIGk7CiAJcmFuZ2VfZGVsdGFfYnVmIFtpXSA9IDA7CiAKQEAgLTExNDUsMTMgKzExNjUs MTEgQEAgY29udmVydF9uYXN0eV9pbmRleF9vYmpzIChTTGFuZ19BcnJheV9UeXBlICphdCwKIAkg ICAgICAgfQogCSAgfQogCi0JbmV3X3RvdGFsX251bV9lbGVtZW50cyA9IHRvdGFsX251bV9lbGVt ZW50cyAqIG1heF9kaW1zW2ldOwotCWlmIChtYXhfZGltc1tpXSAmJiAobmV3X3RvdGFsX251bV9l bGVtZW50cy9tYXhfZGltc1tpXSAhPSB0b3RhbF9udW1fZWxlbWVudHMpKQorCWlmICgtMSA9PSBj aGVja19vdmVyZmxvd19tdWx0X3VpICh0b3RhbF9udW1fZWxlbWVudHMsIG1heF9kaW1zW2ldLCAm dG90YWxfbnVtX2VsZW1lbnRzKSkKIAkgIHsKIAkgICAgIHRocm93X3NpemVfZXJyb3IgKFNMX0lO VkFMSURfUEFSTSk7CiAJICAgICByZXR1cm4gLTE7CiAJICB9Ci0gICAgICAgdG90YWxfbnVtX2Vs ZW1lbnRzID0gbmV3X3RvdGFsX251bV9lbGVtZW50czsKICAgICAgfQogCiAgICAqbnVtX2VsZW1l bnRzID0gdG90YWxfbnVtX2VsZW1lbnRzOwo=