в общем, раньше я не делал очень больших проектов, поэтому не придавал значения важности проверки работы релиз версии на всем этапе разработки. и вот теперь столкнулся с ситуацией — проект большой (около 3М 1.2М в .rar самописного кода), дебаг-версия работает, как надо, релизная не так, как надо.
как бы на распутьи, как малой кровью из этой ситуации выкарабкаться.
первым делом включил уровень /w4 ворнингов, с надеждой обнаружить нужное. но нет, ничего значительного.
далее попытался проверить код встроенным в VS2013 анализатором кода, но анализатор споткнулся на попытках проанализировать используемые boost-овские файлы и выдал internal error
была надежда на psv-студию, но она только под win x64, а у меня стоит win7 x32
думал попробовать вручную — сделать ассерты для релизной версии, но хорошего решения, не засоряющего код, пока не нашел (у меня код, относящийся к бизнес-логике, работает только с boost и cereal, а код gui — на qt. выбросить ассерт через std::excеption (а как по-другому, чтоб универсально?) оказалось в qt проблематичным (qt, по-видимому, не очень дружит с c++ exception-ами)
вот и непонятно, в какую сторону двигаться
upd. суть оказалось в использовании неинициализированных переменных (почему-то vs не все случаи может отслеживать) — при установке в vs /sdl вероятно, студия начала перезаписывать эти переменные, и у меня перестал работать даже debug версия, что позволило легко обнаружить место и саму пробелему простым дебагингом.
всем спасибо за советы. приму на будущее к сведению
Здравствуйте, _hum_, Вы писали:
__> в общем, раньше я не делал очень больших проектов, поэтому не придавал значения важности проверки работы релиз версии на всем этапе разработки. и вот теперь столкнулся с ситуацией — проект большой (около 3М в .rar самописного кода), дебаг-версия работает, как надо, релизная не так, как надо. __>как бы на распутьи, как малой кровью из этой ситуации выкарабкаться. __>первым делом включил уровень /w4 ворнингов, с надеждой обнаружить нужное. но нет, ничего значительного. __>далее попытался проверить код встроенным в VS2013 анализатором кода, но анализатор споткнулся на попытках проанализировать используемые boost-овские файлы и выдал internal error __>была надежда на psv-студию, но она только под win x64, а у меня стоит win7 x32 __>думал попробовать вручную — сделать ассерты для релизной версии, но хорошего решения, не засоряющего код, пока не нашел (у меня код, относящийся к бизнес-логике, работает только с boost и cereal, а код gui — на qt. выбросить ассерт через std::excеption (а как по-другому, чтоб универсально?) оказалось в qt проблематичным (qt, по-видимому, не очень дружит с c++ exception-ами)
__>вот и непонятно, в какую сторону двигаться
Здравствуйте, Nuzhny, Вы писали:
N>Здравствуйте, _hum_, Вы писали:
__>>вот и непонятно, в какую сторону двигаться
N>1. Логи.
и как это по-хорошему огранизтвать, чтоб н едублировать и assert в дебаг-версии и логирвоание? и оно должно включаться макросами, или в самом приложении (чтобы пользователь имел возможность включать логирование, чтобы отправлять разработчику)?
N>2. Если всё такое кроссплатформенное, то Linux.
а при чем тут Ос? вроде, проблема кросс-платформенная
Здравствуйте, _hum_, Вы писали:
__>вот и непонятно, в какую сторону двигаться
1. Попытайтесь комментарить подозрительные функции и смотреть будет ли проявляться глюки, пытаясь локализовать проблему постепенно сужая облать до одной функции/класса
2. Если дебаг работает нормально, не "проезжая" по памяти, то следующая наиболее вероятная проблема, это что-то где-то не инициализировано. Проинициализируте везде, где можно, все переменные и буфера нулями. 90% что баг в этом.
Здравствуйте, Videoman, Вы писали:
V>Здравствуйте, _hum_, Вы писали:
__>>вот и непонятно, в какую сторону двигаться
V>1. Попытайтесь комментарить подозрительные функции и смотреть будет ли проявляться глюки, пытаясь локализовать проблему постепенно сужая облать до одной функции/класса
во-первых, функций слишком много, во-вторых, перекомпиляция обычно занимает около 5-10 минут — у просто физически не смогу все возможные варианты проверить
V>2. Если дебаг работает нормально, не "проезжая" по памяти, то следующая наиболее вероятная проблема, это что-то где-то не инициализировано. Проинициализируте везде, где можно, все переменные и буфера нулями. 90% что баг в этом.
но ведь w4 не ругался (обычно он ругается на неинициализированные).
Здравствуйте, _hum_, Вы писали:
__> во-первых, функций слишком много, во-вторых, перекомпиляция обычно занимает около 5-10 минут — у просто физически не смогу все возможные варианты проверить
Используйте градиентный спуск, метод деления пополам (примерно), придется компилировать.
__>но ведь w4 не ругался (обычно он ругается на неинициализированные).
Только на самые простые случаи. Сомневаюсь что он проверяет поля классов и все буфера и указатели.
дебаг-версия работает, как надо, релизная не так, как надо
Здравствуйте, _hum_, Вы писали:
__> в общем, раньше я не делал очень больших проектов, поэтому не придавал значения важности проверки работы релиз версии на всем этапе разработки. и вот теперь столкнулся с ситуацией — проект большой (около 3М в .rar самописного кода), дебаг-версия работает, как надо, релизная не так, как надо.
__>вот и непонятно, в какую сторону двигаться
Такое случается если где-то портишь память. В debug-версии там хранится отладочная информация, а в release по этому адресу могут быть необходимые данные.
Привело к этому, скорее всего, какое-то недавнее изменение, — иначе перезапись памяти бы проявилась ранее.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, _hum_, Вы писали:
__>Здравствуйте, kov_serg, Вы писали:
_>>Попробуй разные уровние оптимизации в release.
__>и как это поможет, даже если я увижу, что при каком-то уровне работать начинает нормально — как я найду ошибку в проге (ведь, наверняка, она есть)?
Например, непадающая программа, собранная в релизе с выключенной оптимизацией, это гораздо лучше, чем объяснять заказчику, что нет вообще ничего.
Здравствуйте, tdiff, Вы писали:
T>Здравствуйте, _hum_, Вы писали:
__>>Здравствуйте, kov_serg, Вы писали:
_>>>Попробуй разные уровние оптимизации в release.
__>>и как это поможет, даже если я увижу, что при каком-то уровне работать начинает нормально — как я найду ошибку в проге (ведь, наверняка, она есть)?
T>Например, непадающая программа, собранная в релизе с выключенной оптимизацией, это гораздо лучше, чем объяснять заказчику, что нет вообще ничего.
во-первых, мне скорость критична (поэтому оптимизацию снижать — это плохо), во-вторых, это работа не из ряда "ради галочки", ну и в-третьих, самое важное — это же означает, что возможно, в проге есть ошибка, и как ее отдавать, зная, что она там?
Здравствуйте, _hum_, Вы писали:
__>и как это по-хорошему огранизтвать, чтоб н едублировать и assert в дебаг-версии и логирвоание? и оно должно включаться макросами, или в самом приложении (чтобы пользователь имел возможность включать логирование, чтобы отправлять разработчику)?
glogs, например.
N>>2. Если всё такое кроссплатформенное, то Linux. __>а при чем тут Ос? вроде, проблема кросс-платформенная
В другой ОС другие средства для анализа, другой компилятор.
Здравствуйте, Videoman, Вы писали:
V>Здравствуйте, _hum_, Вы писали:
__>> во-первых, функций слишком много, во-вторых, перекомпиляция обычно занимает около 5-10 минут — у просто физически не смогу все возможные варианты проверить V>Используйте градиентный спуск, метод деления пополам (примерно), придется компилировать.
это "сферический конь в вакууме" (кстати, как вы градиент-то искать будете. или имели в виду покоординатный?
__>>но ведь w4 не ругался (обычно он ругается на неинициализированные). V>Только на самые простые случаи. Сомневаюсь что он проверяет поля классов и все буфера и указатели.
вроде, проверяет. по кр. мере, при попытке использования неинициализированной переменной он выдавал исключение.
V>
V>дебаг-версия работает, как надо, релизная не так, как надо
V>что изменяется то хоть можно узнать ?
есть модель, есть эмулятор работы с ней. так вот в релизе эмулятор говорит, что модель невалидна
[да-да, знаю, что можно повводить коды невалидности и отслеживать, что да как. но это все-таки серьезный кусок работы, ис перва хотелось бы выслушать другие варианты решения, чтоб уже с чистой совестью закасывать рукава]
Здравствуйте, _hum_, Вы писали:
__> во-первых, мне скорость критична (поэтому оптимизацию снижать — это плохо), во-вторых, это работа не из ряда "ради галочки", ну и в-третьих, самое важное — это же означает, что возможно, в проге есть ошибка, и как ее отдавать, зная, что она там?
Здравствуйте, lpd, Вы писали:
lpd>Здравствуйте, _hum_, Вы писали:
__>> в общем, раньше я не делал очень больших проектов, поэтому не придавал значения важности проверки работы релиз версии на всем этапе разработки. и вот теперь столкнулся с ситуацией — проект большой (около 3М в .rar самописного кода), дебаг-версия работает, как надо, релизная не так, как надо.
__>>вот и непонятно, в какую сторону двигаться
lpd>Такое случается если где-то портишь память. В debug-версии там хранится отладочная информация, а в release по этому адресу могут быть необходимые данные. lpd>Привело к этому, скорее всего, какое-то недавнее изменение, — иначе перезапись памяти бы проявилась ранее.
мне тоже так кажется. вот как такую гадость отловить... раньше помогал анализатор кода, но сейчас он, видите, не способен переварить проект
может, есть какие-то сторонние анализаторы именно такой проблемы?
Здравствуйте, _hum_, Вы писали:
__>Здравствуйте, lpd, Вы писали:
lpd>>Здравствуйте, _hum_, Вы писали:
__>>> в общем, раньше я не делал очень больших проектов, поэтому не придавал значения важности проверки работы релиз версии на всем этапе разработки. и вот теперь столкнулся с ситуацией — проект большой (около 3М в .rar самописного кода), дебаг-версия работает, как надо, релизная не так, как надо.
__>>>вот и непонятно, в какую сторону двигаться
lpd>>Такое случается если где-то портишь память. В debug-версии там хранится отладочная информация, а в release по этому адресу могут быть необходимые данные. lpd>>Привело к этому, скорее всего, какое-то недавнее изменение, — иначе перезапись памяти бы проявилась ранее.
__>мне тоже так кажется. вот как такую гадость отловить... раньше помогал анализатор кода, но сейчас он, видите, не способен переварить проект __>может, есть какие-то сторонние анализаторы именно такой проблемы?
Можно попробовать запустить под valgrind. Также в аналогичной ситуации мне однажды пришлось перегружать во всем проекте функции выделения памяти, метить границы буферов и вести счетчики выделения/освобождения, — эти меры помогли. Но скорее всего, дело в недавних изменениях, и может оказаться легче откатывать постепенно все правки, пока программа не начнет стабильно работать
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, _hum_, Вы писали:
__> это "сферический конь в вакууме" (кстати, как вы градиент-то искать будете. или имели в виду покоординатный? ну придумайте метрику какую-нибудь
__>есть модель, есть эмулятор работы с ней. так вот в релизе эмулятор говорит, что модель невалидна
Эмулятор конечно же "черный ящик". Упростить модель можно? Пустая модель тоже невалидна?
А многопоточность есть?
Здравствуйте, Videoman, Вы писали:
V>Здравствуйте, _hum_, Вы писали:
__>>есть модель, есть эмулятор работы с ней. так вот в релизе эмулятор говорит, что модель невалидна V>Эмулятор конечно же "черный ящик".
все — белый ящик. просто очень большой и не совсмем прозрачный. поэтому лезть в него ох как неохота.
V>Упростить модель можно? Пустая модель тоже невалидна?
пустая модель невалидна для эмулятора по определению
V>А многопоточность есть?
Здравствуйте, _hum_, Вы писали:
__>вот и непонятно, в какую сторону двигаться
Как вариант можешь выключить оптимизацию в release — если результат станет "нормальным", то можешь постепенно включать/выключать оптимизацию в отдельных translation units по методу divide and conquer. Так за логарифмическое число шагов локализуешь хотя бы один проблемный TU. Далее например можешь включать/выключать оптимизацию на уровне функций.
(qt, по-видимому, не очень дружит с c++ exception-ами)
