информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Spanning Tree Protocol: недокументированное применениеСтрашный баг в WindowsАтака на Internet
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Бэкдор в xz/liblzma, предназначенный... 
 Три миллиона электронных замков... 
 Doom на газонокосилках 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / programming
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
все так 25.02.03 19:24  Число просмотров: 884
Автор: chaka Статус: Незарегистрированный пользователь
<"чистая" ссылка> <обсуждение закрыто>
Статику я использую из следующих соображений:
проекты, как правило, пишуться и отлаживаются с одним crt-шником, но работают потом где угодно. Я не мог даже предположить, на какие машины заказчики умудраются ставить потом это ПО (от первых пней и до пром-машин у которых оперативки больше чем у меня винчестера), так что и операционные системы, даже в пределах win32 у конечного пользователя тоже варьюруются, поэтому для уверенности в том что все мои глюки это исключительно мое творение - я компонуюсь по статике (потому что включать в инсталяху еще и crt - это не очень хорошая идея). Хотя, конечно, раздувание проекта таким образом мне не очень по душе, но более веских аргументов для использования динамической компоновки у меня пока нет. Если кто убедит - буду признателен :)
<programming>
[C++] Освобождение памяти 25.02.03 04:15  
Автор: makeworld Статус: Member
<"чистая" ссылка> <обсуждение закрыто>
Пример кода:
char* func() {
   char *rez;
   rez = (char *)malloc(1024);
   //..
   return rez;
}

void main() {
   char *pc;
   pc = func();
   //...
   free(pc);
}

---

Будет ли освобождена память, выделенная в функции func()?
Что касается win32 26.02.03 02:00  
Автор: Killer{R} <Dmitry> Статус: Elderman
<"чистая" ссылка> <обсуждение закрыто>
The GlobalAlloc function allocates the specified number of bytes from the heap. In the linear Win32 API environment, there is no difference between the local heap and the global heap.
так что куча одна на всех. А конкретная реализация malloc - это дело компилятора имхо. И если кроме GlobalAlloc при этом ваша программа помечает гдето у себя что этот кусок выделен malloc'ом - то естественно длл не сможет его освободить. это тока мое имхо, а проверять на деле - влом. Мот те кто уже накомпилял dll и exe попробую вместо malloc и (это вообще изврат) new/delete заюзать GlobalAlloc / VirtualAlloc -самому интересно.
Лучше HeapAlloc 26.02.03 14:13  
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка> <обсуждение закрыто>
> The GlobalAlloc function allocates the specified number of
> bytes from the heap. In the linear Win32 API environment,
> there is no difference between the local heap and the
> global heap.
> так что куча одна на всех. А конкретная реализация malloc -
> это дело компилятора имхо. И если кроме GlobalAlloc при
> этом ваша программа помечает гдето у себя что этот кусок
> выделен malloc'ом - то естественно длл не сможет его
> освободить. это тока мое имхо, а проверять на деле - влом.
> Мот те кто уже накомпилял dll и exe попробую вместо malloc
> и (это вообще изврат) new/delete заюзать GlobalAlloc /
> VirtualAlloc -самому интересно.
Но весь сыр-бор из-за того, что у майкрософта руки кривые сделать СТАНДАРТНУЮ библиотеку так, чтоб она работала как описано в спецификации. GetProcessHeap использовать можно, но она не стандартизирована ANSI. Вот и вспоминается анекдот про то, что мелкософту легче объявить темноту новым стандартом, чем вкрутить лампочку.
[C++] Да, будет. 25.02.03 10:38  
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
<"чистая" ссылка> <обсуждение закрыто>
А в чем собственно сомнения? Ну отхватила вызываемая функция кусок памяти, передала начальный адрес вызывающей функции, а та освободила его. Функции free побарабану кто вызывал malloc, ей передали адрес куска, который высвободить надо, она и освобождает. Главное, чтобы этот кусок был распределен функцией malloc или calloc, но не alloc. В противном случае выползет какая-нибудь ошибка, или будет все благополучно, если free этот кусок проверит (симантековская функция это делает v7.2).
[C++] Да, будет. 25.02.03 13:49  
Автор: chaka Статус: Незарегистрированный пользователь
<"чистая" ссылка> <обсуждение закрыто>
Это будет работать за исключением одного сценария: если функция, выделяющая память находится в dll (win32), то попытка освободить эту память из функции, находящейся в .exe-модуле приведет, к тому, что память была веделена из одной кучи, а освобождена в другой. И вот тогда ой!
Да ты что ?! 25.02.03 16:13  
Автор: PS <PS> Статус: Elderman
<"чистая" ссылка> <обсуждение закрыто>
> Это будет работать за исключением одного сценария: если
> функция, выделяющая память находится в dll (win32), то
> попытка освободить эту память из функции, находящейся в
> .exe-модуле приведет, к тому, что память была веделена из
> одной кучи, а освобождена в другой. И вот тогда ой!

