Есть ПО, написаное на борланде с++ (2006, вроде), и длл на MSVS2010.
Dll-ка при работе может выпрашивать себе (new) до 600-700 МБ блоками по 2-4 МБ. Также известно, что само ПО может запрашивать столько же или меньше. Цифры примерные, но, в общей сложности, в сумме не превышают 1.2-1.3 ГБ. Процесс 32бит. У длл /MT.
Так вот, если длл-ку подключать к тестовому проекту MSVS — память выделяется, все работает, жизнь хороша.
Если же ее подключать к вышеупомянутому ПО, то dll начинает кидать bad_alloc еще не успев запросить и 200 МБ из любых new, будь то тот самый 2МБ блок или push_back совсем скромного вектора.
Есть ли в этой связи какие-то общеизвестные факты? Да и вообще, что делать-то, как их подружить?
Здравствуйте, kosmas, Вы писали:
K>А здравствуйте.
K>Есть ПО, написаное на борланде с++ (2006, вроде), и длл на MSVS2010. K>Dll-ка при работе может выпрашивать себе (new) до 600-700 МБ блоками по 2-4 МБ. Также известно, что само ПО может запрашивать столько же или меньше. Цифры примерные, но, в общей сложности, в сумме не превышают 1.2-1.3 ГБ. Процесс 32бит. У длл /MT.
K>Так вот, если длл-ку подключать к тестовому проекту MSVS — память выделяется, все работает, жизнь хороша. K>Если же ее подключать к вышеупомянутому ПО, то dll начинает кидать bad_alloc еще не успев запросить и 200 МБ из любых new, будь то тот самый 2МБ блок или push_back совсем скромного вектора.
K>Есть ли в этой связи какие-то общеизвестные факты? Да и вообще, что делать-то, как их подружить?
Похоже, куча приложения и куча дллки передрались за адресное пространство.
На всякий случай начну сначала, чтобы потом не возвращаться.
Куча — некий системный пул памяти, из которого в дальнейшем берутся блоки памяти на нужды приложения.
В винде куча описывается дескриптором, и в приложении их может быть несколько штук.
С++ runtime выделяет при запуске приложения одну такую кучу, из которой потом берут память malloc и new. По сути, это просто глобальная переменная, со всеми своими плюсами и минусами. Как Вы понимаете, если ваши приложение и длл линкуются даже с разными инстансами рантайма, куч получается две штуки. Просто потому что каждый модуль сам держит свои статические данные. И за адресное пространство приложения у них может случиться драка. Примерно как при фрагментации обычной кучи.
Есть несколько способов решить проблему:
1. Линковать обоих пациентов с одним рантаймом. Правда, я не в курсе, с каким рантаймом линковался борланд. Если там тоже статика, а исходников чтобы пересобрать нету, скорее всего дохлый номер.
2. Попытаться заставить софтину юзать 3гб, а не 2. Но для этого надо иметь и приложение, и длл, собранные с этим ключом (вроде можно подхачить готовый бинарь), и ось запускать с определённым ключиком.
3. Плюнуть на всё, написать прокси-длл с интерфейсом нужной, которая будет стартовать отдельный процесс и общаться с ним каким-л. способом, маршаля параметры и результаты туда-сюда. Для этого можно попробовать COM outproc server как готовую инфраструктуру. Если подхачить манифест, не прийдётся регистрировать в глобальной свалке.
Здравствуйте, Мишень-сан, Вы писали:
МС>Есть несколько способов решить проблему: МС>1. Линковать обоих пациентов с одним рантаймом.. МС>2. Попытаться заставить софтину юзать 3гб... МС>3. Плюнуть на всё, ...
Здравствуйте, johny5, Вы писали:
J>Здравствуйте, Мишень-сан, Вы писали:
МС>>Есть несколько способов решить проблему: МС>>1. Линковать обоих пациентов с одним рантаймом.. МС>>2. Попытаться заставить софтину юзать 3гб... МС>>3. Плюнуть на всё, ...
J>4. 64 битный билд
В принципе да, но:
а) не всякий код написан как 64-bit portable, могут вылезти сказочные тараканы
б) не факт, что указанный борланд сможет собрать 64 бит
в) не факт, что у ТС 64-бит ось
Оффтопик.
Вообще, как ни странно, в винде с 64-битностью софта сейчас всё довольно печально. Да и нужна эта 64-битность по сути только для использования памяти больше ~3гб. PAE работает уже давно, но его используют в основном ради DEP — адресное пространство для ритейл-операционок ограничено 32бит на уровне ядра. Якобы из-за некоторых криворуких писателей драйверов. Хотя не думаю, что было бы большой проблемой ввести отдельную сертификацию на соответствие PAE. И громко предупреждать о драйверах, не подписанных подобным способом. Скорее вопрос в желании держать несколько версий оси с минимальными отличиями, но за существенно разные деньги. Да и судя по жалобам на форумах железа и низкоуровневого программирования у МС с тестами на сертификацию местами всё очень загадочно.
Здравствуйте, Мишень-сан, Вы писали:
J>>4. 64 битный билд
МС>В принципе да, но: МС>а) не всякий код написан как 64-bit portable, могут вылезти сказочные тараканы
Да, в случае Майкрософта — она сделала всё, чтобы приколы портабельности минимизировать. Все 32х и 64х битные типы одинаковы(!) за исключением, очевидных: указателей и size_t/ptrdiff_t. Часто достаточно просто компильнуть под 64 бита чтобы заработало.
С Борландом не знаю, стоит хотя бы попробовать, может оказаться не сложнее.
