Многопоточность и STL
Приветствую всех. Ситуация следующая. Есть проект, состоящий из 5 Dll и 1-го exe файла. Некоторые dll файлы ссылаются друг на друга, а exe файл ссылается на две из всех dll. В целом проект собирается под VS2005. Более того проект двухпоточный. Один поток в файле visualizator.dll здесь же существует глобальный объект визуализатора, второй поток calculator.dll, здесь же глобальный объект вычислителя. В проекте используется STL, а именно вектора. Также хочу обратить внимание что в потоке вычислителя в цикле создаются объекты и записываются в объект визуализатора, кот. затем выводит на дисплей данные. Синхронизация проводиться через событие. Теперь о проблеме: проблема в том, что иногда, не часто и не регулярно возникают ошибки времени выполнения и под отладчиком в стэке вызовов функций останавливается на scalar destructor для одного из классов граф. компонента, кот. отображается на дисплей. Вопрос в следующем, может ли быть эти ошибки из за того, что приложение многопоточное и одновремено используется STL? И может ли на эти ошибки влиять использование DLL?
Спасибо.
Спасибо.
Подробное описание ошибок, стеки потоков, куски исходного кода. Иначе: "Ждет вас дальняя дорога и казенный дом".
сама STL не многопоточная, и при обращении к контейнерам требуется синхронизация... это про STL... остальное настолько расплывчато, что правильный ответ будет "ХЗ".
Приветствую. Вот пока что один скрин, в ситуации отладки. Ошибка возникает во время выполнения программа.
Скриншот можно было и побольше приложить, а вообще и просто текста хватило бы.
Во время выполнения это когда, на старте на загрузке/выгрузке DLL, на завершении программы?
Рискну предположить что _crtheap в приведенном выше контексте равно 0 и сразу возникает вопрос как вы слинковались со стандартной либой статически иль динамически?
Во время выполнения это когда, на старте на загрузке/выгрузке DLL, на завершении программы?
Рискну предположить что _crtheap в приведенном выше контексте равно 0 и сразу возникает вопрос как вы слинковались со стандартной либой статически иль динамически?
Скриншот я попытался прислать с разрешением 1280Х800, и размер его 150КБ, поэтому то что залилось видимо урезалось. Напишите эмайл, я пришлю вам скриношот. Теперь по поводу времени возникновения. Возникает в момент когда программа проработала уже минуты 2-3, т.е. не на этапе загрузки или выгрузки DLL, закрытия прогрммы. На счет линковки вот что: все проекты в решении собирались с опцией "\MD (Multi-threaded DLL)" в поле Runtime Library для релиз версии.
Все равно поставлю на то, что вы аллоцируете память в одном модуле EXE/DLL, а освобождаете в другом и проблемы в линковке.
PS: Ибо очень похоже что кто-то слинкован статически, а в маргинальном случае с другой версией рантаймной либы.
PS: Ибо очень похоже что кто-то слинкован статически, а в маргинальном случае с другой версией рантаймной либы.
Такое предпложение, может быть стоит скомпилить все dll с опцией \MD, а exe файл с \MT (Multi-Threaded)? И еще такой важный момент, потоки создаются с помощью функций CreateThread. Когда я просматривал труд Рихтера, там рекомендовалось использовать другую функцию. Возможно ли ошибка происходит из за того что потоки создаются через функцию CreateThread?
Проверьте, что у вас все везде /MD и нигде не линкуется например дебажная либа.
Естественно предпочтительнее юзать _beginthread вместо CreateThread, но это несколько иная история.
http://support.microsoft.com/default.aspx/kb/104641
Естественно предпочтительнее юзать _beginthread вместо CreateThread, но это несколько иная история.
http://support.microsoft.com/default.aspx/kb/104641
Еще можете посмотреть список загруженных модулей в окне через меню Debug->Windows->Modules на момент крэша и запостить то, что там есть.
Цитата: dox07
И еще такой важный момент, потоки создаются с помощью функций CreateThread. Когда я просматривал труд Рихтера, там рекомендовалось использовать другую функцию. Возможно ли ошибка происходит из за того что потоки создаются через функцию CreateThread?
Вам обязательно нужно использовать _beginthread/ex() чтобы менеджер памяти перешел в соответствующий режим. Проблема с большой вероятностью в этом.
Не надо путать людей, _beginthred влияет на контекстно зависимые ф-ции стандартной библиотеки такие как strtok и locale. А так называемый "менеджер памяти" инициализируется, а точнее ему выделяется куча один раз при инициализации рантайма, если таких рантаймов было несколько, например один статически слинкован с EXE, другой динамически с некой другой библиотекой, используемой сим EXE то мы получим две инициализации и две кучи, а если будем выделять из одной, а освобождать память в другую получим то самое. Также достаточно двух версий одного рантайма, одной дебажной, а другой релизной.
Спасибо за внимание.
Спасибо за внимание.
Да, я похоже заблуждаюсь с 2005-м. Действительно там CRT изначально настроен на многопоточность и готов выделить/освобождать те же блоки из различных потоков. Проблема с двумя CRT и, соответственно, двумя менеджерами памяти мною не отрицалась, но по идее должна приводить лишь к нехватке памяти на оперделенном этапе (хотя немогу найти, застрахован ли менеджер памяти от освобождения не своего блока, если нет - конечно могут иметь место повреждения кучи).
Конечно, товарищ мог освободить одну и туже память дважды, но тогда это было бы совсем банально и скучно. А может так оно и есть.:(
Приветствую. Достаточно долго не писал здесь. Ситуация следующая, я собирал проект под висту и запускал проект под висту, в этом случае выдает ошибку. Если пробовать на XР, то пока что ошибки этой не наблюдалось (раз 40 запускали). На счет функций создания потоков, я пока что чисто теоретически знаю что если использовать _beginthreadex, то выделяется блок памяти для каждого потока, если я не ошибаюсь... .
*Поднял вверх палец*