Я строю tensorflow_cc.dll из источника TensorFlow (v2.0.0) с базелем 0.24.1 (версия компилятора 14.16.27023 из Visual Studio, 2017, без графического процессора), используя
bazel build --config=opt //tensorflow:tensorflow_cc.dll
При этом также создается заглушка tensorflow_cc.dll.if.lib, которую я переименую в tensorflow_cc.lib. Когда я связываю библиотеку со следующей простой программой на c ++
#define NOMINMAX
#define COMPILER_MSVC
#include "tensorflow/core/platform/logging.h"
int main(int argc, char* argv[]) {
LOG(ERROR) << "Test";
}
и запускаю ее, сразу после отображения сообщения журнала происходит сбой, получая следующую трассировку стека из отладчика:
ntdll.dll!RtlpBreakPointHeap()
ntdll.dll!RtlpValidateHeapEntry()
ntdll.dll!RtlValidateHeap()
KernelBase.dll!HeapValidate()
ucrtbased.dll!_CrtIsValidHeapPointer(const void * block) Line 1407
at minkernel\crts\ucrt\src\appcrt\heap\debug_heap.cpp(1407)
ucrtbased.dll!free_dbg_nolock(void * const block, const int block_use) Line 904
at minkernel\crts\ucrt\src\appcrt\heap\debug_heap.cpp(904)
ucrtbased.dll!_free_dbg(void * block, int block_use) Line 1030
at minkernel\crts\ucrt\src\appcrt\heap\debug_heap.cpp(1030)
ucrtbased.dll!free(void * block) Line 32
at minkernel\crts\ucrt\src\appcrt\heap\free.cpp(32)
msvcp140d.dll!std::_Crt_new_delete::operator delete(void * _Ptr) Line 73
at d:\agent\_work\3\s\src\vctools\crt\crtw32\stdhpp\xlocale(73)
msvcp140d.dll!std::locale::`scalar deleting destructor'(unsigned int)
msvcp140d.dll!std::ios_base::_Ios_base_dtor(std::ios_base * _This) Line 44
at d:\agent\_work\3\s\src\vctools\crt\crtw32\stdcpp\ios.cpp(44)
msvcp140d.dll!std::ios_base::~ios_base() Line 478
at d:\agent\_work\3\s\src\vctools\crt\crtw32\stdhpp\xiosbase(478)
msvcp140d.dll!std::basic_ios<char,std::char_traits<char> >::~basic_ios<char,std::char_traits<char> >() Line 34
at d:\agent\_work\3\s\src\vctools\crt\crtw32\stdhpp\ios(34)
main.exe!tensorflow::internal::LogMessage::`vbase destructor'()
main.exe!main(int argc, char * * argv) Line 7
at (PATH_TO_PROJECT)\main.cpp(7)
После проверки исходного кода я вижу, что макрос LOG(ERROR) расширяется до конструктора класса tensorflow::internal::LogMessage, который наследуется от std::basic_ostringstream<char>. Ошибка кучи возникает, когда деструктор базового класса удаляет свой внутренний буфер.
При выполнении других вызовов API возникают подобные сбои, приводящие к выполнению записей журнала.
Вопрос:У кого-нибудь есть идея, что вызывает эту проблему и как ее исправить?
Вопрос: Кому-нибудь удалось на самом деле использовать TensorFlow 2.0 из автономной программы c ++, связавшись с API-интерфейсом c ++ через динамическийбиблиотека ссылок в Windows?
Вопрос: у кого-нибудь есть предложенное решение? Я пытаюсь использовать API Tenorflow из автономной программы, которую я разрабатываю в Visual Studio C ++.
Использование Python не вариант в моем приложении, так как интерпретатор не работает, чтобы замедлить то, что яделает. Я также попытался включить мою программу в дерево исходных кодов тензорного потока наряду с примерами, но был раздражен очень длинным циклом development-> build-> debug (также bazel не очень хорошо себя вел, иногда вызывая полное перестроение tenorflow в течение 1 часа + длябез видимой причины и заполнения жесткого диска временными файлами).
Я подал ошибку как выпуск 33267 .