Unstable test _unit.test.layer.extra_layer_query

[eao197]

Unstable test _unit.test.layer.extra_layer_query

О, клево, возможно, это гонка. Попробуй собрать это из репозитория на SF с помощью Mxx_ru и, если воспроизведется, то тогда это к Жене. Только Mxx_ru нужен последней версии, если он у тебя установлен, то нужно обновить.

[DronMDF]

Cлова Mxx_ru меня пугают. :)
Ладно, попробую посмотреть на досуге...

[eao197]

Это какая-то странная штука. У меня проявилась один раз несколько недель назад, да еще в очень специфических условиях. Ни до, ни после больше не проявлялась.
Буду разбираться.

На какой конфигурации она проявилась?

[eao197]

Лёш, так я не у тебя спрашиваю :) Надеюсь, что мой вопрос и Андрей получил и ответит, когда сможет.

[DronMDF]

ubuntu 14.10 (x86_64)
gcc (Ubuntu 4.9.1-16ubuntu6) 4.9.1

Простой прогон сфейлился случайно...

Обычно я для нестабильных тестов делаю так:
$ while test/so_5/layer/extra_layer_query/_unit.test.layer.extra_layer_query; do true; done
Нескольких секунд хватает, чтобы словить падение...
А дальше надо копать глубже...

PS: А еще у меня запущен boinc, загрузка постоянно почти 100%. Щас я проверю насколько это влияет. Да не, не влияет особо...

PPS: Забыл упомянуть... у меня четырехядерный Intel(R) Core(TM) i5-2500 CPU @ 3.30GHz

Лёш, так я не у тебя спрашиваю

Я познаю гитхаб... В почту сыплется, нипонятно что с гитхаба, выглядит как обычное письмо. А потом еще и ответы куда не надо попадают... Ох уж эта юзерфрендливость...

[DronMDF]

Ты являешься участником переписки....
Можно в настройках отключить нотификации на емейл и вообще... :)

[eao197]

Ok, у меня стал стабильно падать в цикле. Буду разбираться, что к чему.

[eao197]

Походу, нашел проблему. Если дело в том, что я думаю, то проблема не в SO5, а в организации этой группы тестов. Они старые и не были расчитанны на режим autoshutdown. Когда этот режим появился, возник еще один момент выдачи команды на завершение работы SOEnv. Как раз этот момент иногда проявляется и ресурсы, проверка наличия которых выполняется в тесте, успевают очистится.

Погоняю обновленный тест в течении получасика, заодно проверю другие похожие. Если все будет нормально, закомичу изменения.

[eao197]

Исправления залиты в branch/so_5/5.5 на SF.net.
Не думаю, что из-за этих правок имеет смысл прямо сегодня выкатывать версию 5.5.4.1...

Сделал слияние изменений.

Fixed c908447

Андрей, закрой пожалуйста баг. Женя мне не разрешает.

[eao197]

@DronMDF, если у тебя баг не проявляется, то смени статус у бага.
Просто я придерживаюсь правила, что баг закрывает тот, кто его открыл. Но если этого не происходит в течении длительного времени, тогда баг закрывают уже сами владельцы проекта.

[DronMDF]

Строго у вас... :)
github умеет закрывать тикеты через коммит мессаджи.

Проверил не совсем в тех же условиях, но 4 ядра, та же убунта, такой же 64-х битный проц, и компилятор тот же.

С этим тестом все хорошо. Изучал диффы, но ничего не понял. :)

[eao197]

@DronMDF попробую объяснить, что это было :)
Изначально SObjectizer не мог сам завершать свою работу. Если создали SObjectizer Environment и запустили его, то нужно дать явную команду на останов. В данном тесте как раз создавался специальный SOEnvironment, в котором регистрировались объекты для проверки (они должны были находиться по своему типу). В условиях явного останова SOEnvironment все работало стабильно.
Но в версии 5.4.0 добавлена возможность останова SOEnvironment в случае, когда больше не остается работающих коопераций. Как раз в этом было все дело. SOEnvironment в тесте стартовал, в него добавлялись объекты для проверки. Потом на отдельной нити запускалась сама проверка.
Однако, если до того, как проверка стартует, SOEnvironment успевал обнаружить отсутствие работающих коопераций, то SOEnvironment успевал заглушить сам себя и выбросить всю хранящующся в нем информацию. Из-за чего проверка проваливалась.
Только нужно было, чтобы случилось вот такое удачное стечение обстоятельств -- одна нить сильно затормозила, а вторая резко ускорилась. С момента выпуска 5.4.0 (август 2014-го) у меня эта штука проявилась только однажды и то, когда в коде было много других проблем и я подумал, что это их проявление.

А еще у тебя винда, которая постоянно перекидывает потоки с одного ядра на другое чтобы данные в кеше не задерживались. А в виртуалке такое тестировать бесполезно (ибо сама виртуалка начинает дополнительно сериализовывать потоки, да и работает она поверх той же винды, которая...).

В общем, вдарим гитхабом по гонкам данных.

[eao197]

Ну как раз под виртуалкой и боролся сегодня :)

[DronMDF]

Спасибо за разъяснение.

Я пока не придумал, чем мне может быть полезен SObjectizer, и как я могу заюзать его в каких-то своих рабочих или хобби проектах. Конечно впихнуть можно, но ведь не самоцель же. И вокруг вообще много интересных технологий... есть чем заняться. Так что мой интерес пока чисто теоретический. Будет время, я поковыряюсь в недрах...

А со всякими многопоточностями всегда так... на билдере падает, на рабочей машине все хорошо, и вот думаешь, как это отловить... запускаешь много раз подряд, вдруг на тысячный раз сфейлится... Или вообще в паралель много раз подрят.. и ловишь через отладку...

Или хуже, у клиентов падает... :) А до релиза - ну хоть бы кто заметил...

[eao197]

Ну у нас же нет цели впарить SObjectizer всем :)
Задача в том, чтобы разработка была качественной и солидной (в хорошем смысле этого слова). А если о ней еще и много людей будет знать, то вообще хорошо.

[DronMDF]

Это я к тому, что дескать простите, что я так поверхностно подхожу...
Пособирать, тесты погонять - это пожалуйста..
А вот на подвиги - типа руби поставить... мне лень... :)
И вспоминать, как пользоваться svn мне тоже местами лень... :)