Правда что ли ?
А можно поподробней о разных кучах ? А может у dll и exe вообще разные адресные пространства ? Может указатели из ф-ий dll в ф-ии exe и передавать то нельзя ?
Да ты что ?! 25.02.03 17:05  
Автор: cb <cb> Статус: Member
<"чистая" ссылка> <обсуждение закрыто>
> Правда что ли ?

правда...

> А можно поподробней о разных кучах ?

все зависит от реализации run-time библиотек которые ты используешь - run-time от msvc ведет себя следующим образом:
- при статической линковке run-time библиотек каждый собранный модуль (dll/exe) получает собственную кучу откуда выделяется память (malloc/alloc), соответственно при попытке освободить память в модуле отличном от того в котором эта память была выделена - приведет к ошибке.
- если же run-time библиотека линкуется как внешняя dll - то у этой dll будет своя собственная куча и соответсвенно память будет браться всегда из нее и приблем с выделением/освобождением не будет...

В общем-то на мой взгляд память должна быть освобождена тем кто ее выделял - это как минимум безопасней...

> Может указатели из ф-ий dll в ф-ии exe и передавать то нельзя ?

см. выше.

cb.
Посмотрел на календарь... 25.02.03 18:04  
Автор: PS <PS> Статус: Elderman
<"чистая" ссылка> <обсуждение закрыто>
Сегодня не первое апреля...

> все зависит от реализации run-time библиотек которые ты
> используешь - run-time от msvc ведет себя следующим
> образом:
> - при статической линковке run-time библиотек каждый
> собранный модуль (dll/exe) получает собственную кучу откуда
> выделяется память (malloc/alloc), соответственно при
> попытке освободить память в модуле отличном от того в
> котором эта память была выделена - приведет к ошибке.

Бред. Даже не поленился сейчас тестик написать. Все работает нормально (что и не удивительно). В противном случае куча проектов бы давно отвалились, это раз, а два: весь COM основан на передаче указателей между модулями (мы говорим сейчас об одном процессе ! так что, умных слов типа "маршалинг" - не надо !).

> - если же run-time библиотека линкуется как внешняя dll -
> то у этой dll будет своя собственная куча и соответсвенно
> память будет браться всегда из нее и приблем с
> выделением/освобождением не будет...
>

ничего не понял.

> В общем-то на мой взгляд память должна быть освобождена тем
> кто ее выделял - это как минимум безопасней...

Это верно, но на счет Dll и Exe - полный бред.
[C++] 25.02.03 18:43  
Автор: chaka Статус: Незарегистрированный пользователь
<"чистая" ссылка> <обсуждение закрыто>
> Бред. Даже не поленился сейчас тестик написать. Все
> работает нормально (что и не удивительно). В противном
> случае куча проектов бы давно отвалились, это раз, а два:

Вот это уже обидно. Зачем сразу бред? Ты действительно сделал, проверил, работает. Отлично, а теперь запусти тоже самое но под отладчиком (или просто debug-версию) и получишь объяснение моего бреда. - Assertion Failed! _CrtIsValidHeapPointer(pUserData). А в релизе, где у тебя все работает - ты освобождаешь кусок адресного пространства в куче исполняемого модуля и раз "у тебя все работает", то довольно успешно, но, вот когда кто-то в этом исполняемом модуле совершенно случайно вместо своих данных в куче найдет там "бред", то не обижайся, просто, при освобождении памяти, выделенной в dll ты с чистой совестью грохнул данные, предназначенные совершенно для других целей (им просто не повезло, они находились по тому же (или смежному) адресу, что и данные, выделенные в dll, только в ДРУГОЙ КУЧЕ).

