memory leaks! - Прочее

В оладочном режиме после работы приложения в окошко Debug вываливается информация такого характрера:

Detected memory leaks!
The thread 0x604 has exited with code 0 (0x0).
Dumping objects ->
thrdcore.cpp(166) : {227} client block at 0x00D03D70, subtype 0, 112 bytes long.
a CWinThread object at $00D03D70, 112 bytes long
{226} normal block at 0x00D01550, 4 bytes long.
 Data: <    > 01 00 00 00 
{225} normal block at 0x00D02580, 1 bytes long.
 Data: < > 0A 
F:\MyProjects\Wallpaper Magic\Wallpaper Magic.cpp(174) : {214} client block at 0x00D03E10, subtype 0, 476 bytes long.
a CMainFrame object at $00D03E10, 476 bytes long
Object dump complete.
The thread 0x3FC has exited with code 0 (0x0).

Понятно, что где-то в программе забыл прочистить память. Конечно в общем случае все это неважно, т.к. теоретически ОС должна сама все отчистить. Есдинственное когда это важно, если ось 95/98/Me (они очищают толь теоретически; практически помогает только ребут) или программа должна непрерывно работать очень долго и утечки памяти могут повредить работе.

Это все не про мой случай, однако хотелось бы написать программу, которая бы работала максимально корректно. И, соответственно, хотелось бы все эти leaks поймать. Но как? В окно Debug вываливается какая-то обкоцаная информация, типа "normal block at 0x00D01550, 4 bytes long". Чесно говоря, адрес 0x00D01550 мне ничего не говорит.

Итак, есть ли какой-то способ поймать memory leaks

в программе? Т.е. получить конкретную информацию: для какой переменной память выделил, а убрать за собой забыл.

Спасибо.

P.S. Я конечно понимаю, что хочу слишком много и так не бывает. Однако, может быть хотя бы можно продвинуться подальше адреса 0x00D01550 способом более простым, чем смотреть адреса всех указателей

(программа довольно большая).

Как это не важно чистить память? Если у тебя работает приложение, и оно отжирает память, то в конечном итоге машина будет тормозить. А чтобы поймать все лики, найди все операторы new в проекте, и засунь объекты которые создаются оператором new в смартптр

С вероятностью 98% ликов не должно быть.

Здравствуйте CooLer, Вы писали:

CL>В оладочном режиме после работы приложения в окошко Debug вываливается информация такого характрера:

CL>

Detected memory leaks!
CL>The thread 0x604 has exited with code 0 (0x0).
CL>Dumping objects ->
CL>thrdcore.cpp(166) : {227} client block at 0x00D03D70, subtype 0, 112 bytes long.
CL>a CWinThread object at $00D03D70, 112 bytes long
CL>{226} normal block at 0x00D01550, 4 bytes long.
CL> Data: <    > 01 00 00 00 
CL>{225} normal block at 0x00D02580, 1 bytes long.
CL> Data: < > 0A 
CL>F:\MyProjects\Wallpaper Magic\Wallpaper Magic.cpp(174) : {214} client block at 0x00D03E10, subtype 0, 476 bytes long.
CL>a CMainFrame object at $00D03E10, 476 bytes long
CL>Object dump complete.
CL>The thread 0x3FC has exited with code 0 (0x0).

CL>Понятно, что где-то в программе забыл прочистить память. Конечно в общем случае все это неважно, т.к. теоретически ОС должна сама все отчистить. Есдинственное когда это важно, если ось 95/98/Me (они очищают толь теоретически; практически помогает только ребут) или программа должна непрерывно работать очень долго и утечки памяти могут повредить работе.

CL>Это все не про мой случай, однако хотелось бы написать программу, которая бы работала максимально корректно. И, соответственно, хотелось бы все эти leaks поймать. Но как? В окно Debug вываливается какая-то обкоцаная информация, типа "normal block at 0x00D01550, 4 bytes long". Чесно говоря, адрес 0x00D01550 мне ничего не говорит.

CL>Итак, есть ли какой-то способ поймать memory leaks

в программе? Т.е. получить конкретную информацию: для какой переменной память выделил, а убрать за собой забыл.

CL>Спасибо.

CL>P.S. Я конечно понимаю, что хочу слишком много и так не бывает. Однако, может быть хотя бы можно продвинуться подальше адреса 0x00D01550 способом более простым, чем смотреть адреса всех указателей

