Re: debug - release problem
От: Pzz Россия https://github.com/alexpevzner
Дата: 12.08.16 12:54
Оценка: +2
Здравствуйте, _hum_, Вы писали:

__>как бы на распутьи, как малой кровью из этой ситуации выкарабкаться.


А никак. Отлаживать заново.

Вообще никогда не понимал, зачем нужна Debug-сборка. Вместо одной программы приходится тестировать и отлаживать две.
Re[3]: debug - release problem
От: Videoman Россия https://hts.tv/
Дата: 13.08.16 11:06
Оценка: 9 (1)
Здравствуйте, _hum_, Вы писали:

__>вы были правы — проблема крылась в использовании неинициализированных переменных


О-о-о! Очень рад за вас . Но это вам звоночек. Следующий раз так не повезет. Лучше пишите сразу нормально, с инициализацией, ассертами и юнит-тестами.
Отредактировано 13.08.2016 11:07 Videoman . Предыдущая версия .
Re[3]: debug - release problem
От: Nuzhny Россия https://github.com/Nuzhny007
Дата: 12.08.16 14:14
Оценка: 1 (1)
Здравствуйте, _hum_, Вы писали:

__>и как это по-хорошему огранизтвать, чтоб н едублировать и assert в дебаг-версии и логирвоание? и оно должно включаться макросами, или в самом приложении (чтобы пользователь имел возможность включать логирование, чтобы отправлять разработчику)?


glogs, например.

N>>2. Если всё такое кроссплатформенное, то Linux.

__>а при чем тут Ос? вроде, проблема кросс-платформенная

В другой ОС другие средства для анализа, другой компилятор.
Re[3]: debug - release problem
От: lpd Черногория  
Дата: 12.08.16 14:22
Оценка: 1 (1)
Здравствуйте, _hum_, Вы писали:

__>Здравствуйте, lpd, Вы писали:


lpd>>Здравствуйте, _hum_, Вы писали:


__>>> в общем, раньше я не делал очень больших проектов, поэтому не придавал значения важности проверки работы релиз версии на всем этапе разработки. и вот теперь столкнулся с ситуацией — проект большой (около 3М в .rar самописного кода), дебаг-версия работает, как надо, релизная не так, как надо.


__>>>вот и непонятно, в какую сторону двигаться


lpd>>Такое случается если где-то портишь память. В debug-версии там хранится отладочная информация, а в release по этому адресу могут быть необходимые данные.

lpd>>Привело к этому, скорее всего, какое-то недавнее изменение, — иначе перезапись памяти бы проявилась ранее.

__>мне тоже так кажется. вот как такую гадость отловить... раньше помогал анализатор кода, но сейчас он, видите, не способен переварить проект

__>может, есть какие-то сторонние анализаторы именно такой проблемы?

Можно попробовать запустить под valgrind. Также в аналогичной ситуации мне однажды пришлось перегружать во всем проекте функции выделения памяти, метить границы буферов и вести счетчики выделения/освобождения, — эти меры помогли. Но скорее всего, дело в недавних изменениях, и может оказаться легче откатывать постепенно все правки, пока программа не начнет стабильно работать
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Re: debug - release problem
От: Pavel Dvorkin Россия  
Дата: 12.08.16 16:00
Оценка: 1 (1)
Здравствуйте, _hum_, Вы писали:

Думаю, что с весьма приличной вероятностью у тебя ошибки доступа к памяти (выход за пределы выделенного блока в куче ("расстрел кучи"), использование неинициализированных переменных/полей и т.д.)

Можно поставить генерацию отладочной информации в Release.

https://msdn.microsoft.com/en-us/library/xe4t6fc1.aspx

Будут работать точки прерывания. Хотя по моему опыту ничему тому, что показывает отладчик, верить нельзя — слишком уж хорошо код оптимизирован.

Лучше попробуй запустить для Debug версии (или Release версии с отладочной информацией) вот это

http://www.drmemory.org/

Ложных ( а может, и не ложных, у меня он в boost-библиотеке ошибки нашел, но мне не до отладки boost) тревог будет много, но, возможно, найдешь что-то важное. Я нашел.

Дальше надо искать причину путем отладки, можно в Debug.

Еще для этой же цели можно использовать Bounds Checker

http://www.borland.com/en-GB/Products/Software-Testing/Automated-Testing/Devpartner-Studio

(Как вам имя сайта, а ? Жив курилка

Когда-то он был очень хорош, пока был от Numega. Дальше становился все хуже и хуже. В последнем моем проекте толку от него не было, приложение фактически не работало под ним. Тем не менее попробовать можно — вдруг тебе повезет больше.
With best regards
Pavel Dvorkin
Re: debug - release problem
От: Lexey Россия  
Дата: 12.08.16 16:27
Оценка: 1 (1)
Здравствуйте, _hum_, Вы писали:

__>вот и непонятно, в какую сторону двигаться


Может еще не совсем актуальность потеряло:
http://rsdn.org/article/vcpp/survrls.xml
Автор(ы): Dr. Joseph M. Newcomer
Дата: 18.06.2001
Статья посвящена проблемам перехода с Debug-версии на Release-версию. Рассматриваются
типичные ошибки, которые могут не проявляться в отладочной версии, но проявляются в финальной.
Обсуждается вопрос "ошибок компилятора" и вопросы необходимости оптимизации и ее побочные эффекты.
В последней редакции добавлен раздел посвященный проблеме совместимости динамических библиотек.




P.S. Иногда еще помогает сборка с STL с поддержкой отладочных итераторов. Я с их помощью как-то поймал лютый баг с расстрелом памяти из-за "висящей" ссылки.
"Будь достоин победы" (c) 8th Wizard's rule.
Re: debug - release problem
От: kov_serg Россия  
Дата: 12.08.16 12:14
Оценка: +1
Здравствуйте, _hum_, Вы писали:

__> в общем, раньше я не делал очень больших проектов, поэтому не придавал значения важности проверки работы релиз версии на всем этапе разработки. и вот теперь столкнулся с ситуацией — проект большой (около 3М в .rar самописного кода), дебаг-версия работает, как надо, релизная не так, как надо.

__>как бы на распутьи, как малой кровью из этой ситуации выкарабкаться.
__>первым делом включил уровень /w4 ворнингов, с надеждой обнаружить нужное. но нет, ничего значительного.
__>далее попытался проверить код встроенным в VS2013 анализатором кода, но анализатор споткнулся на попытках проанализировать используемые boost-овские файлы и выдал internal error
__>была надежда на psv-студию, но она только под win x64, а у меня стоит win7 x32
__>думал попробовать вручную — сделать ассерты для релизной версии, но хорошего решения, не засоряющего код, пока не нашел (у меня код, относящийся к бизнес-логике, работает только с boost и cereal, а код gui — на qt. выбросить ассерт через std::excеption (а как по-другому, чтоб универсально?) оказалось в qt проблематичным (qt, по-видимому, не очень дружит с c++ exception-ами)

__>вот и непонятно, в какую сторону двигаться


Попробуй разные уровние оптимизации в release.
Re: debug - release problem
От: Videoman Россия https://hts.tv/
Дата: 12.08.16 12:38
Оценка: +1
Здравствуйте, _hum_, Вы писали:

__>вот и непонятно, в какую сторону двигаться


1. Попытайтесь комментарить подозрительные функции и смотреть будет ли проявляться глюки, пытаясь локализовать проблему постепенно сужая облать до одной функции/класса
2. Если дебаг работает нормально, не "проезжая" по памяти, то следующая наиболее вероятная проблема, это что-то где-то не инициализировано. Проинициализируте везде, где можно, все переменные и буфера нулями. 90% что баг в этом.
Re[8]: debug - release problem [solved]
От: _hum_ Беларусь  
Дата: 13.08.16 14:59
Оценка: :)
Здравствуйте, b0r3d0m, Вы писали:

__>>не понял вас, что вы хотели этим сказать.


B>Делаете #undef перед включением cassert и, вот это да, ассерты работают и в релизе.


это не совсем корректно делать, потому что реализация самого ассерта "implementation defined", а значит, может быть не рассчитана на работу в условиях релиза
Re[9]: debug - release problem [solved]
От: b0r3d0m  
Дата: 13.08.16 15:05
Оценка: +1
__>это не совсем корректно делать
Да ну?

__>потому что реализация самого ассерта "implementation defined"

Кто сказал?

ISO/IEC 9899:TC3

7.2 Diagnostics <assert.h>
1 The header <assert.h> defines the assert macro and refers to another macro,
NDEBUG
which is not defined by <assert.h>. If NDEBUG is defined as a macro name at the
point in the source file where <assert.h> is included, the assert macro is defined
simply as
#define assert(ignore) ((void)0)
The assert macro is redefined according to the current state of NDEBUG each time that
<assert.h> is included

[...]

7.2.1.1 The assert macro
Synopsis
1 #include <assert.h>
void assert(scalar expression);
Description
2 The assert macro puts diagnostic tests into programs; it expands to a void expression.
When it is executed, if expression (which shall have a scalar type) is false (that is,
compares equal to 0), the assert macro writes information about the particular call that
failed (including the text of the argument, the name of the source file, the source line
number, and the name of the enclosing function — the latter are respectively the values of
the preprocessing macros __FILE_ _ and __LINE_ _ and of the identifier
__func_ _) on the standard error stream in an implementation-defined format. 165) It
then calls the abort function.


