DLL и память

[ezus]

Добрый день.

Есть DLL, обращение к которой выполняется через  LoadLibrary и GetProcAddress.
И DLL, и программа написаны на С++ 6.0.

Вопросы:
1. Тело DLL размещается в своем адресном пространстве или в адресном пространстве вызывающей программы?
2. Может ли вызывающая программа в процессе подготовки данных испортить тело  DLL?

Спасибо.

[Finch]

Код DLL размешается в расшаренной памяти. Т.е. для всех процессов Dll загружается только 1 раз. Потом система только расшаривает код. Ты с юзер мода не сможеш что либо затереть в коде DLL. Вот область переменных для каждого процесса своя.

[ezus]

Тогда, что может быть причиной падения?
Программа падает на операторе

Код:

           memcpy(str2,Conditions->GetAt(j),LEN_FM_DESCRIP);

что в кодах

Код:

     102198F1   jb          CopyUnwindUp (1021991c)
=>   102198F3   rep movs    dword ptr [edi],dword ptr [esi]
     102198F5   jmp         dword ptr [edx*4+10219A08h]

[Finch]

ezus, А что есть str2. Что возвращает Conditions->GetAt(j). Ну и что есть LEN_FM_DESCRIP?

[Dimka]

Для DLL, хотя она находится в адресном пространстве процесса, есть ньюансы с выделением и освобождением памяти. Кратко всё сводится к правилу: где выделил память, там и освободи. На выделенную в основной программе память можно передать указатель в DLL, чтобы та могла читать или писать в эту память. Но освобождать память должна также основная программа. Если DLL выделяет память, она может передать указатель в основную программу, чтобы та могла читать или писать в эту память. Но освобождать память должна также DLL.

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

[Ochkarik]

Dimka, серьезно? по поводу выделения-освобождения памяти?
всегда считал что разницы не должно быть - кто выделяет а кто освобождает....
почему так? где почитать можно?

[Антон (LogRus)]

Ochkarik, потому, что аллокаторы, умные указали, буфер на стеке и т.д. и т.п.
Тоже может касаться не только dll, но и статик библиотек и даже классов с функциями

Ты не знаешь, какием способом была выделена память и выделялась ли вообще, может это был malloc, а не new или библиотека заранее создала 10 элементов одним массивом и отдала тебе только один элемент, а ты решил, что его можно грохнуть через delete

[Dimka]

Ochkarik, где почитать - не знаю. "И опыт - сын ошибок трудных..." Устное предание

Если основная программа собрана, допустим, в Debug, а DLL - в Release, то в этих режимах сборки выделение памяти происходит по-разному (в Debug память выделяется с запасом). Поэтому такой невинный на первый взгляд подход, как выделение памяти в программе, а освобождение - в DLL, приводит к access violation. EXE и DLL - разные исполняемые файлы, и в них влинкованы собственные экземпляры стандартной и прочих статических библиотек, или же идёт обращение к разным версиям DLL из Microsoft'овских библиотека (с суффиксом D и без оного).

[ezus]

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

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

[RXL]

ezus, очень наивно. Это как кидать мусор из окна, считая, что до своего этажа куча еще не скоро дорастет.
Размер нужно высчитывать точно, или брать с запасом. Либо проверять перед копированием - сравнивать длину данных и размер буфера. Если это действительно строка, то добавь еще место для терминирующего нуля.

[ezus]

А что есть str2. Что возвращает Conditions->GetAt(j). Ну и что есть LEN_FM_DESCRIP?

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

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

1-ый - это расчет. Большой, может продолжаться часами и жрать море памяти. Результаты сохраняет в MS Access. Комментировать:fie:.Решение не мое.

2-ой - это отчет по результатам расчета. Исходные данные читает из MS Access.

Расчет расположен в головной программе, а отчет в DLL.

Программа падает, если запускать отчет после расчета.
По отдельности все работает. Т.е., если запускать отчет после рестарта программы, то все ОК.

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

Загрузка DLL выполняется непосредственно перед вызовом функции печати на втором шаге.

У меня уже крыша едет. Я никак не могу нашупать идеи.

Буду благодарен любым подсказкам, мыслям, ассоциациям.

Добавлено через 3 минуты и 49 секунд:

очень наивно. Это как кидать мусор из окна, считая, что до своего этажа куча еще не скоро дорастет.
Размер нужно высчитывать точно, или брать с запасом. Либо проверять перед копированием - сравнивать длину данных и размер буфера. Если это действительно строка, то добавь еще место для терминирующего нуля.

Все верно, но проблема ведь не в этом.
Если в поле под 10 символов я запишу 20, то программа от этого не упадет на операторе записи. Она может упасть потом(дай б-г), когда затертая память будет использоваться, но не в момент записи, как у меня.