(программа довольно большая).

Mozhesh vospolzovatsya otladochnymi funkciyami iz C-runtime:
CrtMemCheckpoint i im podobnye.
Okruzhi kazdyi funkcionalnyi block
svoey programmy i proveryai na memory leaks.

Здравствуйте CooLer, Вы писали:

CL>В оладочном режиме после работы приложения в окошко Debug вываливается информация такого характрера:

CL>

Detected memory leaks!
CL>The thread 0x604 has exited with code 0 (0x0).
CL>Dumping objects ->
CL>thrdcore.cpp(166) : {227} client block at 0x00D03D70, subtype 0, 112 bytes long.
CL>a CWinThread object at $00D03D70, 112 bytes long
CL>{226} normal block at 0x00D01550, 4 bytes long.
CL> Data: <    > 01 00 00 00 
CL>{225} normal block at 0x00D02580, 1 bytes long.
CL> Data: < > 0A 
CL>F:\MyProjects\Wallpaper Magic\Wallpaper Magic.cpp(174) : {214} client block at 0x00D03E10, subtype 0, 476 bytes long.
CL>a CMainFrame object at $00D03E10, 476 bytes long
CL>Object dump complete.
CL>The thread 0x3FC has exited with code 0 (0x0).

CL>Понятно, что где-то в программе забыл прочистить память. Конечно в общем случае все это неважно, т.к. теоретически ОС должна сама все отчистить. Есдинственное когда это важно, если ось 95/98/Me (они очищают толь теоретически; практически помогает только ребут) или программа должна непрерывно работать очень долго и утечки памяти могут повредить работе.

CL>Это все не про мой случай, однако хотелось бы написать программу, которая бы работала максимально корректно. И, соответственно, хотелось бы все эти leaks поймать. Но как? В окно Debug вываливается какая-то обкоцаная информация, типа "normal block at 0x00D01550, 4 bytes long". Чесно говоря, адрес 0x00D01550 мне ничего не говорит.

CL>Итак, есть ли какой-то способ поймать memory leaks

в программе? Т.е. получить конкретную информацию: для какой переменной память выделил, а убрать за собой забыл.

CL>Спасибо.

CL>P.S. Я конечно понимаю, что хочу слишком много и так не бывает. Однако, может быть хотя бы можно продвинуться подальше адреса 0x00D01550 способом более простым, чем смотреть адреса всех указателей

(программа довольно большая).

Здравствуйте CooLer, Вы писали:

CL>Итак, есть ли какой-то способ поймать memory leaks

в программе? Т.е. получить конкретную информацию: для какой переменной память выделил, а убрать за собой забыл.

CL>Спасибо.

CL>P.S. Я конечно понимаю, что хочу слишком много и так не бывает. Однако, может быть хотя бы можно продвинуться подальше адреса 0x00D01550 способом более простым, чем смотреть адреса всех указателей

(программа довольно большая).

Такой способ конечно же есть — использовать при отладке
Numega BoundsChecker (C++ edition)

Здравствуйте kaziboba, Вы писали:

K>Как это не важно чистить память? Если у тебя работает приложение, и оно отжирает память, то в конечном итоге машина будет тормозить.

Не, казибоба, ты не прав. Каждому процессу предоставляется свое адресное пространство, так что лики каждоко процесса влияют только на него, т. к. система очищает всю память из-под приложения после его работы. Правда это ДЕЙСТВИЬЕЛЬНО работает только в NT/2000/XP. За остальные не поручусь. Впрочем, это я уже говорил.

K>А чтобы поймать все лики, найди все операторы new в проекте, и засунь объекты которые создаются оператором new в смартптр :) С вероятностью 98% ликов не должно быть.

И как ты себе это представляешь? У меня в программе оператор new встречается 99 раз. И что я из-за пары глупых ликов буду перекапывать всю программу?

Итог: очень глупый совет. Оба. :down:

K>Здравствуйте CooLer, Вы писали:

CL>>В оладочном режиме после работы приложения в окошко Debug вываливается информация такого характрера:

CL>>

