Здравствуйте, Sheridan, Вы писали:
S>Я это понял еще в предыдущем сообщении. Понял то, что ты считаешь, что оно приходит случайно. Считаешь ты это потому что не знаешь по какой причине оно падает. То что ты не пытался эту причину найти — опустим. А вот то, что ты утверждаешь
Какой же ты тугой. Первопричина — то, что один поток записал новое значение переменной, а другой считал без соответствующей блокировки. Что, само по себе, не обязательно приводит к проблемам, но при определенном стечении обстоятельств приводит к считыванию мусора. А определенные обстоятельства — это, например, то, что писатель и читатель выполнялись на разных ядрах, а считывание произошло до того, как данные целиком попали из L2 кэша одного ядра в L2 кэш другого. Что, конечно, теоретически можно считать детерминированными условиями, но только при условии что твой код — единственный, который выполняется в системе, и у тебя есть возможность контролировать работу процессора на очень низком уровне. А практически, эти условия можно и нужно считать случайными.
Здравствуйте, stronk2, Вы писали:
S>Какой же ты тугой. Первопричина — то, что один поток записал новое значение переменной, а другой считал без соответствующей блокировки. Что, само по себе, не обязательно приводит к проблемам, но при определенном стечении обстоятельств приводит к считыванию мусора. А определенные обстоятельства — это, например, то, что писатель и читатель выполнялись на разных ядрах, а считывание произошло до того, как данные целиком попали из L2 кэша одного ядра в L2 кэш другого. Что, конечно, теоретически можно считать детерминированными условиями, но только при условии что твой код — единственный, который выполняется в системе, и у тебя есть возможность контролировать работу процессора на очень низком уровне. А практически, эти условия можно и нужно считать случайными.
1. Вот это намного более похоже на багрепорт
2. Почему ты не сделал подобную блокировку\проверку на своей стороне? Или у вас там проблемы с архитектурой? Пользуете глобальные переменные? Ну в таком случае баг именно в этом.
Здравствуйте, stronk2, Вы писали:
E>>В детерминированных безглючных программах не особо... S>В сферовакуумных, ты хотел сказать?
Да нет, просто в нормальных
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Sheridan, Вы писали:
S>1. Вот это намного более похоже на багрепорт
На самом деле, это объяснение азов для безграмотных.
S>2. Почему ты не сделал подобную блокировку\проверку на своей стороне? Или у вас там проблемы с архитектурой? Пользуете глобальные переменные? Ну в таком случае баг именно в этом.
Блокировку внутренних данных библиотеки на "своей стороне"? Очевидно, ты все-таки не понял, о чем шла речь.
Здравствуйте, lxa, Вы писали:
lxa>Откуда следует, что закрытие процесса с сохранением stack trace в результате этого исключения является багом? Может, это нормальное поведение.
Оттуда, что так говорит разработчик того процесса, который является конечным продуктом. То есть я. Отлов и сохранение stack trace необработанных исключений, кстати, тоже делаю я.
Здравствуйте, stronk2, Вы писали:
S>>1. Вот это намного более похоже на багрепорт S>На самом деле, это объяснение азов для безграмотных.
Не волнуйся, тот кто будет читать подобный багрепорт — не обидится, а даже поблагодарит за подробное описание.
S>>2. Почему ты не сделал подобную блокировку\проверку на своей стороне? Или у вас там проблемы с архитектурой? Пользуете глобальные переменные? Ну в таком случае баг именно в этом. S>Блокировку внутренних данных библиотеки на "своей стороне"? Очевидно, ты все-таки не понял, о чем шла речь.
А какой еще можно сделать вывод из фразы
Здравствуйте, stronk2, Вы писали:
E>>Да нет, просто в нормальных S>Такие программы были "нормальными" минимум лет 15 назад. Добро пожаловать в мир будущего.
Угу, где всем на всё насрать. Тебе насрать на работу разработчика библиотеки, который потратит кучу времени на выяснение того что ты имел ввиду. Тебе насрать на свою работу, которая спотыкается о падения библиотеки. Разработчику библиотеки насрать на твой багрепорт, потому как он ни разу не информативный. Разработчику библиотеки насрать на твою работу, потому как у него есть своя. Впрочем по той же причине тебе насрать и на его работу.
И, подводя итог, мне в общем то тоже насрать на всю эту любовь между вами и багрепортом. Ты спросил наше мнение, я тебе ответил и расписал почему именно я так считаю и как бы сделал сам. И насрать мне стало после того, как ты воспринял наше (в том числе и моё) мнение в штыки.
Спасибо за внимание, трансляция сознания окончена.
Здравствуйте, stronk2, Вы писали:
S>Такие программы были "нормальными" минимум лет 15 назад. Добро пожаловать в мир будущего.
Экономить на качестве это тренд. Да.
Тут, дальше личный выбор каждого, либо работать в таких проектах либо нет. М если да, то как.
только если у тебя такой проект и культура, что программы работают иногда, то не понятны все твои стоны, что вот де мол, ты там чего-то поймал, другой программист не поймал а класть жизнь на повторение поведения твоего не всегда работающего кода он не стал. Тоже мне проблема. Если какашку делаешь, то не удивляйся, что при разработке пахнет...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>только если у тебя такой проект и культура, что программы работают иногда
Они не работают иногда. Ты опять демонстрируешь неспособность извлечь смысл из вполне ясного сообщения. Собственно, та самая проблема, о которой я писал.
Баг синхронизации потоков подразумевает случайность по умолчанию. Если ты не знаешь даже азов, то надо этого стыдиться, а не обвинять других, что они знают.
Здравствуйте, stronk2, Вы писали:
S>Здравствуйте, Хреннос, Вы писали:
Х>>Скажите, а вы и с коллегами так же высокомерно общаетесь? Тогда я, кажется, понимаю суть вашей проблемы.
S>Ну во первых, как был сформулирован текст — почти дословно, процитировано в первом сообщении. S>Во вторых — а как иначе я должен был воспринять абсолютно бредовое и безграмотное указание?
Вежливо. Вежливо и спокойно, с желанием помочь(ну или хотя бы не мешать) коллеге. Иди к психологу, у тебя проблемы.
Здравствуйте, stronk2, Вы писали: S>Желаю удачи, искать способ воспроизвести баг в многопоточном коде. Флаг в руки. S>И здесь вопрос о понимании сути проблемы, а не хотелках.
Ага. И видно, что вы сути проблемы не понимаете.
Каким образом QA-шник поймёт, что баг починен? Поверит программисту на слово?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Синонимы подойдут.
S>Баг синхронизации потоков подразумевает случайность по умолчанию. Если ты не знаешь даже азов, то надо этого стыдиться, а не обвинять других, что они знают.
Я спросил, есть ли слово слово "случайно" (включая синонимы) здесь.
Я наивно подразумевал три возможных ответа:
1. Да
2. Нет
3. ХЗ
IMHO твой ответ больше подходит под третий пункт.
Просто на всякий случай, если ты (гипотетически) не знаешь даже, как найти слово в тексте, то надо этого стыдиться, а не обвинять других, что они знают. Если ты не знаешь русский язык, то стыдиться этого не надо, но обвинять других всё равно не стоит.