[RXL]

Если в поле под 10 символов я запишу 20, то программа от этого не упадет на операторе записи. Она может упасть потом(дай б-г), когда затертая память будет использоваться, но не в момент записи, как у меня.

Ну-ну. Удачной охоты за багами.

[ezus]

Если в поле под 10 символов я запишу 20, то программа от этого не упадет на операторе записи. Она может упасть потом(дай б-г), когда затертая память будет использоваться, но не в момент записи, как у меня.

Ну-ну. Удачной охоты за багами.

Я был не прав?
Программа упадет в момент выхода за границы?

[RXL]

Какая разница?! Она будет функционировать не верно и это главное. А если она не упадет сразу, то результат работы дальнейшей работы будет непредсказуем.

[ezus]

Какая разница?! Она будет функционировать не верно и это главное. А если она не упадет сразу, то результат работы дальнейшей работы будет непредсказуем.

Да, большая разница!!!
В данный момент у меня цель другая, не написать программу без ошибок, а НАЙТИ УЖЕ существующую ошибку, чтобы исправивь ее получить "предсказуемую" программу.
Я ищу причину, по которой программа падает. Поэтому, если превышение размеров буфера не приводит к мгновенному падению, то это не моя ошибка, надо искать, что-то другое.

[RXL]

Проверь:
1. Размер буфера назначения.
2. Корректность указателя источника.

Поставь в отладчике точку останова и просмотри память источника.

[Dimka]

ezus, ты привёл одну строчку кода. Больше мы ничего не знаем. Тебе говорят о том, что в этой строчке может быть проблемным. Кроме сказанного, в ней ничего другого проблемного нет и быть не может. Не хочешь проверять, не хочешь разбираться - чего тогда спрашиваешь?

Или вся тема - не просьба помочь, а способ пожаловаться на трудную жизнь? Ну тогда я лично сочувствую, скорблю и т.д.

[Ochkarik]

Антон (LogRus), Dimka, понял)
каждый раз забываю, что память можно не только через API выделять

[ezus]

Всем спасибо и за помощь и за сочувствие.
Код не мой, поэтому не сразу обратил внимание, что источник CString.

[Алексей++]

прошёлся по дурацким граблям, часа 2 выяснял причину

Есть программа на C++ и DLL на C++

передавал в DLL из программы указатель на std::string , функция в DLL заполняла контейнер. А в дебаге , в деструкторе контейнера программа валилась (в релизе не валилась)

Оказалось, что если в контейнере, принадлежащем программе, после передачи указателя в DLL производилась переаллокация, то вот тогда этот падёж и возникал. Если зарезервировать нужный объём, а в DLL не переступать границу capacity , то всё ок

[Dimka]

Это частный случай другой темы - о выделении и освобождении памяти в DLL и EXE.

[Алексей++]

Dimka, где почитать ?

[Вад]

Так а что тут читать? При линковке dll получает свою копию функций аллокации, а exe - свою. В общем случае, версии этих функций могут различаться, и в релизе будет валиться тоже. Валиться будет и в том случае, если функции имеют side-effect - то есть, аллокация/освобождение памяти сопровождаются изменением каких-то глобальных переменных: собственно, в debug так и происходит, поскольку там есть дополнительные проверки насчёт того, выделялась ли вообще освобождаемая память, и нужно ли по этому поводу вызывать деструктор(ы).

Вообще, экспорт типов (в том числе, и std::string) из dll должен помогать. По крайней мере, мне, помнится, приходилось подобным образом решать проблему работы контейнеров через границу модуля: наследовал какой-то стандартный контейнер и делал экспорт/импорт (если не ошибаюсь, можно и напрямую экспортировать). Как результат, весь код компилируется в составе dll, и методы контейнера (в их числе, разумеется, и производящие аллокацию) вызываются из кода dll. Хотя это может быть не очень удобно в общем случае.

[Алексей++]

Вад, ну суть то я понял, почему так произошло )

>>экспорт типов (в том числе, и std::string) из dll должен помогать.
а это как делается ?

[Вад]

>>экспорт типов (в том числе, и std::string) из dll должен помогать.
а это как делается ?

http://support.microsoft.com/kb/168958/en-us (не люблю майкрософтовский автоматический перевод на suppot-е, он корявый какой-то)

[Алексей++]

Вад, спасибо, щас почитаю. А перевод - это да, вечная там подстава, и не всегда сразу найдёшь, как инглиш переключить ))

хотя, я заметил, если ссылка оканчивается на "en-us" , то насильного перевода не происходит