Detected memory leaks!
CL>>The thread 0x604 has exited with code 0 (0x0).
CL>>Dumping objects ->
CL>>thrdcore.cpp(166) : {227} client block at 0x00D03D70, subtype 0, 112 bytes long.
CL>>a CWinThread object at $00D03D70, 112 bytes long
CL>>{226} normal block at 0x00D01550, 4 bytes long.
CL>> Data: <    > 01 00 00 00 
CL>>{225} normal block at 0x00D02580, 1 bytes long.
CL>> Data: < > 0A 
CL>>F:\MyProjects\Wallpaper Magic\Wallpaper Magic.cpp(174) : {214} client block at 0x00D03E10, subtype 0, 476 bytes long.
CL>>a CMainFrame object at $00D03E10, 476 bytes long
CL>>Object dump complete.
CL>>The thread 0x3FC has exited with code 0 (0x0).

CL>>Понятно, что где-то в программе забыл прочистить память. Конечно в общем случае все это неважно, т.к. теоретически ОС должна сама все отчистить. Есдинственное когда это важно, если ось 95/98/Me (они очищают толь теоретически; практически помогает только ребут) или программа должна непрерывно работать очень долго и утечки памяти могут повредить работе.

CL>>Это все не про мой случай, однако хотелось бы написать программу, которая бы работала максимально корректно. И, соответственно, хотелось бы все эти leaks поймать. Но как? В окно Debug вываливается какая-то обкоцаная информация, типа "normal block at 0x00D01550, 4 bytes long". Чесно говоря, адрес 0x00D01550 мне ничего не говорит. ;)

CL>>Итак, есть ли какой-то способ поймать memory leaks :maniac: в программе? Т.е. получить конкретную информацию: для какой переменной память выделил, а убрать за собой забыл.

CL>>Спасибо.

CL>>P.S. Я конечно понимаю, что хочу слишком много и так не бывает. Однако, может быть хотя бы можно продвинуться подальше адреса 0x00D01550 способом более простым, чем смотреть адреса всех указателей :no: (программа довольно большая). :) :) :)

Здравствуйте kaziboba, Вы писали:

K>Как это не важно чистить память? Если у тебя работает приложение, и оно отжирает память, то в конечном итоге машина будет тормозить.

Не, казибоба, ты не прав. Каждому процессу предоставляется свое адресное пространство, так что лики каждоко процесса влияют только на него, т. к. система очищает всю память из-под приложения после его работы. Правда это ДЕЙСТВИЬЕЛЬНО работает только в NT/2000/XP. За остальные не поручусь. Впрочем, это я уже говорил.

K>А чтобы поймать все лики, найди все операторы new в проекте, и засунь объекты которые создаются оператором new в смартптр :) С вероятностью 98% ликов не должно быть.

И как ты себе это представляешь? У меня в программе оператор new встречается 99 раз. И что я из-за пары глупых ликов буду перекапывать всю программу?

Итог: очень глупый совет. Оба. :down:

K>Здравствуйте CooLer, Вы писали:

CL>>В оладочном режиме после работы приложения в окошко Debug вываливается информация такого характрера:

CL>>

Detected memory leaks!
CL>>The thread 0x604 has exited with code 0 (0x0).
CL>>Dumping objects ->
CL>>thrdcore.cpp(166) : {227} client block at 0x00D03D70, subtype 0, 112 bytes long.
CL>>a CWinThread object at $00D03D70, 112 bytes long
CL>>{226} normal block at 0x00D01550, 4 bytes long.
CL>> Data: <    > 01 00 00 00 
CL>>{225} normal block at 0x00D02580, 1 bytes long.
CL>> Data: < > 0A 
CL>>F:\MyProjects\Wallpaper Magic\Wallpaper Magic.cpp(174) : {214} client block at 0x00D03E10, subtype 0, 476 bytes long.
CL>>a CMainFrame object at $00D03E10, 476 bytes long
CL>>Object dump complete.
CL>>The thread 0x3FC has exited with code 0 (0x0).

CL>>Понятно, что где-то в программе забыл прочистить память. Конечно в общем случае все это неважно, т.к. теоретически ОС должна сама все отчистить. Есдинственное когда это важно, если ось 95/98/Me (они очищают толь теоретически; практически помогает только ребут) или программа должна непрерывно работать очень долго и утечки памяти могут повредить работе.

CL>>Это все не про мой случай, однако хотелось бы написать программу, которая бы работала максимально корректно. И, соответственно, хотелось бы все эти leaks поймать. Но как? В окно Debug вываливается какая-то обкоцаная информация, типа "normal block at 0x00D01550, 4 bytes long". Чесно говоря, адрес 0x00D01550 мне ничего не говорит. ;)