P.S. А если у тебя никаких предупреждений не всплывет в debug-версии программы, то, возможно ты компилируешь exe и dll-модули, связанные с библиотекой времени выполнения по динамике, ну, а если crt у тебя скомпонована по статике, то советую подумать о смене компилятора или замене библиотеки времени выполнения (CRT).

> весь COM основан на передаче указателей между модулями (мы
> говорим сейчас об одном процессе ! так что, умных слов типа
> "маршалинг" - не надо !).

Весь COM построен на принципе подщета ссылок, а не передаче указателей.
В результате подсчета ссылок если Release() возвращает 0, то память, выделенная под объект, освобождается, но это происходит в коде того модуля, КОТОРЫЙ ВЫДЕЛИЛ память под класс. Это происходит потому, что фабрика по созданию объектов и сам объект (который сам себя уничтожает) находятся в ОДНОМ модуле (exe или dll)
Мда 25.02.03 19:02  
Автор: PS <PS> Статус: Elderman
<"чистая" ссылка> <обсуждение закрыто>
Действительно, при статической линковке не фурычит...
Признаю, вы все правы были ;)
Век живи, век учись.
Посмотрел на календарь... 25.02.03 18:17  
Автор: cb <cb> Статус: Member
Отредактировано 25.02.03 18:18  Количество правок: 1
<"чистая" ссылка> <обсуждение закрыто>
> Бред.

это твое личное отношение к делу...


> Даже не поленился сейчас тестик написать. Все
> работает нормально (что и не удивительно).

в студию....

> В противном
> случае куча проектов бы давно отвалились, это раз, а два:
> весь COM основан на передаче указателей между модулями (мы
> говорим сейчас об одном процессе ! так что, умных слов типа
> "маршалинг" - не надо !).

никаких умных слов - я их просто не знаю...

> ничего не понял.

"учите матчасть" (C).

> Это верно, но на счет Dll и Exe - полный бред.

см. выше.

cb.
В студию так в студию... 25.02.03 18:29  
Автор: PS <PS> Статус: Elderman
<"чистая" ссылка> <обсуждение закрыто>
> в студию....

1. Exe делаешь MFC Wizard'ом. На диалоге. На OnOk Пишишь простейший код:
void CTestDllAllocExeDlg::OnOK() 
{

	char* m = myalloc();
	free( m );
	MessageBox( "OK" );

	CDialog::OnOK();
}

---

2. Dll делаешь тоже визардом (что б долго не трахаться) и заводишь в ней одну ф-ию:
char* myalloc()
{
	return (char*)malloc( 10 );
}

---

И ты хочешь сказать, что эта хрень не работоспособна ?

P.S. А если криворукие программеры из Борладна не умеют писать свой инструментарий под ОС от Microsoft, и их dll начинает конфликтовать с exe или dll созданом на других инструментах - то тут только можно развести руками.
[C++] В студию так в студию... 25.02.03 18:56  
Автор: chaka Статус: Незарегистрированный пользователь
<"чистая" ссылка> <обсуждение закрыто>
Кстати, раз пошла такая жара, вот код, который железобетонно валится:

//main_dll.cpp

__declspec(dllexport) char* __stdcall f(){
return new char[100];
}

//main_exe.cpp

__declspec(dllimport) char* __stdcall f();
int main(int argc, char** argv){
char* p = f();
delete [] p; // assertion failed, file: debugheap.c expression:
// _CrtIsValidHeapPointer(pUserData)
return 0;
}
все так 25.02.03 19:08  
Автор: dl <Dmitry Leonov>
<"чистая" ссылка> <обсуждение закрыто>
**int _CrtIsValidHeapPointer() - verify pointer is from 'local' heap
*
*Purpose:
*       Verify pointer is not only a valid pointer but also that it is from
*       the 'local' heap. Pointers from another copy of the C runtime (even in the
*       same process) will be caught.
*
*Entry:
*       const void * pUserData     - pointer of interest
*
*Return:
*       TRUE - if valid and from local heap
*       FALSE otherwise
******************************************************************************

---