__>а значит, может быть не рассчитана на работу в условиях релиза

Стандарт вообще не оперирует такими словами, как Release и Debug. Самое ближайшее, что он знает, это макрос NDEBUG.
Re[5]: debug - release problem
От: landerhigh Пират  
Дата: 18.08.16 14:52
Оценка: :)
Здравствуйте, _hum_, Вы писали:

L>>Примитивнешие же юнит-тесты, прогоняющие логику в релизе, отловили бы эту мину еще год назад, когда ее еще только заложили

__>ну наконец-то, а то я уже стал волноваться

Я просто мимокрокодил
www.blinnov.com
debug - release problem [solved]
От: _hum_ Беларусь  
Дата: 12.08.16 11:55
Оценка:
в общем, раньше я не делал очень больших проектов, поэтому не придавал значения важности проверки работы релиз версии на всем этапе разработки. и вот теперь столкнулся с ситуацией — проект большой (около 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 версия, что позволило легко обнаружить место и саму пробелему простым дебагингом.

всем спасибо за советы. приму на будущее к сведению
Отредактировано 12.08.2016 21:09 _hum_ . Предыдущая версия . Еще …
Отредактировано 12.08.2016 18:18 _hum_ . Предыдущая версия .
Re: debug - release problem
От: Nuzhny Россия https://github.com/Nuzhny007
Дата: 12.08.16 12:06
Оценка:
Здравствуйте, _hum_, Вы писали:

__>вот и непонятно, в какую сторону двигаться


1. Логи.
2. Если всё такое кроссплатформенное, то Linux.
Re[2]: debug - release problem
От: _hum_ Беларусь  
Дата: 12.08.16 12:25
Оценка:
Здравствуйте, kov_serg, Вы писали:

_>Попробуй разные уровние оптимизации в release.


и как это поможет, даже если я увижу, что при каком-то уровне работать начинает нормально — как я найду ошибку в проге (ведь, наверняка, она есть)?
Re[2]: debug - release problem
От: _hum_ Беларусь  
Дата: 12.08.16 12:28
Оценка:
Здравствуйте, Nuzhny, Вы писали:

N>Здравствуйте, _hum_, Вы писали:


__>>вот и непонятно, в какую сторону двигаться


N>1. Логи.


и как это по-хорошему огранизтвать, чтоб н едублировать и assert в дебаг-версии и логирвоание? и оно должно включаться макросами, или в самом приложении (чтобы пользователь имел возможность включать логирование, чтобы отправлять разработчику)?

N>2. Если всё такое кроссплатформенное, то Linux.


а при чем тут Ос? вроде, проблема кросс-платформенная
Re[2]: debug - release problem
От: _hum_ Беларусь  
Дата: 12.08.16 13:02
Оценка:
Здравствуйте, Videoman, Вы писали:

V>Здравствуйте, _hum_, Вы писали:


__>>вот и непонятно, в какую сторону двигаться


V>1. Попытайтесь комментарить подозрительные функции и смотреть будет ли проявляться глюки, пытаясь локализовать проблему постепенно сужая облать до одной функции/класса


во-первых, функций слишком много, во-вторых, перекомпиляция обычно занимает около 5-10 минут — у просто физически не смогу все возможные варианты проверить

V>2. Если дебаг работает нормально, не "проезжая" по памяти, то следующая наиболее вероятная проблема, это что-то где-то не инициализировано. Проинициализируте везде, где можно, все переменные и буфера нулями. 90% что баг в этом.


но ведь w4 не ругался (обычно он ругается на неинициализированные).
Re[3]: debug - release problem
От: Videoman Россия https://hts.tv/
Дата: 12.08.16 13:28
Оценка:
Здравствуйте, _hum_, Вы писали:

__> во-первых, функций слишком много, во-вторых, перекомпиляция обычно занимает около 5-10 минут — у просто физически не смогу все возможные варианты проверить

Используйте градиентный спуск, метод деления пополам (примерно), придется компилировать.

__>но ведь w4 не ругался (обычно он ругается на неинициализированные).

Только на самые простые случаи. Сомневаюсь что он проверяет поля классов и все буфера и указатели.

дебаг-версия работает, как надо, релизная не так, как надо

что изменяется то хоть можно узнать ?
Re: debug - release problem
От: lpd Черногория  
Дата: 12.08.16 13:40
Оценка:
Здравствуйте, _hum_, Вы писали:

__> в общем, раньше я не делал очень больших проектов, поэтому не придавал значения важности проверки работы релиз версии на всем этапе разработки. и вот теперь столкнулся с ситуацией — проект большой (около 3М в .rar самописного кода), дебаг-версия работает, как надо, релизная не так, как надо.


__>вот и непонятно, в какую сторону двигаться


Такое случается если где-то портишь память. В debug-версии там хранится отладочная информация, а в release по этому адресу могут быть необходимые данные.
Привело к этому, скорее всего, какое-то недавнее изменение, — иначе перезапись памяти бы проявилась ранее.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Отредактировано 12.08.2016 13:44 lpd . Предыдущая версия . Еще …
Отредактировано 12.08.2016 13:44 lpd . Предыдущая версия .
Отредактировано 12.08.2016 13:43 lpd . Предыдущая версия .
Отредактировано 12.08.2016 13:41 lpd . Предыдущая версия .
Re[3]: debug - release problem
От: tdiff  
Дата: 12.08.16 13:53
Оценка:
Здравствуйте, _hum_, Вы писали:

__>Здравствуйте, kov_serg, Вы писали:


_>>Попробуй разные уровние оптимизации в release.


__>и как это поможет, даже если я увижу, что при каком-то уровне работать начинает нормально — как я найду ошибку в проге (ведь, наверняка, она есть)?


Например, непадающая программа, собранная в релизе с выключенной оптимизацией, это гораздо лучше, чем объяснять заказчику, что нет вообще ничего.
Re[4]: debug - release problem
От: _hum_ Беларусь  
Дата: 12.08.16 14:13
Оценка:
Здравствуйте, tdiff, Вы писали:

T>Здравствуйте, _hum_, Вы писали:


__>>Здравствуйте, kov_serg, Вы писали:


_>>>Попробуй разные уровние оптимизации в release.


__>>и как это поможет, даже если я увижу, что при каком-то уровне работать начинает нормально — как я найду ошибку в проге (ведь, наверняка, она есть)?


T>Например, непадающая программа, собранная в релизе с выключенной оптимизацией, это гораздо лучше, чем объяснять заказчику, что нет вообще ничего.


во-первых, мне скорость критична (поэтому оптимизацию снижать — это плохо), во-вторых, это работа не из ряда "ради галочки", ну и в-третьих, самое важное — это же означает, что возможно, в проге есть ошибка, и как ее отдавать, зная, что она там?
Re[4]: debug - release problem
От: _hum_ Беларусь  
Дата: 12.08.16 14:17
Оценка:
Здравствуйте, Videoman, Вы писали:

V>Здравствуйте, _hum_, Вы писали:


__>> во-первых, функций слишком много, во-вторых, перекомпиляция обычно занимает около 5-10 минут — у просто физически не смогу все возможные варианты проверить

V>Используйте градиентный спуск, метод деления пополам (примерно), придется компилировать.

это "сферический конь в вакууме" (кстати, как вы градиент-то искать будете. или имели в виду покоординатный?

__>>но ведь w4 не ругался (обычно он ругается на неинициализированные).

V>Только на самые простые случаи. Сомневаюсь что он проверяет поля классов и все буфера и указатели.

вроде, проверяет. по кр. мере, при попытке использования неинициализированной переменной он выдавал исключение.

V>

V>дебаг-версия работает, как надо, релизная не так, как надо

V>что изменяется то хоть можно узнать ?

есть модель, есть эмулятор работы с ней. так вот в релизе эмулятор говорит, что модель невалидна

[да-да, знаю, что можно повводить коды невалидности и отслеживать, что да как. но это все-таки серьезный кусок работы, ис перва хотелось бы выслушать другие варианты решения, чтоб уже с чистой совестью закасывать рукава]
Re[5]: debug - release problem
От: tdiff  
Дата: 12.08.16 14:18
Оценка:
Здравствуйте, _hum_, Вы писали:

__> во-первых, мне скорость критична (поэтому оптимизацию снижать — это плохо), во-вторых, это работа не из ряда "ради галочки", ну и в-третьих, самое важное — это же означает, что возможно, в проге есть ошибка, и как ее отдавать, зная, что она там?


смотря по обстоятельствам
Re[2]: debug - release problem
От: _hum_ Беларусь  
Дата: 12.08.16 14:19
Оценка:
Здравствуйте, lpd, Вы писали:

lpd>Здравствуйте, _hum_, Вы писали:


__>> в общем, раньше я не делал очень больших проектов, поэтому не придавал значения важности проверки работы релиз версии на всем этапе разработки. и вот теперь столкнулся с ситуацией — проект большой (около 3М в .rar самописного кода), дебаг-версия работает, как надо, релизная не так, как надо.


__>>вот и непонятно, в какую сторону двигаться


lpd>Такое случается если где-то портишь память. В debug-версии там хранится отладочная информация, а в release по этому адресу могут быть необходимые данные.

lpd>Привело к этому, скорее всего, какое-то недавнее изменение, — иначе перезапись памяти бы проявилась ранее.

мне тоже так кажется. вот как такую гадость отловить... раньше помогал анализатор кода, но сейчас он, видите, не способен переварить проект
может, есть какие-то сторонние анализаторы именно такой проблемы?
Re[5]: debug - release problem
От: Videoman Россия https://hts.tv/
Дата: 12.08.16 14:28
Оценка:
Здравствуйте, _hum_, Вы писали:

__> это "сферический конь в вакууме" (кстати, как вы градиент-то искать будете. или имели в виду покоординатный?

ну придумайте метрику какую-нибудь

__>есть модель, есть эмулятор работы с ней. так вот в релизе эмулятор говорит, что модель невалидна

Эмулятор конечно же "черный ящик". Упростить модель можно? Пустая модель тоже невалидна?
А многопоточность есть?
Re[6]: debug - release problem
От: _hum_ Беларусь  
Дата: 12.08.16 14:59
Оценка:
Здравствуйте, Videoman, Вы писали:

V>Здравствуйте, _hum_, Вы писали:


__>>есть модель, есть эмулятор работы с ней. так вот в релизе эмулятор говорит, что модель невалидна

V>Эмулятор конечно же "черный ящик".

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

V>Упростить модель можно? Пустая модель тоже невалидна?


пустая модель невалидна для эмулятора по определению

V>А многопоточность есть?


есть, но чисто для gui (ею можно пренебречь)
Re: debug - release problem
От: Evgeny.Panasyuk Россия  
Дата: 12.08.16 15:13
Оценка:
Здравствуйте, _hum_, Вы писали:

__>вот и непонятно, в какую сторону двигаться


Как вариант можешь выключить оптимизацию в release — если результат станет "нормальным", то можешь постепенно включать/выключать оптимизацию в отдельных translation units по методу divide and conquer. Так за логарифмическое число шагов локализуешь хотя бы один проблемный TU. Далее например можешь включать/выключать оптимизацию на уровне функций.
Re: debug - release problem
От: B0FEE664  
Дата: 12.08.16 17:06
Оценка:
Здравствуйте, _hum_, Вы писали:

__> в общем, раньше я не делал очень больших проектов, поэтому не придавал значения важности проверки работы релиз версии на всем этапе разработки. и вот теперь столкнулся с ситуацией — проект большой (около 3М в .rar самописного кода), дебаг-версия работает, как надо, релизная не так, как надо.


"релизная не так, как надо" — это как? Не тот результат? Падает? Ещё что?
И каждый день — без права на ошибку...
Re[2]: debug - release problem
От: _hum_ Беларусь  
Дата: 12.08.16 18:20
Оценка:
Здравствуйте, Videoman, Вы писали:

V>Здравствуйте, _hum_, Вы писали:


__>>вот и непонятно, в какую сторону двигаться


V>2. Если дебаг работает нормально, не "проезжая" по памяти, то следующая наиболее вероятная проблема, это что-то где-то не инициализировано. Проинициализируте везде, где можно, все переменные и буфера нулями. 90% что баг в этом.


вы были правы — проблема крылась в использовании неинициализированных переменных
Re[2]: debug - release problem
От: _hum_ Беларусь  
Дата: 12.08.16 18:20
Оценка:
Здравствуйте, Pzz, Вы писали:

Pzz>Здравствуйте, _hum_, Вы писали:


__>>как бы на распутьи, как малой кровью из этой ситуации выкарабкаться.


Pzz>А никак. Отлаживать заново.


Pzz>Вообще никогда не понимал, зачем нужна Debug-сборка. Вместо одной программы приходится тестировать и отлаживать две.


проблема быстро решилась после того, как настройка среды привела к проявлению этой проблемы и в дебаг версии (это к вопросу о полезности дебагинга)
Re[2]: debug - release problem
От: _hum_ Беларусь  
Дата: 12.08.16 18:22
Оценка:
Здравствуйте, lpd, Вы писали:

lpd>Здравствуйте, _hum_, Вы писали:


__>> в общем, раньше я не делал очень больших проектов, поэтому не придавал значения важности проверки работы релиз версии на всем этапе разработки. и вот теперь столкнулся с ситуацией — проект большой (около 3М в .rar самописного кода), дебаг-версия работает, как надо, релизная не так, как надо.


__>>вот и непонятно, в какую сторону двигаться


lpd>Такое случается если где-то портишь память. В debug-версии там хранится отладочная информация, а в release по этому адресу могут быть необходимые данные.

lpd>Привело к этому, скорее всего, какое-то недавнее изменение, — иначе перезапись памяти бы проявилась ранее.

нет, если бы был выход за пределы, то студия бы обнаружила в дебаг версии (потому что она такие проверки делает). а вот с использованием неинициализированных переменных сложнее. именно этот случай у меня и вылез.
Re[2]: debug - release problem
От: _hum_ Беларусь  
Дата: 12.08.16 18:24
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Здравствуйте, _hum_, Вы писали:


__>>вот и непонятно, в какую сторону двигаться


EP>Как вариант можешь выключить оптимизацию в release — если результат станет "нормальным", то можешь постепенно включать/выключать оптимизацию в отдельных translation units по методу divide and conquer. Так за логарифмическое число шагов локализуешь хотя бы один проблемный TU. Далее например можешь включать/выключать оптимизацию на уровне функций.


я почему-то думал, что вы опять начнете про юнит-тестирование говорить
Re[2]: debug - release problem
От: _hum_ Беларусь  
Дата: 12.08.16 18:25
Оценка:
Здравствуйте, 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. Дальше становился все хуже и хуже. В последнем моем проекте толку от него не было, приложение фактически не работало под ним. Тем не менее попробовать можно — вдруг тебе повезет больше.


спасибо. приму к сведению на будущее. а дело было в "использование неинициализированных переменных/полей " (студия это не может напрямую обнаружить, но специально делает разное заполнение в дебаг и релиз версии начальные значения, чтобы хоть как-то указать на то, что что-то не так )
Re[2]: debug - release problem
От: _hum_ Беларусь  
Дата: 12.08.16 18:26
Оценка:
Здравствуйте, Lexey, Вы писали:

L>Здравствуйте, _hum_, Вы писали:


__>>вот и непонятно, в какую сторону двигаться


L>Может еще не совсем актуальность потеряло:

L>http://rsdn.org/article/vcpp/survrls.xml
Автор(ы): Dr. Joseph M. Newcomer
Дата: 18.06.2001
Статья посвящена проблемам перехода с Debug-версии на Release-версию. Рассматриваются
типичные ошибки, которые могут не проявляться в отладочной версии, но проявляются в финальной.
Обсуждается вопрос "ошибок компилятора" и вопросы необходимости оптимизации и ее побочные эффекты.
В последней редакции добавлен раздел посвященный проблеме совместимости динамических библиотек.


L>)


L>P.S. Иногда еще помогает сборка с STL с поддержкой отладочных итераторов. Я с их помощью как-то поймал лютый баг с расстрелом памяти из-за "висящей" ссылки.


спасибо. интересно будет почитать!
Re[2]: debug - release problem
От: _hum_ Беларусь  
Дата: 12.08.16 18:27
Оценка:
Здравствуйте, B0FEE664, Вы писали:

BFE>Здравствуйте, _hum_, Вы писали:


__>> в общем, раньше я не делал очень больших проектов, поэтому не придавал значения важности проверки работы релиз версии на всем этапе разработки. и вот теперь столкнулся с ситуацией — проект большой (около 3М в .rar самописного кода), дебаг-версия работает, как надо, релизная не так, как надо.


BFE>"релизная не так, как надо" — это как? Не тот результат? Падает? Ещё что?


самый худший вариант — работает не так, как ожидалось, но не не падает.
Re[3]: debug - release problem
От: Evgeny.Panasyuk Россия  
Дата: 12.08.16 18:32
Оценка:
Здравствуйте, _hum_, Вы писали:

__>>>вот и непонятно, в какую сторону двигаться

EP>>Как вариант можешь выключить оптимизацию в release — если результат станет "нормальным", то можешь постепенно включать/выключать оптимизацию в отдельных translation units по методу divide and conquer. Так за логарифмическое число шагов локализуешь хотя бы один проблемный TU. Далее например можешь включать/выключать оптимизацию на уровне функций.
__> я почему-то думал, что вы опять начнете про юнит-тестирование говорить

В контексте чего я про него говорил?
Re[2]: debug - release problem
От: T4r4sB Россия  
Дата: 12.08.16 18:33
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Здравствуйте, _hum_, Вы писали:


PD>Думаю, что с весьма приличной вероятностью у тебя ошибки доступа к памяти (выход за пределы выделенного блока в куче ("расстрел кучи"), использование неинициализированных переменных/полей и т.д.)


Скучные причины какие-то у вас. Весело, когда ничего не висит и всё инициализировано, но релиз всё равно глючит. А в асмовыхлопе — нечто, не соответствующее никакому валидному коду. 2003я студия отжигала знатно, да...
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Re: debug - release problem [solved]
От: VTT http://vtt.to
Дата: 12.08.16 18:39
Оценка:
Сдается мне, что проблема не столько оттого, что проект большой (3 мб рар в выражениях — это сколько?), а оттого, что он монолитный и по частям его работоспособность не проверить.
И вообще, что значит "не так, как надо"?

/w4 полезно держать включенным постоянно.

Если статические анализаторы не помогают, то имеет смысл использовать динамические visual leak detector, app verifier, встроенные рантайм проверки.

А что за проблемы с ассертами? Компилируйте с _DEBUG DEBUG и оптимизациями.
Говорить дальше не было нужды. Как и все космонавты, капитан Нортон не испытывал особого доверия к явлениям, внешне слишком заманчивым.
Re[4]: debug - release problem
От: _hum_ Беларусь  
Дата: 12.08.16 18:57
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Здравствуйте, _hum_, Вы писали:


__>>>>вот и непонятно, в какую сторону двигаться

EP>>>Как вариант можешь выключить оптимизацию в release — если результат станет "нормальным", то можешь постепенно включать/выключать оптимизацию в отдельных translation units по методу divide and conquer. Так за логарифмическое число шагов локализуешь хотя бы один проблемный TU. Далее например можешь включать/выключать оптимизацию на уровне функций.
__>> я почему-то думал, что вы опять начнете про юнит-тестирование говорить

EP>В контексте чего я про него говорил?


ааа. сори, это я вас с Stanislav V. Zudin перепутал (тоже ник — фамилия, имя)
Re[3]: debug - release problem
От: _hum_ Беларусь  
Дата: 12.08.16 19:01
Оценка:
Здравствуйте, T4r4sB, Вы писали:

TB>Здравствуйте, Pavel Dvorkin, Вы писали:


PD>>Здравствуйте, _hum_, Вы писали:


PD>>Думаю, что с весьма приличной вероятностью у тебя ошибки доступа к памяти (выход за пределы выделенного блока в куче ("расстрел кучи"), использование неинициализированных переменных/полей и т.д.)


TB>Скучные причины какие-то у вас. Весело, когда ничего не висит и всё инициализировано, но релиз всё равно глючит. А в асмовыхлопе — нечто, не соответствующее никакому валидному коду. 2003я студия отжигала знатно, да...


тьфу-тьфу-тьфу такие ужасы. но вообще (из рекомендованной статьи "Как пережить release-версию"
Автор(ы): Dr. Joseph M. Newcomer
Дата: 18.06.2001
Статья посвящена проблемам перехода с Debug-версии на Release-версию. Рассматриваются
типичные ошибки, которые могут не проявляться в отладочной версии, но проявляются в финальной.
Обсуждается вопрос "ошибок компилятора" и вопросы необходимости оптимизации и ее побочные эффекты.
В последней редакции добавлен раздел посвященный проблеме совместимости динамических библиотек.
):

"Ошибки" компилятора

Оптимизирующий компилятор делает различные предположения о той сущности, с которой он имеет дело. Проблема в том, что взгляд компилятора на реальность целиком базируется на ряде предположений, все из которых программист на C может очень легко нарушить. Результатом этой неправильной интерпретации реальности будет то, что вы можете обмануть компилятор, заставив его генерировать "плохой код". В действительности, он не плохой — это совершенно правильный код, при условии, что предположения компилятора были верны. Если вы явно или неявно лгали компилятору, то с него взятки гладки.

Re[2]: debug - release problem [solved]
От: _hum_ Беларусь  
Дата: 12.08.16 19:09
Оценка:
Здравствуйте, VTT, Вы писали:

VTT>Сдается мне, что проблема не столько оттого, что проект большой (3 мб рар в выражениях — это сколько?), а оттого, что он монолитный и по частям его работоспособность не проверить.

нет. проблема именно в объемности (он ен монолитный). 3M rar — это столько кода, что если заархивировать в рар (с настройками по умолчанию), то получится 3М [просто это, имхо, наиболее адекватная оценка объема информации в коде. все остальные оценки наподобие — число строк, число слов и проч. — очень сильно зависят от стилистики]

VTT>И вообще, что значит "не так, как надо"?


писал выше — работает не так, как ожидалось, когда "2+2 = 5"

VTT>/w4 полезно держать включенным постоянно.


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

VTT>Если статические анализаторы не помогают, то имеет смысл использовать динамические visual leak detector, app verifier, встроенные рантайм проверки.


статические как раз-таки помогли бы. тут проблема найти рабочий

VTT>А что за проблемы с ассертами? Компилируйте с _DEBUG DEBUG и оптимизациями.


ассерты в дебаг версии не работают. надо писать свои. вот и проблема, как лучше это сделать.
Re[4]: debug - release problem
От: T4r4sB Россия  
Дата: 12.08.16 19:22
Оценка:
Здравствуйте, _hum_, Вы писали:

__>

__>"Ошибки" компилятора


Дадада, я читал, что типа такого не бывает, что компиль лажает. Долго думал, где же я ошибся, только время зря потратил на поиск своей ошибки. Так вот не ошибался я. Компиль лажал.
Пруф могу найти.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Re[5]: debug - release problem
От: _hum_ Беларусь  
Дата: 12.08.16 19:29
Оценка:
Здравствуйте, T4r4sB, Вы писали:

TB>Здравствуйте, _hum_, Вы писали:


__>>

__>>"Ошибки" компилятора


TB>Дадада, я читал, что типа такого не бывает, что компиль лажает. Долго думал, где же я ошибся, только время зря потратил на поиск своей ошибки. Так вот не ошибался я. Компиль лажал.

TB>Пруф могу найти.

в смысле, майкрософт признал ошибку?
Re[3]: debug - release problem [solved]
От: VTT http://vtt.to
Дата: 12.08.16 20:03
Оценка:
По-моему число выражений (statements) как раз очень хорошо показывает реальный объем кода.

__>ой, он так шумит. например, на неиспользованные переменные. а у меня они для отладки остаются. а еще есть унифицированные функции, с общей сигнатурой, но в теле которых могут не использоваться некоторые параметры. и вот он на них тоже ругается.


Можно явно указывать, что они не используются.

__>ассерты в дебаг версии не работают

-_-'
это как так?
даже просто __debugbreak?
Говорить дальше не было нужды. Как и все космонавты, капитан Нортон не испытывал особого доверия к явлениям, внешне слишком заманчивым.
Re[4]: debug - release problem [solved]
От: _hum_ Беларусь  
Дата: 12.08.16 20:49
Оценка:
Здравствуйте, VTT, Вы писали:

VTT>По-моему число выражений (statements) как раз очень хорошо показывает реальный объем кода.


__>>ой, он так шумит. например, на неиспользованные переменные. а у меня они для отладки остаются. а еще есть унифицированные функции, с общей сигнатурой, но в теле которых могут не использоваться некоторые параметры. и вот он на них тоже ругается.



VTT>Можно явно указывать, что они не используются.


как именно?

__>>ассерты в дебаг версии не работают

VTT>-_-'
VTT>это как так?

так:

cppreference/assert

#ifdef NDEBUG

#define assert(condition) ((void)0)
#else
#define assert(condition) /*implementation defined*/
#endif



VTT>даже просто __debugbreak?


не пользовался
Отредактировано 12.08.2016 20:49 _hum_ . Предыдущая версия .
Re[6]: debug - release problem
От: T4r4sB Россия  
Дата: 12.08.16 20:59
Оценка:
Здравствуйте, _hum_, Вы писали:

__>в смысле, майкрософт признал ошибку?


То есть иначе ты не признаешь, что компиль может генерить лажу?
Асмовыхлоп есть, там просто видно, что компиль посылает в функцию смещение на какуюто фигню, а не на нужный объект.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Re[3]: debug - release problem [solved]
От: Evgeny.Panasyuk Россия  
Дата: 12.08.16 20:59
Оценка:
Здравствуйте, _hum_, Вы писали:

__>нет. проблема именно в объемности (он ен монолитный). 3M rar — это столько кода, что если заархивировать в рар (с настройками по умолчанию), то получится 3М


Сдаётся мне что в твоём случае 3MB это не только исходники но и ещё и какие-то левые бинарники и подобное. Сжатые заголовки Boost'а (при том что там практически всё header-only) имеют размер того же порядка.
Re[7]: debug - release problem
От: _hum_ Беларусь  
Дата: 12.08.16 21:05
Оценка:
Здравствуйте, T4r4sB, Вы писали:

TB>Здравствуйте, _hum_, Вы писали:


__>>в смысле, майкрософт признал ошибку?


TB>То есть иначе ты не признаешь, что компиль может генерить лажу?

TB>Асмовыхлоп есть, там просто видно, что компиль посылает в функцию смещение на какуюто фигню, а не на нужный объект.

ну, иначе просто ваше слово против слова специалистов, что ошибки компилятора (тем более такие серьезные, как вы описали), крайняя редкость
Re[4]: debug - release problem [solved]
От: _hum_ Беларусь  
Дата: 12.08.16 21:06
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Здравствуйте, _hum_, Вы писали:


__>>нет. проблема именно в объемности (он ен монолитный). 3M rar — это столько кода, что если заархивировать в рар (с настройками по умолчанию), то получится 3М


EP>Сдаётся мне что в твоём случае 3MB это не только исходники но и ещё и какие-то левые бинарники и подобное. Сжатые заголовки Boost'а (при том что там практически всё header-only) имеют размер того же порядка.


да, точно там затесалась папка с доками по проекту. без нее — 1.2 М [хидеры сторонних библиотек хранятся отдельно от проекта]
Re[5]: debug - release problem [solved]
От: Evgeny.Panasyuk Россия  
Дата: 12.08.16 21:18
Оценка:
Здравствуйте, _hum_, Вы писали:

EP>>Сдаётся мне что в твоём случае 3MB это не только исходники но и ещё и какие-то левые бинарники и подобное. Сжатые заголовки Boost'а (при том что там практически всё header-only) имеют размер того же порядка.

__>да, точно там затесалась папка с доками по проекту. без нее — 1.2 М [хидеры сторонних библиотек хранятся отдельно от проекта]

Не не не Девид Блейн, мегабайт это у Eigen исходники столько весят.
Найди все исходники по расширению, скопируй в отдельную папку и потом измерь.
Re[8]: debug - release problem
От: Evgeny.Panasyuk Россия  
Дата: 12.08.16 21:32
Оценка:
Здравствуйте, _hum_, Вы писали:

__>>>в смысле, майкрософт признал ошибку?

TB>>То есть иначе ты не признаешь, что компиль может генерить лажу?
TB>>Асмовыхлоп есть, там просто видно, что компиль посылает в функцию смещение на какуюто фигню, а не на нужный объект.
__>ну, иначе просто ваше слово против слова специалистов, что ошибки компилятора (тем более такие серьезные, как вы описали), крайняя редкость

"Крайняя редкость" не значит что не встречается.
https://connect.microsoft.com/VisualStudio/feedback/details/855237/vs2012-and-vs2013-floating-point-move-bug
Re[6]: debug - release problem [solved]
От: _hum_ Беларусь  
Дата: 12.08.16 21:47
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Здравствуйте, _hum_, Вы писали:


EP>>>Сдаётся мне что в твоём случае 3MB это не только исходники но и ещё и какие-то левые бинарники и подобное. Сжатые заголовки Boost'а (при том что там практически всё header-only) имеют размер того же порядка.

__>>да, точно там затесалась папка с доками по проекту. без нее — 1.2 М [хидеры сторонних библиотек хранятся отдельно от проекта]

EP>Не не не Девид Блейн, мегабайт это у Eigen исходники столько весят.

EP>Найди все исходники по расширению, скопируй в отдельную папку и потом измерь.

может, архиватор плохо архивирует...но вроде ничего не поменялось:
  pics





итого:




в архиве: 1 110 878 B
Re[7]: debug - release problem [solved]
От: Evgeny.Panasyuk Россия  
Дата: 12.08.16 21:52
Оценка:
Здравствуйте, _hum_, Вы писали:

__>может, архиватор плохо архивирует...но вроде ничего не поменялось:


Например сколько строк в файле BasicLevel_ControlUnit.cpp? Ты его сам писал или всё-таки сгенерировал?
Re[8]: debug - release problem [solved]
От: _hum_ Беларусь  
Дата: 12.08.16 21:54
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Здравствуйте, _hum_, Вы писали:


__>>может, архиватор плохо архивирует...но вроде ничего не поменялось:


EP>Например сколько строк в файле BasicLevel_ControlUnit.cpp? Ты его сам писал или всё-таки сгенерировал?


17945

да, это все вручную писано-переписано
Re[8]: debug - release problem
От: T4r4sB Россия  
Дата: 13.08.16 10:21
Оценка:
Здравствуйте, _hum_, Вы писали:


__>ну, иначе просто ваше слово против слова специалистов, что ошибки компилятора (тем более такие серьезные, как вы описали), крайняя редкость


Я понял, тебе не интересно почитать про конкретные детали моего случая. Тебе хочется самоутвердиться. У тебя нет нормального любопытства, только желание тупо возвыситься.
Досвиданья.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Re[6]: debug - release problem
От: b0r3d0m  
Дата: 13.08.16 11:09
Оценка:
__>в смысле, майкрософт признал ошибку?
А чему вы так удивляетесь?
Мне, например, хорошо запомнился баг с возвращением float'ов из switch-case блоков в MSVC-11.0. Ловил целый день.
Баг-репорты тут и тут.
Re[3]: debug - release problem [solved]
От: b0r3d0m  
Дата: 13.08.16 11:11
Оценка:
__>ассерты в дебаг версии не работают
Чёт не понял. Не работают или не срабатывают?
Re[9]: debug - release problem
От: _hum_ Беларусь  
Дата: 13.08.16 11:45
Оценка:
Здравствуйте, T4r4sB, Вы писали:

TB>Здравствуйте, _hum_, Вы писали:



__>>ну, иначе просто ваше слово против слова специалистов, что ошибки компилятора (тем более такие серьезные, как вы описали), крайняя редкость


TB>Я понял, тебе не интересно почитать про конкретные детали моего случая. Тебе хочется самоутвердиться. У тебя нет нормального любопытства, только желание тупо возвыситься.

TB>Досвиданья.

T4r4sB, вы меня огорошили таким ответом. вы же научный сотрудник, насколько я понимаю. вам ли не знать, что всякое высказывание нужно подвергать разумному сомнению. вот я его и высказал (ни коим образом не собираясь тем самым как-то принизить вас как специалиста), ожидая услышать какие-то подтверждения вашим словам (например, как сделал Evgeny.Panasyuk , приведя ссылки на зафиксированные баги компилятора).

на всякий случай, прошу прощения, если мои слова вас все-таки задели.
Re[4]: debug - release problem
От: _hum_ Беларусь  
Дата: 13.08.16 11:47
Оценка:
Здравствуйте, Videoman, Вы писали:

V>Здравствуйте, _hum_, Вы писали:


__>>вы были правы — проблема крылась в использовании неинициализированных переменных


V>О-о-о! Очень рад за вас . Но это вам звоночек. Следующий раз так не повезет. Лучше пишите сразу нормально, с инициализацией, ассертами и юнит-тестами.


я все время пишу с инициализациями, просто помимо написания кода есть еще и переписывание. и вот на этом этапе уследить уже за такими вещами становится сложнее
Re[4]: debug - release problem [solved]
От: _hum_ Беларусь  
Дата: 13.08.16 11:54
Оценка:
Здравствуйте, b0r3d0m, Вы писали:

__>>ассерты в дебаг версии не работают

B>Чёт не понял. Не работают или не срабатывают?

там просто пропустил "не" — в "не дебаг версии" ассерты не работают
Re[5]: debug - release problem [solved]
От: b0r3d0m  
Дата: 13.08.16 12:06
Оценка:
__>>>ассерты в дебаг версии не работают
B>>Чёт не понял. Не работают или не срабатывают?

__>там просто пропустил "не" — в "не дебаг версии" ассерты не работают


#undef NDEBUG
#include <cassert>


???
Re[6]: debug - release problem [solved]
От: _hum_ Беларусь  
Дата: 13.08.16 13:18
Оценка:
Здравствуйте, b0r3d0m, Вы писали:

__>>>>ассерты в дебаг версии не работают

B>>>Чёт не понял. Не работают или не срабатывают?

__>>там просто пропустил "не" — в "не дебаг версии" ассерты не работают


B>
B>#undef NDEBUG
B>#include <cassert>
B>


B>???


не понял вас, что вы хотели этим сказать.


Standard library header <cassert>

C++

Standard Library header files


This header was originally in the C standard library as <assert.h>.

This header is part of the error handling library.

Re[10]: debug - release problem
От: T4r4sB Россия  
Дата: 13.08.16 13:41
Оценка:
Здравствуйте, _hum_, Вы писали:

__>ожидая услышать какие-то подтверждения вашим словам


Вопрос в том, что ты считаешь подтверждением. Если тебе интересно именно обсуждение моего случая с выкладками асмовыхлопа, это одно. А если тебе это неинтересно, тебе нужны лишь официальные документы, а без них ты предпочитаешь считать, что это я напортачил — ну считай дальше.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Re[7]: debug - release problem [solved]
От: b0r3d0m  
Дата: 13.08.16 14:52
Оценка:
__>не понял вас, что вы хотели этим сказать.

Делаете #undef перед включением cassert и, вот это да, ассерты работают и в релизе.
Re[11]: debug - release problem
От: _hum_ Беларусь  
Дата: 13.08.16 14:57
Оценка:
Здравствуйте, T4r4sB, Вы писали:

TB>Здравствуйте, _hum_, Вы писали:


__>>ожидая услышать какие-то подтверждения вашим словам


TB>Вопрос в том, что ты считаешь подтверждением. Если тебе интересно именно обсуждение моего случая с выкладками асмовыхлопа, это одно. А если тебе это неинтересно, тебе нужны лишь официальные документы, а без них ты предпочитаешь считать, что это я напортачил — ну считай дальше.


ну, смотрите, я читаю статью, написанную разработчиком компиляторов с 30-летним опытом, в которой говорится, что ошибки компилятора сами по себе очень редки, что в подавляющем большинстве случаев все равно вина за программистом.
тут вы говорите, что у вас был именно такой случай. вот я и высказал сомнение (я же вас лично не знаю, насколько вы компетентны в данной области). технические детали мне скорее всего будут непонятны (ибо я в низкоуровневом программировании не силен), потому ожидалось просто подтверждение того, что такие случаи не такая уж и редкость у новых компиляторов (например, через отсылку на баг-фиксы того же майкросовфт), или какое-то обоснование роста вероятности таких ошибок (например, из-за роста сложности компиляторов и ограниченности возможностей их автоматической проверки). только и всего. ничего личного (я вас как раз наоборот ценю за аналитический ум, хоть вы порой и очень категоричны )
Re[12]: debug - release problem
От: T4r4sB Россия  
Дата: 13.08.16 15:06
Оценка:
Здравствуйте, _hum_, Вы писали:


__>ну, смотрите, я читаю статью, написанную разработчиком компиляторов с 30-летним опытом, в которой говорится, что ошибки компилятора сами по себе очень редки, что в подавляющем большинстве случаев все равно вина за программистом.


Ну ему виднее, ага.

__>технические детали мне скорее всего будут непонятны (ибо я в низкоуровневом программировании не силен)


Жаль. Там асмто достаточно знать на уровне "куда указывает есп, и что сидит в еах".

>, потому ожидалось просто подтверждение того, что такие случаи не такая уж и редкость у новых компиляторов


У старых тоже. В обсуждении ещё есть подтверждение от других людей, что они сталкивались. Ну и ещё поверь на слово, что мой начальник вообще не впечатлился моим рассказом о баге в МСВЦ2003, сказал "ачётакого я вообще им 30 репортов послал уже".
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Re[10]: debug - release problem [solved]
От: _hum_ Беларусь  
Дата: 13.08.16 15:40
Оценка:
Здравствуйте, b0r3d0m, Вы писали:

__>>это не совсем корректно делать

B>Да ну?

__>>потому что реализация самого ассерта "implementation defined"

B>Кто сказал?

  text
B>ISO/IEC 9899:TC3
B>

B>7.2 Diagnostics <assert.h>
B>1 The header <assert.h> defines the assert macro and refers to another macro,
B>NDEBUG
B>which is not defined by <assert.h>. If NDEBUG is defined as a macro name at the
B>point in the source file where <assert.h> is included, the assert macro is defined
B>simply as
B>#define assert(ignore) ((void)0)
B>The assert macro is redefined according to the current state of NDEBUG each time that
B><assert.h> is included

B>[...]

B>7.2.1.1 The assert macro
B>Synopsis
B>1 #include <assert.h>
B>void assert(scalar expression);
B>Description
B>2 The assert macro puts diagnostic tests into programs; it expands to a void expression.
B>When it is executed, if expression (which shall have a scalar type) is false (that is,
B>compares equal to 0), the assert macro writes information about the particular call that
B>failed (including the text of the argument, the name of the source file, the source line
B>number, and the name of the enclosing function — the latter are respectively the values of
B>the preprocessing macros __FILE_ _ and __LINE_ _ and of the identifier
B>__func_ _) on the standard error stream in an implementation-defined format. 165) It
B>then calls the abort function.



__>>а значит, может быть не рассчитана на работу в условиях релиза

B>Стандарт вообще не оперирует такими словами, как Release и Debug. Самое ближайшее, что он знает, это макрос NDEBUG.

хорошо, согласен, в такой формулировке он должен продолжить работать и в релизе. но! появляется же опасность рассогласованности — библиотеки могут, ориентируясь на NDEBUG, выставлять у себя кучу других макросов для релизной версии, а тут вы берете и в каком-то месте отключаете NDEBUG
Re[11]: debug - release problem [solved]
От: b0r3d0m  
Дата: 13.08.16 15:42
Оценка:
__>хорошо, согласен, в такой формулировке он должен продолжить работать и в релизе. но! появляется же опасность рассогласованности — библиотеки могут, ориентируясь на NDEBUG, выставлять у себя кучу других макросов для релизной версии, а тут вы берете и в каком-то месте отключаете NDEBUG
Ты издеваешься?

#undef NDEBUG
#include <cassert>
#define NDEBUG
Re[13]: debug - release problem
От: _hum_ Беларусь  
Дата: 13.08.16 15:44
Оценка:
Здравствуйте, T4r4sB, Вы писали:

TB>Здравствуйте, _hum_, Вы писали:



>>, потому ожидалось просто подтверждение того, что такие случаи не такая уж и редкость у новых компиляторов


TB>У старых тоже. В обсуждении ещё есть подтверждение от других людей, что они сталкивались. Ну и ещё поверь на слово, что мой начальник вообще не впечатлился моим рассказом о баге в МСВЦ2003, сказал "ачётакого я вообще им 30 репортов послал уже".


то, что у компиляторов есть ошибки — это одно (тут уже куча выкладывалась), но речь же шла немного о другом — об ошибках именно оптимизации (ваш шеф и с такими сталкивался?)
Re[14]: debug - release problem
От: b0r3d0m  
Дата: 13.08.16 15:47
Оценка:
__>то, что у компиляторов есть ошибки — это одно (тут уже куча выкладывалась), но речь же шла немного о другом — об ошибках именно оптимизации (ваш шеф и с такими сталкивался?)
Я тебе даже ссылки рядом привёл, там чётко сказано:

Thanks for the bug report. I confirm this is a bug in whole program optimization (/GL)

Re[12]: debug - release problem [solved]
От: _hum_ Беларусь  
Дата: 13.08.16 15:48
Оценка:
Здравствуйте, b0r3d0m, Вы писали:

__>>хорошо, согласен, в такой формулировке он должен продолжить работать и в релизе. но! появляется же опасность рассогласованности — библиотеки могут, ориентируясь на NDEBUG, выставлять у себя кучу других макросов для релизной версии, а тут вы берете и в каком-то месте отключаете NDEBUG

B>Ты издеваешься?

B>
B>#undef NDEBUG
B>#include <cassert>
B>#define NDEBUG
B>


нет, просто не думал о таком варианте

не знаю, вроде бы как бы вы и правы, но интуиция говорит, что это нехорошо, и может выстрелить в ногу.
Re[13]: debug - release problem [solved]
От: b0r3d0m  
Дата: 13.08.16 15:50
Оценка:
__>не знаю, вроде бы как бы вы и правы, но интуиция говорит, что это нехорошо, и может выстрелить в ногу.
Аргументированно.
Re[15]: debug - release problem
От: _hum_ Беларусь  
Дата: 13.08.16 15:51
Оценка:
Здравствуйте, b0r3d0m, Вы писали:

__>>то, что у компиляторов есть ошибки — это одно (тут уже куча выкладывалась), но речь же шла немного о другом — об ошибках именно оптимизации (ваш шеф и с такими сталкивался?)

B>Я тебе даже ссылки рядом привёл, там чётко сказано:

B>

B>Thanks for the bug report. I confirm this is a bug in whole program optimization (/GL)


я не вам писал. а в контексте того разговора, я просто пытаюсь объяснить, почему у меня возникло сомнение, а не то, что T4r4sB неправ.
Re[14]: debug - release problem [solved]
От: _hum_ Беларусь  
Дата: 13.08.16 15:53
Оценка:
Здравствуйте, b0r3d0m, Вы писали:

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

B>Аргументированно.

я же признал, что де-факто вы правы. но сам так делать не буду, ибо интуиция говорит, что это неправильно.
Re[14]: debug - release problem
От: T4r4sB Россия  
Дата: 13.08.16 16:03
Оценка:
Здравствуйте, _hum_, Вы писали:

__>то, что у компиляторов есть ошибки — это одно (тут уже куча выкладывалась), но речь же шла немного о другом — об ошибках именно оптимизации (ваш шеф и с такими сталкивался?)


Именно про ошибку, проявляющуюся именно в релизе с O2, не с O1.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Re[15]: debug - release problem
От: _hum_ Беларусь  
Дата: 13.08.16 16:08
Оценка:
Здравствуйте, T4r4sB, Вы писали:

TB>Здравствуйте, _hum_, Вы писали:


__>>то, что у компиляторов есть ошибки — это одно (тут уже куча выкладывалась), но речь же шла немного о другом — об ошибках именно оптимизации (ваш шеф и с такими сталкивался?)


TB>Именно про ошибку, проявляющуюся именно в релизе с O2, не с O1.


хорошо. спасибо. теперь буду иметь в в иду и о таких превратностях судьбы (надеюсь, меня они минут, ибо в анализе дезасемблированнго кода я не мастер).
Re[7]: debug - release problem
От: ononim  
Дата: 15.08.16 19:38
Оценка:
__>>в смысле, майкрософт признал ошибку?
TB>То есть иначе ты не признаешь, что компиль может генерить лажу?
TB>Асмовыхлоп есть, там просто видно, что компиль посылает в функцию смещение на какуюто фигню, а не на нужный объект.
Пока выглядит как применение reinterpret_cast к классу с ромбовидным наследованием.
Как много веселых ребят, и все делают велосипед...
Re[8]: debug - release problem
От: T4r4sB Россия  
Дата: 15.08.16 19:55
Оценка:
Здравствуйте, ononim, Вы писали:

O>Пока выглядит как применение reinterpret_cast к классу с ромбовидным наследованием.


Ещё раз: проблема именно в слое, на которые средствами С без асмовставок влиять невозможно.

http://www.gamedev.ru/flame/forum/?id=198083

Смотри, где на стеке находится число 12345678h, и чему равно значение esp на момент вызова i.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Re[3]: debug - release problem
От: landerhigh Пират  
Дата: 18.08.16 14:04
Оценка:
Здравствуйте, _hum_, Вы писали:

__>проблема быстро решилась после того, как настройка среды привела к проявлению этой проблемы и в дебаг версии (это к вопросу о полезности дебагинга)


О бесполезности, скорее.
Примитивнешие же юнит-тесты, прогоняющие логику в релизе, отловили бы эту мину еще год назад, когда ее еще только заложили
www.blinnov.com
Re[4]: debug - release problem
От: _hum_ Беларусь  
Дата: 18.08.16 14:50
Оценка:
Здравствуйте, landerhigh, Вы писали:

L>Здравствуйте, _hum_, Вы писали:


__>>проблема быстро решилась после того, как настройка среды привела к проявлению этой проблемы и в дебаг версии (это к вопросу о полезности дебагинга)


L>О бесполезности, скорее.

L>Примитивнешие же юнит-тесты, прогоняющие логику в релизе, отловили бы эту мину еще год назад, когда ее еще только заложили

ну наконец-то, а то я уже стал волноваться
Re[2]: debug - release problem
От: Vain Россия google.ru
Дата: 03.09.16 07:28
Оценка:
Здравствуйте, Pzz, Вы писали:

Pzz>Вообще никогда не понимал, зачем нужна Debug-сборка. Вместо одной программы приходится тестировать и отлаживать две.

И этого ещё мало будет.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.