CL>>Итак, есть ли какой-то способ поймать memory leaks :maniac: в программе? Т.е. получить конкретную информацию: для какой переменной память выделил, а убрать за собой забыл.

CL>>Спасибо.

CL>>P.S. Я конечно понимаю, что хочу слишком много и так не бывает. Однако, может быть хотя бы можно продвинуться подальше адреса 0x00D01550 способом более простым, чем смотреть адреса всех указателей :no: (программа довольно большая). :) :) :)

Здравствуйте CooLer, Вы писали:

А воспользоватся поиском?

http://www.rsdn.ru/?article/?vcpp/leaks.xml

Вобще-то есть несколько вариантов:
1. самый простой — воспользоватся боундс чекером от NuMega
2. перегрузить оператор new чтобы обеспечить контроль за выделяемой и освобождаемой памятью
3. стараться везде пользоваться смарт поинтерами (std::auto_ptr<>)
........

вобщем удачи.

Поищи здесь на сайте по ключевым словам "memory leaks" и "smart pointer", найдёшь кучу полезной информации, так-как эта тема уже не раз затрагивалась

Нет Cooler. Больше никому не говори то, что написал мне. Засмеют. Адресное протранство для каждого процесса одно, но память одна на всех. Ну сам подумай.

А по поводу второго совета скажу одно, когда оперируешь тысячами объектов, какая-то сотня, просто фигня. Одним словом не обижайся, но ты не прав. Опыта наберёшся, поймешь.

Здравствуйте CooLer, Вы писали:

CL>Здравствуйте kaziboba, Вы писали:

K>>Как это не важно чистить память? Если у тебя работает приложение, и оно отжирает память, то в конечном итоге машина будет тормозить.

CL>Не, казибоба, ты не прав. Каждому процессу предоставляется свое адресное пространство, так что лики каждоко процесса влияют только на него, т. к. система очищает всю память из-под приложения после его работы. Правда это ДЕЙСТВИЬЕЛЬНО работает только в NT/2000/XP. За остальные не поручусь. Впрочем, это я уже говорил.

K>>А чтобы поймать все лики, найди все операторы new в проекте, и засунь объекты которые создаются оператором new в смартптр :) С вероятностью 98% ликов не должно быть.

CL>И как ты себе это представляешь? У меня в программе оператор new встречается 99 раз. И что я из-за пары глупых ликов буду перекапывать всю программу?

CL>Итог: очень глупый совет. Оба. :down:

K>>Здравствуйте CooLer, Вы писали:

CL>>>В оладочном режиме после работы приложения в окошко Debug вываливается информация такого характрера:

CL>>>

Detected memory leaks!
CL>>>The thread 0x604 has exited with code 0 (0x0).
CL>>>Dumping objects ->
CL>>>thrdcore.cpp(166) : {227} client block at 0x00D03D70, subtype 0, 112 bytes long.
CL>>>a CWinThread object at $00D03D70, 112 bytes long
CL>>>{226} normal block at 0x00D01550, 4 bytes long.
CL>>> Data: <    > 01 00 00 00 
CL>>>{225} normal block at 0x00D02580, 1 bytes long.
CL>>> Data: < > 0A 
CL>>>F:\MyProjects\Wallpaper Magic\Wallpaper Magic.cpp(174) : {214} client block at 0x00D03E10, subtype 0, 476 bytes long.
CL>>>a CMainFrame object at $00D03E10, 476 bytes long
CL>>>Object dump complete.
CL>>>The thread 0x3FC has exited with code 0 (0x0).

CL>>>Понятно, что где-то в программе забыл прочистить память. Конечно в общем случае все это неважно, т.к. теоретически ОС должна сама все отчистить. Есдинственное когда это важно, если ось 95/98/Me (они очищают толь теоретически; практически помогает только ребут) или программа должна непрерывно работать очень долго и утечки памяти могут повредить работе.

CL>>>Это все не про мой случай, однако хотелось бы написать программу, которая бы работала максимально корректно. И, соответственно, хотелось бы все эти leaks поймать. Но как? В окно Debug вываливается какая-то обкоцаная информация, типа "normal block at 0x00D01550, 4 bytes long". Чесно говоря, адрес 0x00D01550 мне ничего не говорит. ;)

CL>>>Итак, есть ли какой-то способ поймать memory leaks :maniac: в программе? Т.е. получить конкретную информацию: для какой переменной память выделил, а убрать за собой забыл.

CL>>>Спасибо.

CL>>>P.S. Я конечно понимаю, что хочу слишком много и так не бывает. Однако, может быть хотя бы можно продвинуться подальше адреса 0x00D01550 способом более простым, чем смотреть адреса всех указателей :no: (программа довольно большая). :) :) :)

Эпиграф: С дураком возиться, что в крапиву срать садиться.Народная мудрость.

Итак, казибоба, ты пытаешься доказать, что память одна на всех. Ну что же, спорить трудно, память действительно одна на всех. Но память тоже разная бывает. :-\

Итак, разберемся подробнее. Начнем с того, что Windows 32-разрядная операционная система и работает в защищенном режиме процессора. (Судя по твоим высказываниям ты можешь не знать даже таких простых вещей :)) )

Теперь дальше. Помимо обычной памяти, которой всегда мало Windows использует т.н. файл подкачки. Поэтому памяти получается довольно много.

Теперь подходим к самому интересному. Созданию процесса. Итак, при создании процесса система выделяет опеределенное количество памяти (обычно это несколько гигабайт), затем загружает туда код из исполняемого файла, туда же складывает все используемые DLL, создает HANDLE процесса, затем создает первый поток со своим HANDLE-ом. С этого момента процесс считается выполняющимся и его потокам начинает выделятся процессорное время. Замечу, что в Микрософт я не работаю, поэтому в описаном выше алгоритме могут быть допущены некоторые ошибки (весьма незначительные :shuffle: ).

Зачем же я все это рассказывал? Обрати внимание: процессу выделяется отдельное адресное пространство, в котором размещается весь исполняемый код, а также стек и куча. Это адресное пространство отдельное у каждого процесса и в общем случае потоки процесса работают работают исключительно со своим адресным пространством. Да, не спорю, можно залезть и в чужое, но это уже с memory leaks (а значит и с обсуждаемой темой) никак не связано. Т.е. операции типа new/delete работают только со своей кучей. И только так.

Теперь поговорим о завершении процессов. После того как умерли все потоки процесса, система начинает погребение процесса. Для этого уменьшаются счетчики DLL, высвобождаются занятые ресурсы (мьютексы, файлы и т.п.) и т.д. После завершения всего этого, все адресное пространство процесса высвобождается. Т.е. все memory leaks, были они или нет, просто перестают существовать вместе с процессом. :)))

Правда все это верно только для Windows NT/2000/XP, т.к. ОСи все-таки серверные и ядро у них соответствующее. А вот в Windows 95/98/Me ядро фиговенькое, поэтому один процесс может испоганить всю систему. Спорим на ящик пива, что у тебя Windows 95/98/Me! :-\ (А может и вобще 3.11 :))) )

Итак, надеюсь я смог продемонстрировать тебе всю твою ущербность и умственную неполноценность. :)
Учится тебе еще и учится, ламушок ;)

Кстати, а ты читал Рихтера? Могу поспорить, что не только не читал, но и не слышал о таком. Ну, признайся чесно! ;)

Эпилог: Дурака учить, что мертвого лечить.Народная мудрость.

Спасибо большое за ответ! (Приятно умного человека послушать, не то что этого казибобу!)

Сразу нашелся вредный leak. Оказывается CWinApp::GetProfileBinary выделяет память, которую надо потом удалять! А я как-то и не думал об этом...

Правда два memory leaks починить не удалось: это экземпляры классов CWinThread и CMainFrame. Видимо при звершении приложения не вызывается MFC код, который отвечает за их убиение (я вызываю PostQuitmessage). Подскажите, затрагивалась ли такая тема?
Еще раз спасибо.

YS>Здравствуйте CooLer, Вы писали:

YS>А воспользоватся поиском?

YS>http://www.rsdn.ru/?article/?vcpp/leaks.xml

YS>Вобще-то есть несколько вариантов:
YS>1. самый простой — воспользоватся боундс чекером от NuMega
YS>2. перегрузить оператор new чтобы обеспечить контроль за выделяемой и освобождаемой памятью
YS>3. стараться везде пользоваться смарт поинтерами (std::auto_ptr<>)
YS>........

YS>вобщем удачи.

YS>Поищи здесь на сайте по ключевым словам "memory leaks" и "smart pointer", найдёшь кучу полезной информации, так-как эта тема уже не раз затрагивалась

Здравствуйте CooLer, Вы писали:

CL>Эпиграф: С дураком возиться, что в крапиву срать садиться.Народная мудрость.

[skip]

CL>Итак, надеюсь я смог продемонстрировать тебе всю твою ущербность и умственную неполноценность.

CL>Учится тебе еще и учится, ламушок

CL>Кстати, а ты читал Рихтера? Могу поспорить, что не только не читал, но и не слышал о таком. Ну, признайся чесно!

CL>Эпилог: Дурака учить, что мертвого лечить.Народная мудрость.

Кулер, либо ты извиняешься и больше так не будешь, либо я баню все твои ip-шники и ты больше сайта не видишь.

Многоуважаемый казибоба! Приношу вам свои извинения за грубые выражения, использованные по отношению к вам. Обещаю, что больше этого не повториться.

P.S. А все же, по поводу процессов я прав, а?

Ладно, перед казибобй извинился. Теперь хочу извиниться перед остальными участниками форума, которые читали это сообщение. Действительно, погорячился. Но поймите, этот... хм... товарищ... объясняет мне то, что сам плохо понимает. Причем пишет: "Опыта наберёшся, поймешь". Слюшай, абыдна, чесслово! Вот я ему вкраце объяснил что к чему. Хотя, согласен, можно было и без грубостей.

А все-таки, уважаемый IT, рассудите: кто прав? Вы же серьезный человек, вероятно программист, должны же знать!

А IP банить не надо... Я без этого сайта пропаду. Тем более что айпишник у меня статический...

Здравствуйте CooLer, Вы писали:

CL>Ладно, перед казибобй извинился. Теперь хочу извиниться перед остальными участниками форума, которые читали это сообщение. Действительно, погорячился. Но поймите, этот... хм... товарищ... объясняет мне то, что сам плохо понимает. Причем пишет: "Опыта наберёшся, поймешь". Слюшай, абыдна, чесслово! Вот я ему вкраце объяснил что к чему. Хотя, согласен, можно было и без грубостей.

CL>А все-таки, уважаемый IT, рассудите: кто прав? Вы же серьезный человек, вероятно программист, должны же знать!

CL>А IP банить не надо... Я без этого сайта пропаду. Тем более что айпишник у меня статический...

Тебе б кстати самому не мешало бы Рихтера перечитать...
В той пурге что ты нагнал про процессы и адресные пространства внятно прозвучали только оскорбления в адрес казибобы...

Здравствуйте CooLer, Вы писали:

CL>Здравствуйте kaziboba, Вы писали:

K>>Как это не важно чистить память? Если у тебя работает приложение, и оно отжирает память, то в конечном итоге машина будет тормозить.

CL>Не, казибоба, ты не прав. Каждому процессу предоставляется свое адресное пространство, так что лики каждоко процесса влияют только на него, т. к. система очищает всю память из-под приложения после его работы. Правда это ДЕЙСТВИЬЕЛЬНО работает только в NT/2000/XP. За остальные не поручусь. Впрочем, это я уже говорил.

K>>А чтобы поймать все лики, найди все операторы new в проекте, и засунь объекты которые создаются оператором new в смартптр

С вероятностью 98% ликов не должно быть.

CL>И как ты себе это представляешь? У меня в программе оператор new встречается 99 раз. И что я из-за пары глупых ликов буду перекапывать всю программу?

Так делай выводы и используй smart-поинтеры с самого начала

Здравствуйте CooLer, Вы писали:

CL>Эпиграф: С дураком возиться, что в крапиву срать садиться.Народная мудрость.

CL>Итак, казибоба, ты пытаешься доказать, что память одна на всех. Ну что же, спорить трудно, память действительно одна на всех. Но память тоже разная бывает.

CL>Итак, разберемся подробнее. Начнем с того, что Windows 32-разрядная операционная система и работает в защищенном режиме процессора. (Судя по твоим высказываниям ты можешь не знать даже таких простых вещей

)

CL>Теперь дальше. Помимо обычной памяти, которой всегда мало Windows использует т.н. файл подкачки. Поэтому памяти получается довольно много.

CL>Теперь подходим к самому интересному. Созданию процесса. Итак, при создании процесса система выделяет опеределенное количество памяти (обычно это несколько гигабайт), затем загружает туда код из исполняемого файла, туда же складывает все используемые DLL, создает HANDLE процесса, затем создает первый поток со своим HANDLE-ом. С этого момента процесс считается выполняющимся и его потокам начинает выделятся процессорное время. Замечу, что в Микрософт я не работаю, поэтому в описаном выше алгоритме могут быть допущены некоторые ошибки (весьма незначительные

).

CL>Зачем же я все это рассказывал? Обрати внимание: процессу выделяется отдельное адресное пространство, в котором размещается весь исполняемый код, а также стек и куча. Это адресное пространство отдельное у каждого процесса и в общем случае потоки процесса работают работают исключительно со своим адресным пространством. Да, не спорю, можно залезть и в чужое, но это уже с memory leaks (а значит и с обсуждаемой темой) никак не связано. Т.е. операции типа new/delete работают только со своей кучей. И только так.

CL>Теперь поговорим о завершении процессов. После того как умерли все потоки процесса, система начинает погребение процесса. Для этого уменьшаются счетчики DLL, высвобождаются занятые ресурсы (мьютексы, файлы и т.п.) и т.д. После завершения всего этого, все адресное пространство процесса высвобождается. Т.е. все memory leaks, были они или нет, просто перестают существовать вместе с процессом.

CL>Правда все это верно только для Windows NT/2000/XP, т.к. ОСи все-таки серверные и ядро у них соответствующее. А вот в Windows 95/98/Me ядро фиговенькое, поэтому один процесс может испоганить всю систему. Спорим на ящик пива, что у тебя Windows 95/98/Me!

(А может и вобще 3.11

)

CL>Итак, надеюсь я смог продемонстрировать тебе всю твою ущербность и умственную неполноценность.

CL>Учится тебе еще и учится, ламушок

CL>Кстати, а ты читал Рихтера? Могу поспорить, что не только не читал, но и не слышал о таком. Ну, признайся чесно!

CL>Эпилог: Дурака учить, что мертвого лечить.Народная мудрость.

Читал и плевался — чего ты такой агрессивный (кстати, не только ты)

Солнечная активность, что ли, влияет. Если что-то имеешь против, то просто скажи это. Неужели надо обязательно человека оскорблять

Ты вот сам-то что-нибудь кроме ихтера прочитал... Действительно, "наберьшься опыта — поймешь", что нельзя так с людьми

Здравствуйте CooLer, Вы писали:

CL>P.S. А все же, по поводу процессов я прав, а?

По поводу процессов у меня к тебе особых претензий не было

Здравствуйте CooLer, Вы писали:

CL>А все-таки, уважаемый IT, рассудите: кто прав? Вы же серьезный человек, вероятно программист, должны же знать!

Возможно и программист, может и знаю, но ни за знания, ни за незнания тут никто ни на кого не наезжает.

Вы с казибобой оба хороши.

K>Адресное протранство для каждого процесса одно, но память одна на всех.

Выражаться надо точнее. Адресное пространсво и память по большому счёту это одно и тоже. Даже по маленькому между ними разницы почти нет. Можно даже сказать, что процессу выделяется виртуальная память из физического адресного пространства.

CL>Теперь дальше. Помимо обычной памяти, которой всегда мало Windows использует т.н. файл подкачки. Поэтому памяти получается довольно много.

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

CL>Теперь подходим к самому интересному. Созданию процесса. Итак, при создании процесса система выделяет опеределенное количество памяти (обычно это несколько гигабайт),...

Это не верно с самого начала. Система не может выделить несколько гигабайт памяти для каждой задачи. Система создаёт адресное пространство для процесса (ну типа записывает у себя на бумажке, что этому чуваку выделено 2 гига) и резервирует в нём регион адресов размером, достаточным для загрузки EXE модуля. Никакая физическая память при этом ещё не трогается.

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

CL>затем загружает туда код из исполняемого файла, туда же складывает все используемые DLL, создает HANDLE процесса, затем создает первый поток со своим HANDLE-ом. С этого момента процесс считается выполняющимся и его потокам начинает выделятся процессорное время. Замечу, что в Микрософт я не работаю, поэтому в описаном выше алгоритме могут быть допущены некоторые ошибки (весьма незначительные

).

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