Одно-единственное НО - все-таки если и exe, и dll пишутся в рамках одного комплекса, то я не вижу смысла в статической линковке с рантаймом. Ну а при динамической линковке все сработает без проблем.
все так 25.02.03 19:24  
Автор: chaka Статус: Незарегистрированный пользователь
<"чистая" ссылка> <обсуждение закрыто>
Статику я использую из следующих соображений:
проекты, как правило, пишуться и отлаживаются с одним crt-шником, но работают потом где угодно. Я не мог даже предположить, на какие машины заказчики умудраются ставить потом это ПО (от первых пней и до пром-машин у которых оперативки больше чем у меня винчестера), так что и операционные системы, даже в пределах win32 у конечного пользователя тоже варьюруются, поэтому для уверенности в том что все мои глюки это исключительно мое творение - я компонуюсь по статике (потому что включать в инсталяху еще и crt - это не очень хорошая идея). Хотя, конечно, раздувание проекта таким образом мне не очень по душе, но более веских аргументов для использования динамической компоновки у меня пока нет. Если кто убедит - буду признателен :)
все так 25.02.03 19:44  
Автор: dl <Dmitry Leonov>
<"чистая" ссылка> <обсуждение закрыто>
> Статику я использую из следующих соображений:
> проекты, как правило, пишуться и отлаживаются с одним
> crt-шником, но работают потом где угодно. Я не мог даже
> предположить, на какие машины заказчики умудраются ставить
> потом это ПО (от первых пней и до пром-машин у которых
> оперативки больше чем у меня винчестера), так что и
> операционные системы, даже в пределах win32 у конечного
> пользователя тоже варьюруются, поэтому для уверенности в
> том что все мои глюки это исключительно мое творение - я
> компонуюсь по статике (потому что включать в инсталяху еще
> и crt - это не очень хорошая идея). Хотя, конечно,
> раздувание проекта таким образом мне не очень по душе, но
> более веских аргументов для использования динамической
> компоновки у меня пока нет. Если кто убедит - буду
> признателен :)

Я предпочитаю именно вставлять crt в дистрибутив :) Естественно, не копируя его в системный каталог. Плюсы - при активном использовании функций из crt получаем выигрыш по памяти, получаем уменьшенный размер апдейтов, ну и не спотыкаемся на такие вот неочевидные глюки.
все так 25.02.03 19:52  
Автор: chaka Статус: Незарегистрированный пользователь
<"чистая" ссылка> <обсуждение закрыто>
Это неплохое решение, но для меня оно выглядит не более убедительным чем, скажем увеличение размера и т.д. Дело в том, что мое участие в проектах как правило сводится к написанию библиотек, следовательно бал заказывают разработчики исполняемых модулей, по этому статика в нашей организации - своего рода традиция, а менять тардиции по пустякам, как правило никто не хочет :)
все так 25.02.03 21:10  
Автор: dl <Dmitry Leonov>
<"чистая" ссылка> <обсуждение закрыто>
> Это неплохое решение, но для меня оно выглядит не более
> убедительным чем, скажем увеличение размера и т.д. Дело в
> том, что мое участие в проектах как правило сводится к
> написанию библиотек, следовательно бал заказывают
> разработчики исполняемых модулей, по этому статика в нашей
> организации - своего рода традиция, а менять тардиции по
> пустякам, как правило никто не хочет :)

Оно, конечно, дело вкуса, но просто меня бы жаба задушила, глядючи как десяток мелких dll занимается инициализацией рантайма и на ровном месте отжирает лишний мегабайт-другой :)
а вот 25.02.03 19:34  
Автор: PS <PS> Статус: Elderman
<"чистая" ссылка> <обсуждение закрыто>
> я
> компонуюсь по статике (потому что включать в инсталяху еще
> и crt - это не очень хорошая идея).

про rt библиотеки и инсталяшку - не надо. Если ты отдаешь не debug версии, то у клиентов и так все есть.
а вот 25.02.03 19:45  
Автор: chaka Статус: Незарегистрированный пользователь
<"чистая" ссылка> <обсуждение закрыто>
Да я не сомневаюсь, что у них все есть, я имею ввиду ВЕРСИИ, клиент может обладать версией библиотеки, отличной от той, с применением которой тестировалось ПО, по этому я компонуюсь по статике, чтобы быть уверенным, что си-библиотека времени выполнения работает так, как она работала у меня. И это не значит, что в этой библиотеке были или будут ошибки, это лишь значит то, что на своей версии crt я ТЕСТИРОВАЛ свое програмное обеспечение и если я, скажем что то сделал не так и МОЯ версия crt-это пропустила (т.е. это небыло вызвано побочных явлений), то я хочу, чтобы так было и впредь. Вот и все!!!
1  |  2 >>  »  




Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2024 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach