Думаю, что с весьма приличной вероятностью у тебя ошибки доступа к памяти (выход за пределы выделенного блока в куче ("расстрел кучи"), использование неинициализированных переменных/полей и т.д.)
Можно поставить генерацию отладочной информации в Release.
Ложных ( а может, и не ложных, у меня он в boost-библиотеке ошибки нашел, но мне не до отладки boost) тревог будет много, но, возможно, найдешь что-то важное. Я нашел.
Дальше надо искать причину путем отладки, можно в Debug.
Еще для этой же цели можно использовать Bounds Checker
Когда-то он был очень хорош, пока был от Numega. Дальше становился все хуже и хуже. В последнем моем проекте толку от него не было, приложение фактически не работало под ним. Тем не менее попробовать можно — вдруг тебе повезет больше.
P.S. Иногда еще помогает сборка с STL с поддержкой отладочных итераторов. Я с их помощью как-то поймал лютый баг с расстрелом памяти из-за "висящей" ссылки.
Здравствуйте, _hum_, Вы писали:
__> в общем, раньше я не делал очень больших проектов, поэтому не придавал значения важности проверки работы релиз версии на всем этапе разработки. и вот теперь столкнулся с ситуацией — проект большой (около 3М в .rar самописного кода), дебаг-версия работает, как надо, релизная не так, как надо.
"релизная не так, как надо" — это как? Не тот результат? Падает? Ещё что?
Здравствуйте, Videoman, Вы писали:
V>Здравствуйте, _hum_, Вы писали:
__>>вот и непонятно, в какую сторону двигаться
V>2. Если дебаг работает нормально, не "проезжая" по памяти, то следующая наиболее вероятная проблема, это что-то где-то не инициализировано. Проинициализируте везде, где можно, все переменные и буфера нулями. 90% что баг в этом.
вы были правы — проблема крылась в использовании неинициализированных переменных
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, _hum_, Вы писали:
__>>как бы на распутьи, как малой кровью из этой ситуации выкарабкаться.
Pzz>А никак. Отлаживать заново.
Pzz>Вообще никогда не понимал, зачем нужна Debug-сборка. Вместо одной программы приходится тестировать и отлаживать две.
проблема быстро решилась после того, как настройка среды привела к проявлению этой проблемы и в дебаг версии (это к вопросу о полезности дебагинга)
Здравствуйте, lpd, Вы писали:
lpd>Здравствуйте, _hum_, Вы писали:
__>> в общем, раньше я не делал очень больших проектов, поэтому не придавал значения важности проверки работы релиз версии на всем этапе разработки. и вот теперь столкнулся с ситуацией — проект большой (около 3М в .rar самописного кода), дебаг-версия работает, как надо, релизная не так, как надо.
__>>вот и непонятно, в какую сторону двигаться
lpd>Такое случается если где-то портишь память. В debug-версии там хранится отладочная информация, а в release по этому адресу могут быть необходимые данные. lpd>Привело к этому, скорее всего, какое-то недавнее изменение, — иначе перезапись памяти бы проявилась ранее.
нет, если бы был выход за пределы, то студия бы обнаружила в дебаг версии (потому что она такие проверки делает). а вот с использованием неинициализированных переменных сложнее. именно этот случай у меня и вылез.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, _hum_, Вы писали:
__>>вот и непонятно, в какую сторону двигаться
EP>Как вариант можешь выключить оптимизацию в release — если результат станет "нормальным", то можешь постепенно включать/выключать оптимизацию в отдельных translation units по методу divide and conquer. Так за логарифмическое число шагов локализуешь хотя бы один проблемный TU. Далее например можешь включать/выключать оптимизацию на уровне функций.
я почему-то думал, что вы опять начнете про юнит-тестирование говорить
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, _hum_, Вы писали:
PD>Думаю, что с весьма приличной вероятностью у тебя ошибки доступа к памяти (выход за пределы выделенного блока в куче ("расстрел кучи"), использование неинициализированных переменных/полей и т.д.)
PD>Можно поставить генерацию отладочной информации в Release.
PD>https://msdn.microsoft.com/en-us/library/xe4t6fc1.aspx
PD>Будут работать точки прерывания. Хотя по моему опыту ничему тому, что показывает отладчик, верить нельзя — слишком уж хорошо код оптимизирован.
PD>Лучше попробуй запустить для Debug версии (или Release версии с отладочной информацией) вот это
PD>http://www.drmemory.org/
PD>Ложных ( а может, и не ложных, у меня он в boost-библиотеке ошибки нашел, но мне не до отладки boost) тревог будет много, но, возможно, найдешь что-то важное. Я нашел.
PD>Дальше надо искать причину путем отладки, можно в Debug.
PD>Еще для этой же цели можно использовать Bounds Checker
PD>http://www.borland.com/en-GB/Products/Software-Testing/Automated-Testing/Devpartner-Studio
PD>(Как вам имя сайта, а ? Жив курилка
PD>Когда-то он был очень хорош, пока был от Numega. Дальше становился все хуже и хуже. В последнем моем проекте толку от него не было, приложение фактически не работало под ним. Тем не менее попробовать можно — вдруг тебе повезет больше.
спасибо. приму к сведению на будущее. а дело было в "использование неинициализированных переменных/полей " (студия это не может напрямую обнаружить, но специально делает разное заполнение в дебаг и релиз версии начальные значения, чтобы хоть как-то указать на то, что что-то не так )
Здравствуйте, Lexey, Вы писали:
L>Здравствуйте, _hum_, Вы писали:
__>>вот и непонятно, в какую сторону двигаться
L>Может еще не совсем актуальность потеряло: L>http://rsdn.org/article/vcpp/survrls.xml
L>)
L>P.S. Иногда еще помогает сборка с STL с поддержкой отладочных итераторов. Я с их помощью как-то поймал лютый баг с расстрелом памяти из-за "висящей" ссылки.
Здравствуйте, B0FEE664, Вы писали:
BFE>Здравствуйте, _hum_, Вы писали:
__>> в общем, раньше я не делал очень больших проектов, поэтому не придавал значения важности проверки работы релиз версии на всем этапе разработки. и вот теперь столкнулся с ситуацией — проект большой (около 3М в .rar самописного кода), дебаг-версия работает, как надо, релизная не так, как надо.
BFE>"релизная не так, как надо" — это как? Не тот результат? Падает? Ещё что?
самый худший вариант — работает не так, как ожидалось, но не не падает.
Здравствуйте, _hum_, Вы писали:
__>>>вот и непонятно, в какую сторону двигаться EP>>Как вариант можешь выключить оптимизацию в release — если результат станет "нормальным", то можешь постепенно включать/выключать оптимизацию в отдельных translation units по методу divide and conquer. Так за логарифмическое число шагов локализуешь хотя бы один проблемный TU. Далее например можешь включать/выключать оптимизацию на уровне функций. __> я почему-то думал, что вы опять начнете про юнит-тестирование говорить
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, _hum_, Вы писали:
PD>Думаю, что с весьма приличной вероятностью у тебя ошибки доступа к памяти (выход за пределы выделенного блока в куче ("расстрел кучи"), использование неинициализированных переменных/полей и т.д.)
Скучные причины какие-то у вас. Весело, когда ничего не висит и всё инициализировано, но релиз всё равно глючит. А в асмовыхлопе — нечто, не соответствующее никакому валидному коду. 2003я студия отжигала знатно, да...
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Сдается мне, что проблема не столько оттого, что проект большой (3 мб рар в выражениях — это сколько?), а оттого, что он монолитный и по частям его работоспособность не проверить.
И вообще, что значит "не так, как надо"?
/w4 полезно держать включенным постоянно.
Если статические анализаторы не помогают, то имеет смысл использовать динамические visual leak detector, app verifier, встроенные рантайм проверки.
А что за проблемы с ассертами? Компилируйте с _DEBUG DEBUG и оптимизациями.
Говорить дальше не было нужды. Как и все космонавты, капитан Нортон не испытывал особого доверия к явлениям, внешне слишком заманчивым.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, _hum_, Вы писали:
__>>>>вот и непонятно, в какую сторону двигаться EP>>>Как вариант можешь выключить оптимизацию в release — если результат станет "нормальным", то можешь постепенно включать/выключать оптимизацию в отдельных translation units по методу divide and conquer. Так за логарифмическое число шагов локализуешь хотя бы один проблемный TU. Далее например можешь включать/выключать оптимизацию на уровне функций. __>> я почему-то думал, что вы опять начнете про юнит-тестирование говорить
EP>В контексте чего я про него говорил?
ааа. сори, это я вас с Stanislav V. Zudin перепутал (тоже ник — фамилия, имя)
Здравствуйте, T4r4sB, Вы писали:
TB>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Здравствуйте, _hum_, Вы писали:
PD>>Думаю, что с весьма приличной вероятностью у тебя ошибки доступа к памяти (выход за пределы выделенного блока в куче ("расстрел кучи"), использование неинициализированных переменных/полей и т.д.)
TB>Скучные причины какие-то у вас. Весело, когда ничего не висит и всё инициализировано, но релиз всё равно глючит. А в асмовыхлопе — нечто, не соответствующее никакому валидному коду. 2003я студия отжигала знатно, да...
Оптимизирующий компилятор делает различные предположения о той сущности, с которой он имеет дело. Проблема в том, что взгляд компилятора на реальность целиком базируется на ряде предположений, все из которых программист на C может очень легко нарушить. Результатом этой неправильной интерпретации реальности будет то, что вы можете обмануть компилятор, заставив его генерировать "плохой код". В действительности, он не плохой — это совершенно правильный код, при условии, что предположения компилятора были верны. Если вы явно или неявно лгали компилятору, то с него взятки гладки.
Здравствуйте, VTT, Вы писали:
VTT>Сдается мне, что проблема не столько оттого, что проект большой (3 мб рар в выражениях — это сколько?), а оттого, что он монолитный и по частям его работоспособность не проверить.
нет. проблема именно в объемности (он ен монолитный). 3M rar — это столько кода, что если заархивировать в рар (с настройками по умолчанию), то получится 3М [просто это, имхо, наиболее адекватная оценка объема информации в коде. все остальные оценки наподобие — число строк, число слов и проч. — очень сильно зависят от стилистики]
VTT>И вообще, что значит "не так, как надо"?
писал выше — работает не так, как ожидалось, когда "2+2 = 5"
VTT>/w4 полезно держать включенным постоянно.
ой, он так шумит. например, на неиспользованные переменные. а у меня они для отладки остаются. а еще есть унифицированные функции, с общей сигнатурой, но в теле которых могут не использоваться некоторые параметры. и вот он на них тоже ругается.
VTT>Если статические анализаторы не помогают, то имеет смысл использовать динамические visual leak detector, app verifier, встроенные рантайм проверки.
статические как раз-таки помогли бы. тут проблема найти рабочий
VTT>А что за проблемы с ассертами? Компилируйте с _DEBUG DEBUG и оптимизациями.
ассерты в дебаг версии не работают. надо писать свои. вот и проблема, как лучше это сделать.
Дадада, я читал, что типа такого не бывает, что компиль лажает. Долго думал, где же я ошибся, только время зря потратил на поиск своей ошибки. Так вот не ошибался я. Компиль лажал.
Пруф могу найти.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, T4r4sB, Вы писали:
TB>Здравствуйте, _hum_, Вы писали:
__>>
__>>"Ошибки" компилятора
TB>Дадада, я читал, что типа такого не бывает, что компиль лажает. Долго думал, где же я ошибся, только время зря потратил на поиск своей ошибки. Так вот не ошибался я. Компиль лажал. TB>Пруф могу найти.
По-моему число выражений (statements) как раз очень хорошо показывает реальный объем кода.
__>ой, он так шумит. например, на неиспользованные переменные. а у меня они для отладки остаются. а еще есть унифицированные функции, с общей сигнатурой, но в теле которых могут не использоваться некоторые параметры. и вот он на них тоже ругается.
Можно явно указывать, что они не используются.
__>ассерты в дебаг версии не работают
-_-'
это как так?
даже просто __debugbreak?
Говорить дальше не было нужды. Как и все космонавты, капитан Нортон не испытывал особого доверия к явлениям, внешне слишком заманчивым.
Здравствуйте, VTT, Вы писали:
VTT>По-моему число выражений (statements) как раз очень хорошо показывает реальный объем кода.
__>>ой, он так шумит. например, на неиспользованные переменные. а у меня они для отладки остаются. а еще есть унифицированные функции, с общей сигнатурой, но в теле которых могут не использоваться некоторые параметры. и вот он на них тоже ругается.
VTT>Можно явно указывать, что они не используются.
как именно?
__>>ассерты в дебаг версии не работают VTT>-_-' VTT>это как так?
[просто это, имхо, наиболее адекватная оценка объема информации в коде. все остальные оценки наподобие — число строк, число слов и проч. — очень сильно зависят от стилистики] 