[skip]

CL>Теперь поговорим о завершении процессов. После того как умерли все потоки процесса, система начинает погребение процесса. Для этого уменьшаются счетчики DLL, высвобождаются занятые ресурсы (мьютексы, файлы и т.п.) и т.д. После завершения всего этого, все адресное пространство процесса высвобождается. Т.е. все memory leaks, были они или нет, просто перестают существовать вместе с процессом.

Тут трудно с чем-то поспорить.

CL>Правда все это верно только для Windows NT/2000/XP, т.к. ОСи все-таки серверные и ядро у них соответствующее. А вот в Windows 95/98/Me ядро фиговенькое, поэтому один процесс может испоганить всю систему. Спорим на ящик пива, что у тебя Windows 95/98/Me!

(А может и вобще 3.11

)

Оно не фиговенькое, оно совместименькое с MS DOS. Знаешь такую операционку?

BTW, ничего подобного по своим масштабам никогда ещё не было и вряд ли уже будет. За 7-8 лет неутомимые программеры наколбасили столько разнообразного кода для реального режима процессора, что сделать операционку, обеспечивающую приемлемую с ним совместимость могла только MS со своими бабками и многотысячным штатом программеров.

CL>Кстати, а ты читал Рихтера? Могу поспорить, что не только не читал, но и не слышал о таком. Ну, признайся чесно!

Давай-ка, и ты тоже достань его с полки, стряхни пыль и перечитай любимые главы

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

Здравствуйте CooLer, Вы писали:

CL>Многоуважаемый казибоба! Приношу вам свои извинения за грубые выражения, использованные по отношению к вам. Обещаю, что больше этого не повториться.

CL>P.S. А все же, по поводу процессов я прав, а?

Нет.

Твои фактические ошибки в описании механима IT уже описал (неужели действительно программист?

), но главного почему-то не сказал.

Я думаю, что под словом "память" уважаемый kaziboba имел ввиду оперативную память и файлы подкачки, которые действительно одни на всех (даже на Win 2000, честное слово). И, как обычно, чем больше общесистемных ресурсов (в данном случае памяти) занимает твоя программа, тем меньше остаётся остальным... Как на производительность системы влияет забивание оперативки понятно, наверное, всем, с файломи подкачки сложнее. Тестов не проводил, но, сомневаюсь, что от распухания файлов подкачки система будет работать быстрее. Они всё-таки не просто так лежат на диске, система их иногда читает, пишет и т.д.

P.S. А чего ты так наезжаешь на ядро Win 9x? Ты его дизассемблировал и обнаружил, все те ужастные факты о которых поведал нам? Если нет, то перед Microsoft извиняться необязательно (разве что IT попросит

), но на будующее таких реплик лучше не кидать.

P.P.S. Я пишу о файлах подкачки во множественном числе для большей академичности. Люди говорят что их можно сделать несколько и раскидать по разным дискам для ускорения работы. Но даже в этом случае это будет общесистемный ресурс, а не отдельный на каждый процесс.

Я прописал в InitInstance() строчку:

_CrtSetReportMode( _CRT_ERROR, _CRTDBG_MODE_DEBUG );

Где-то здесь кстати и вычитал. При компиляции моя прога выдает несколько memory leaks на оператор new, хотя он точно удаляется оператором delete. Что вы на это скажете, уважаемые?

От:	CooLer	http://bestsoft.far.ru
Дата:	31.07.02 15:27
Оценка:

	От:	kaziboba
	Дата:	31.07.02 16:01
	Оценка:	18 (1)

	От:	a70
	Дата:	31.07.02 16:50
	Оценка:	4 (1)

	От:	xpl0rer
	Дата:	31.07.02 16:55
	Оценка:	4 (1)

	От:	Аноним
	Дата:	31.07.02 16:59
	Оценка:

От:	YuriS	www.yuris.de
Дата:	31.07.02 18:25
Оценка:	6 (1)

От:	IT	linq2db.com
Дата:	31.07.02 22:00
Оценка:	57 (4)

От:	Vovkos	https://ioninja.com
Дата:	31.07.02 22:50
Оценка:

	От:	Reverend JAHncle
	Дата:	01.08.02 05:47
	Оценка: