Как правильно написать C ++ DLL, которая будет загружаться и в режиме отладки без сбоев

мои проблемы связаны с собственными библиотеками DLL C ++ (Visual Studio 2005, если это имеет значение) и с тем, как их писать, чтобы гарантировать, что:

  • когда DLL скомпилирована в режиме выпуска, она будет правильно загружена EXE, скомпилированным в режиме выпуска или отладки (первый приоритет)
  • когда DLL скомпилирована в режиме отладки, она также будет правильно загружена EXE, скомпилированным в режиме отладки.

Сегодня у меня есть собственная библиотека C ++, которая загружается и отлично работает в режиме выпуска DLL / EXE. DLL загружается, но не работает нормально (вызовы функций возвращают неожиданные результаты) в режиме выпуска DLL / EXE (и это огромная проблема, потому что это не позволяет мне отлаживать EXE, что является моей основной целью) и дает сбой о повреждении кучи в режиме DLL-debug / EXE-debug.

Я знаю, что существует проблема, связанная с CRT, которая требует изоляции CRT между DLL и EXE. Обычно эту проблему решают, делая операторы new / new [] / delete / delete [] частными в DLL и оборачивая их функциями create () / release (), которые позволяют создавать динамический объект EXE.

Мой вопрос: прежде чем я начну перефакторинг всего моего кода в этом направлении, нужно ли мне еще что-нибудь сделать, чтобы избежать подобных проблем? CRT-изоляция, вероятно, исправит мой сбой DLL-debug / EXE-debug, но я не уверен, что это решит проблему DLL-release / EXE-debug.

Намек? Кто-нибудь уже сталкивался с этой проблемой?

Спасибо, Ал.


c++ release crash debugging dll
person Alberto Avanzi    schedule 15.09.2010    source источник

Ответы (2)


arrow_upward
0
arrow_downward

Не используйте код, зависящий от конфигурации, в общедоступных h-файлах Dll. Например:

class ExportedClass
{
...

#ifdef _DEBIG
    int debug_info;
#endif

...
}

Когда Dll компилируется в конфигурации отладки, sizeof (ExportedClass) содержит дополнительные 4 байта. Когда этот файл компилируется клиентским кодом конфигурации Release, sizeof (ExportedClass) на 4 байта меньше. Результат не определен.

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

person Alex F    schedule 15.09.2010
comment
Привет спасибо за ответ Да, я знаю, это уже сделано. Например, я старательно избегаю использования std в общедоступных файлах DLL .h из-за этой проблемы. Мой код DLL довольно самодостаточен и использует только примитивные типы или типы, которые определены в самой DLL и размер которых не зависит от конфигурации. - person Alberto Avanzi; 15.09.2010

arrow_upward
0
arrow_downward

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

Кроме того, я не уверен, почему вы думаете, что повреждение кучи должно быть решено с помощью изоляции CRT и не является проблемой в коде dll или exe. Связаны ли DLL и EXE с разными версиями CRT?

person Franci Penov    schedule 15.09.2010
comment
Привет спасибо за ответ Я почти уверен, что проблем с повреждением кучи ни в exe, ни в dll нет. Оба они месяцами работали в конфигурации выпуска / выпуска под разными ОС и ПК без каких-либо проблем. Более того, сбой происходит, как только объект, определенный в DLL, уничтожается (оператор удаления). Звонок совершенно законен, и это заставляет меня думать, что он решает проблему, связанную с ЭЛТ. Кроме того, я согласен с вами, что и моя DLL, и EXE (на данный момент) используют одну и ту же версию CRT, так что, вероятно, мне стоит еще немного покопаться в этом повреждении кучи ... - person Alberto Avanzi; 15.09.2010