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

S>Есть локальный COM сервер на ATL.
S>Внутри используется WinHTTP, MSXML.
WinHTTP редкостное УГ.
Когда-то давно делал на нем простой клиент к ftp, были тормоза, обрывы связи (отваливалось с ошибкой "не могу соединиться" через раз).
Заменил на чуть ли не скачанную с кодепроджекта библиотеку, обернул в COM (чтобы воткнулось вместо текущего когда) — и все залетало и заработало как часы.

Если соберешься переписывать на что-то другое, то сейчас лучше всего CURL.
Ну и вместо MSXML взять, например, pugixml.

>Собственно вопрос — можно ли найти причину такого роста памяти? может в WinHTTP есть какие-то буфера или файлы выгружаются из памяти не сразу...
А в чем собственно сакральная ценность такого рода знания?

Если нужно понять есть ли утечки памяти я бы сделал по тупому — поставил на ночь (сутки, двое) работать и врубил perfmon на private set Вашего
процесса — если в результате тренд будет горизантальный (т.е. растет, падает до предыдущего уровня и снова) то волноваться не о чем.
Если растет и падает, но чуток выше чем было и так постоянно — то есть проблемы.

Для утечек COM памяти есть простенький StackWalker (наверное есть что то лучше, просто всегда его пользовал).

Для WinAPI незнаю ничего лучше чем проверить все места пользования.

Хэндлеры посмотреть в том же ProcessExlorer.

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

S>т.е. память время от времени очищается. это я заметил и раньше.
S>А если ждущий режим приводит к очищению памяти, то что это может быть? политика ОС? Если бы это были буфера WinHTTP, например — то они бы сохранились, наверное...
Ну все-таки вы видите только подгруженные странички(динамику их подгрузки/выгрузки). Реальной информации об использовании памяти это не дает. В таких случаях лучше смотреть количество виртуальной памяти для процесса(например в висте Commit size в таск менеджере). Это тоже не дает реальной инфы по использованию, но несколько ближе. Это значение если и уменьшается, то только если страницы освободили, а не выгрузили на диск.

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

S>Есть ли в сети какой пример класса с их использованием. сходу не нашел...
Дело было 3 года назад, сразу и не нашел тот проект. В целом все просто, вот кусок кода, остальное в MSDN очень подробно описано.
По именам классов легко найдешь остальное, здесь очень маленькая часть.
// ---------------------------------------------------------------------- CDownload
// Класс реализующий обмен информацией между клиентом и сервером
class CDownload {
public:
CDownload();
~CDownload();

HRESULT DoDownload(HWND, HWND, HWND, HWND, HWND, int);
HRESULT DoUpload(HWND, HWND, HWND, HWND, HWND, int);

LPCWSTR m_url;

private:
IMoniker* m_pMoniker;
IBindCtx* m_pBindCtx;
IBindStatusCallback* m_pBindStatusCallback;
};

//------------------------------------------------------------------------ CBindStatusCallback
class CBindStatusCallback : public IBindStatusCallback, IAuthenticate, IHttpNegotiate
{
public:
// IUnknown methods
STDMETHODIMP QueryInterface(REFIID riid,void ** ppv);
STDMETHODIMP_(ULONG) AddRef() { return m_cRef++; }
STDMETHODIMP_(ULONG) Release() { if (--m_cRef == 0) { delete this; return 0; } return m_cRef; }

// IBindStatusCallback methods
STDMETHODIMP OnStartBinding(DWORD dwReserved, IBinding* pbinding);
STDMETHODIMP GetPriority(LONG* pnPriority);
STDMETHODIMP OnLowResource(DWORD dwReserved);
STDMETHODIMP OnProgress(ULONG ulProgress, ULONG ulProgressMax, ULONG ulStatusCode,
LPCWSTR pwzStatusText);
STDMETHODIMP OnStopBinding(HRESULT hrResult, LPCWSTR szError);
STDMETHODIMP GetBindInfo(DWORD* pgrfBINDF, BINDINFO* pbindinfo);
STDMETHODIMP OnDataAvailable(DWORD grfBSCF, DWORD dwSize, FORMATETC *pfmtetc,
STGMEDIUM* pstgmed);
STDMETHODIMP OnObjectAvailable(REFIID riid, IUnknown* punk);
STDMETHODIMP BeginningTransaction( /* [in] */ LPCWSTR szURL,
/* [unique][in] */ LPCWSTR szHeaders,
/* [in] */ DWORD dwReserved,
/* [out] */ LPWSTR __RPC_FAR *pszAdditionalHeaders);
STDMETHODIMP OnResponse( /* [in] */ DWORD dwResponseCode,
/* [unique][in] */ LPCWSTR szResponseHeaders,
/* [unique][in] */ LPCWSTR szRequestHeaders,
/* [out] */ LPWSTR __RPC_FAR *pszAdditionalRequestHeaders);

STDMETHOD(Authenticate)(/* [out] */ HWND __RPC_FAR *phwnd,
/* [out] */ LPWSTR __RPC_FAR *pszUsername,
/* [out] */ LPWSTR __RPC_FAR *pszPassword);

CBindStatusCallback(HWND hwndStatus,
HWND hwndProgress,
HWND hwndText,
HWND hwndProgressBar,
HWND hwndTreeView,
int isView);
~CBindStatusCallback();

inline void SetStatus(LPCWSTR szStatus) { SetWndText(m_hwndStatus, szStatus); }
void SetProgress(LPCWSTR szProgress) { SetWndText(m_hwndProgress, szProgress); }
void SetProgressBar(ULONG cProgress, ULONG maxProgress)
{
SendMessage(m_hwndProgressBar,
PBM_SETRANGE,
0,
100);
SendMessage(m_hwndProgressBar,
PBM_SETPOS,
(WPARAM) (maxProgress ? cProgress * 100 / maxProgress : 0),
0);
}
void SetWndText(HWND hwnd, LPCWSTR szText);

void SetTreeView(DWORD);
void DrawingShot(DWORD);

// data members
public:
DWORD m_cRef;
IBinding* m_pbinding;
IStream* m_pstm;
HWND m_hwndStatus; //
HWND m_hwndProgress;
HWND m_hwndText;
HWND m_hwndProgressBar;
HWND m_hwndTreeView;
int m_isView;
DWORD m_cbOld;

};
//------------------------------------------------------------- CBindStatusCallback::CBindStatusCallback
CBindStatusCallback::CBindStatusCallback(HWND hwndStatus,
HWND hwndProgress,
HWND hwndText,
HWND hwndProgressBar,
HWND hwndTreeView)

{
m_hwndStatus = hwndStatus;
m_hwndProgress = hwndProgress;
m_hwndText = hwndText;
m_hwndProgressBar = hwndProgressBar;
m_hwndTreeView = hwndTreeView;
m_pbinding = NULL;
m_pstm = NULL;
m_cRef = 1;
m_cbOld = 0;

m_BufRead = new char[MAX_LIMIT_SHOT];
m_BufInput = new char[MAX_LIMIT_SHOT];
}
// ---------------------------------------------------------------------------
CBindStatusCallback::~CBindStatusCallback()
{
delete(m_BufRead);
delete(m_BufInput);
}

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

S>а они в свою очередь также копируются в процессе перечисления(каждый объект — COM и у него есть метод get_id(BSTR*) ).. т.о. на 50 объектов — до 2500 аллокаций строк(BSTR).. и так до нескольких раз в минуту))
Брррр. Может у вас комовские строки текут?) используйте _bstr_t или CComBSTR. Тогда не удивительно почему вы не ловите мемлики — этм строки алоцируются с помощью SysAllocString

S>Так... что можно сделать..
S>- Сравнения оптимизируем..
используйте _bstr_t или CComBSTR
S>- Xml.. может есть xml бесплатная либа, которая менее интенсиво использует кучу чем msxml?
pugixml или накрайняк tinyxml
S>- А что такое настройки прожорливости crt-шного хипа? и как их можно настроить..
Вряд ли там что-то настроить можно, да и проблема не в нем

CS>>Нужно убедиться что это не твое точно.
CS>>Скажем дампить количесвто и объем аллокаций и/или объектов.

S>О.
S>А как это сделать? и можно ли при этом знать место(на стеке), где эта аллокация происходит.

umdh + настроенные символы. И не забыть отключить апп верифайер после использования.

Есть локальный COM сервер на ATL.
Внутри используется WinHTTP, MSXML.

Сервер время от времени(до нескольких раз в минуту) качает xml-ку из интернета.
Данные, которые одновременно хранятся на сервере занимают 300-400 кб максимум(примерно).

вначале exe-шник занимает 3-4 метра.
в течении 2-3 часов он растет до 20-23 метров. потом освобождается до 10-12 и опять растет.

в сервере 80 длл я насчитал, но вначале их даже больше(смотрел process explorer-ом)

Собственно вопрос — можно ли найти причину такого роста памяти? может в WinHTTP есть какие-то буфера или файлы выгружаются из памяти не сразу...
Средствами отладки CRT — ликов нет. Для хендлов файлов используются умные указатели — тоже не должно быть ликов.
С COM объектами — тоже вроде все нормально, если бы количество AddRef/Release не совпадало — сервер бы зависал при выходе, такое уже было.

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

S>Собственно вопрос — можно ли найти причину такого роста памяти?

Нужно убедиться что это не твое точно.
Скажем дампить количесвто и объем аллокаций и/или объектов.

S>может в WinHTTP есть какие-то буфера или файлы выгружаются из памяти не сразу...

Может сегодня есть, а может заватра уже нет. Т.е. тебе это знание ну никак не поможет.

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

CS>Нужно убедиться что это не твое точно.
CS>Скажем дампить количесвто и объем аллокаций и/или объектов.

О.
А как это сделать? и можно ли при этом знать место(на стеке), где эта аллокация происходит.

S>>может в WinHTTP есть какие-то буфера или файлы выгружаются из памяти не сразу...

CS>Может сегодня есть, а может заватра уже нет. Т.е. тебе это знание ну никак не поможет.

Помогло бы локализовать рост памяти. знать, что это? политика ОС или настраиваемая фича.

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

S>Здравствуйте, c-smile, Вы писали:

CS>>Нужно убедиться что это не твое точно.
CS>>Скажем дампить количесвто и объем аллокаций и/или объектов.

S>О.
S>А как это сделать? и можно ли при этом знать место(на стеке), где эта аллокация происходит.
http://www.rsdn.ru/article/vcpp/leaks.xml

Автор(ы): Эдвард Райт

Статья посвящена проблеме, которая постоянно преследует программистов на C/C++, — обнаружению и локализации утечек памяти. Автор демонстрирует применение средств библиотеки времени выполнения (CTR), поставляемой с Visual C++, с помощью которых утечки памяти можно устранить гораздо быстрее и проще, чем методом "пристального взгляда".

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

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

S>>Здравствуйте, c-smile, Вы писали:

CS>>>Нужно убедиться что это не твое точно.
CS>>>Скажем дампить количесвто и объем аллокаций и/или объектов.

S>>О.
S>>А как это сделать? и можно ли при этом знать место(на стеке), где эта аллокация происходит.
G_>http://www.rsdn.ru/article/vcpp/leaks.xml

Автор(ы): Эдвард Райт

Статья посвящена проблеме, которая постоянно преследует программистов на C/C++, — обнаружению и локализации утечек памяти. Автор демонстрирует применение средств библиотеки времени выполнения (CTR), поставляемой с Visual C++, с помощью которых утечки памяти можно устранить гораздо быстрее и проще, чем методом "пристального взгляда".

Спасибо, уже проверил — ничего нет(это я и имел ввиду в первом посте под "Средствами отладки CRT — ликов нет").

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

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

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

S>>>Здравствуйте, c-smile, Вы писали:

CS>>>>Нужно убедиться что это не твое точно.
CS>>>>Скажем дампить количесвто и объем аллокаций и/или объектов.

S>>>О.
S>>>А как это сделать? и можно ли при этом знать место(на стеке), где эта аллокация происходит.
G_>>http://www.rsdn.ru/article/vcpp/leaks.xml

Автор(ы): Эдвард Райт

Статья посвящена проблеме, которая постоянно преследует программистов на C/C++, — обнаружению и локализации утечек памяти. Автор демонстрирует применение средств библиотеки времени выполнения (CTR), поставляемой с Visual C++, с помощью которых утечки памяти можно устранить гораздо быстрее и проще, чем методом "пристального взгляда".

S>Спасибо, уже проверил — ничего нет(это я и имел ввиду в первом посте под "Средствами отладки CRT — ликов нет").
Ну тогда только менять WinHTTP остается.
Кстати, замеры делали по количеству виртуальной памяти или по физическим страницам?

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

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

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

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

S>>>>Здравствуйте, c-smile, Вы писали:

CS>>>>>Нужно убедиться что это не твое точно.
CS>>>>>Скажем дампить количесвто и объем аллокаций и/или объектов.

S>>>>О.
S>>>>А как это сделать? и можно ли при этом знать место(на стеке), где эта аллокация происходит.
G_>>>http://www.rsdn.ru/article/vcpp/leaks.xml

Автор(ы): Эдвард Райт

Статья посвящена проблеме, которая постоянно преследует программистов на C/C++, — обнаружению и локализации утечек памяти. Автор демонстрирует применение средств библиотеки времени выполнения (CTR), поставляемой с Visual C++, с помощью которых утечки памяти можно устранить гораздо быстрее и проще, чем методом "пристального взгляда".

S>>Спасибо, уже проверил — ничего нет(это я и имел ввиду в первом посте под "Средствами отладки CRT — ликов нет").
G_>Ну тогда только менять WinHTTP остается.
G_>Кстати, замеры делали по количеству виртуальной памяти или по физическим страницам?

Я делал только то, что описано в статье — объявлял макрос _CRTDBG_MAP_ALLOC. Делал тестовый лик, чтобы убедится, что все работает. по завершении программы — никаких ликов нет(В конце Leaks detected! не пишет в окне дебага).

Насчет памяти — смотрел только по диспетчеру задач) — эта колонка называется "Память(частный рабочий набор)" в 7-ке.
А что может дать распределение памяти по физической/виртуальной?

Насчет WinHTTP — локализовать хотябы, кто память выделяет.
какими средствами это можно сделать? можно, например, отслеживать каждое выделение памяти и знать при этом стек?

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

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

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

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

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

S>>>>>Здравствуйте, c-smile, Вы писали:

CS>>>>>>Нужно убедиться что это не твое точно.
CS>>>>>>Скажем дампить количесвто и объем аллокаций и/или объектов.

S>>>>>О.
S>>>>>А как это сделать? и можно ли при этом знать место(на стеке), где эта аллокация происходит.
G_>>>>http://www.rsdn.ru/article/vcpp/leaks.xml

Автор(ы): Эдвард Райт

Статья посвящена проблеме, которая постоянно преследует программистов на C/C++, — обнаружению и локализации утечек памяти. Автор демонстрирует применение средств библиотеки времени выполнения (CTR), поставляемой с Visual C++, с помощью которых утечки памяти можно устранить гораздо быстрее и проще, чем методом "пристального взгляда".

S>>>Спасибо, уже проверил — ничего нет(это я и имел ввиду в первом посте под "Средствами отладки CRT — ликов нет").
G_>>Ну тогда только менять WinHTTP остается.
G_>>Кстати, замеры делали по количеству виртуальной памяти или по физическим страницам?

S>Я делал только то, что описано в статье — объявлял макрос _CRTDBG_MAP_ALLOC. Делал тестовый лик, чтобы убедится, что все работает. по завершении программы — никаких ликов нет(В конце Leaks detected! не пишет в окне дебага).

То что не течет CRT еще не значит, что не течет что то другое
Нужно проверить еще COM память! Так же еще может течь какие-нить WinAPI функции требующие освобождения после использования, могут течь хэндлеры,....

Здравствуйте, Аноним, Вы писали:

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

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

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

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

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

S>>>>>>Здравствуйте, c-smile, Вы писали:

CS>>>>>>>Нужно убедиться что это не твое точно.
CS>>>>>>>Скажем дампить количесвто и объем аллокаций и/или объектов.

S>>>>>>О.
S>>>>>>А как это сделать? и можно ли при этом знать место(на стеке), где эта аллокация происходит.
G_>>>>>http://www.rsdn.ru/article/vcpp/leaks.xml

Автор(ы): Эдвард Райт

Статья посвящена проблеме, которая постоянно преследует программистов на C/C++, — обнаружению и локализации утечек памяти. Автор демонстрирует применение средств библиотеки времени выполнения (CTR), поставляемой с Visual C++, с помощью которых утечки памяти можно устранить гораздо быстрее и проще, чем методом "пристального взгляда".

S>>>>Спасибо, уже проверил — ничего нет(это я и имел ввиду в первом посте под "Средствами отладки CRT — ликов нет").
G_>>>Ну тогда только менять WinHTTP остается.
G_>>>Кстати, замеры делали по количеству виртуальной памяти или по физическим страницам?

S>>Я делал только то, что описано в статье — объявлял макрос _CRTDBG_MAP_ALLOC. Делал тестовый лик, чтобы убедится, что все работает. по завершении программы — никаких ликов нет(В конце Leaks detected! не пишет в окне дебага).

А>То что не течет CRT еще не значит, что не течет что то другое
А>Нужно проверить еще COM память! Так же еще может течь какие-нить WinAPI функции требующие освобождения после использования, могут течь хэндлеры,....

Это все хорошо)
Можно ли это проверить программными средствами?
Тем более память время от времени очищается — можно предположить, что используются буфера, которые время от времени очищаются...

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

S>Это все хорошо)
S>Можно ли это проверить программными средствами?
S>Тем более память время от времени очищается — можно предположить, что используются буфера, которые время от времени очищаются...

while(1) в нужных местах и perfmon

Здравствуйте, Аноним, Вы писали:

>>Собственно вопрос — можно ли найти причину такого роста памяти? может в WinHTTP есть какие-то буфера или файлы выгружаются из памяти не сразу...
А>А в чем собственно сакральная ценность такого рода знания?

А>Если нужно понять есть ли утечки памяти я бы сделал по тупому — поставил на ночь (сутки, двое) работать и врубил perfmon на private set Вашего
А>процесса — если в результате тренд будет горизантальный (т.е. растет, падает до предыдущего уровня и снова) то волноваться не о чем.
А>Если растет и падает, но чуток выше чем было и так постоянно — то есть проблемы.

А>Для утечек COM памяти есть простенький StackWalker (наверное есть что то лучше, просто всегда его пользовал).

А>Для WinAPI незнаю ничего лучше чем проверить все места пользования.

А>Хэндлеры посмотреть в том же ProcessExlorer.

Спасибо) проверил.

Оставил на ночь работать программу.
На момент запуска монитора программа занимала 11 метров(это та память, что в диспетчере задач называется "Память", а по умолчанию там — "Память(частный рабочий набор)", которой меньше раза в полтора обычно).
Примерно за час объем памяти вырос до 20 метров. Дальше за минуту он упал до 2-х метров, а в след. минуту стал занимать 7 метров.
Через 40 минут объем вырос до 12-и метров.
А дальше включился ждущий режим.
Утром, после выхода из ждущего режима программа в памяти занимала почти 3 метра.

т.е. память время от времени очищается. это я заметил и раньше.
А если ждущий режим приводит к очищению памяти, то что это может быть? политика ОС? Если бы это были буфера WinHTTP, например — то они бы сохранились, наверное...



Хендлы смотрел через ProcessExplorer. Количество примерно одинаковое все время.
кроме моих файлов 3 файла, связанных с IE:

C:\Users\Дима\AppData\Local\Microsoft\Windows\Temporary Internet Files\Content.IE5\index.dat
C:\Users\Дима\AppData\Roaming\Microsoft\Windows\Cookies\index.dat
C:\Users\Дима\AppData\Local\Microsoft\Windows\History\History.IE5\index.dat

Это наверное WinHTTP все открывает?

И еще несколько, вроде:

\Device\Nsi
\Device\KsecDD
..
C:\Windows\System32\ru-RU\msxml3r.dll.mui
...
C:\Windows\winsxs\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.4927_none_d08a205e442db5b5

Вроде ничего необычного.

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

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

S>>т.е. память время от времени очищается. это я заметил и раньше.
S>>А если ждущий режим приводит к очищению памяти, то что это может быть? политика ОС? Если бы это были буфера WinHTTP, например — то они бы сохранились, наверное...
G_>Ну все-таки вы видите только подгруженные странички(динамику их подгрузки/выгрузки). Реальной информации об использовании памяти это не дает. В таких случаях лучше смотреть количество виртуальной памяти для процесса(например в висте Commit size в таск менеджере). Это тоже не дает реальной инфы по использованию, но несколько ближе. Это значение если и уменьшается, то только если страницы освободили, а не выгрузили на диск.

Спасибо)
Факт утечки, похоже, выявить все таки удалось.
После 16-и часов работы программы виртуальная память занимает 116 метров. И даже частный рабочий набор 54 метра(но скоро упал до 30-и).

Все же локализовать утечку не могу пока.
Вроде утечка происходит в процессе скачивания файла, т.к. если его не качать — то память стоит примерно на одном уровне все время.
В процессе скачивания файла:
Или текущий объем памяти записывается не синхронно или диспетчер задач ее обновляет не сразу, но в процессе выполнения ф-ии пошагово в отладчике увеличения памяти происходят в разных местах, хотя и регулярно( иногда на WinHttpOpen, иногда на условиях, вроде if(bool_variable) )
Может тут помогут всякие BoundsChecker? Никогда ими не пользовался.

И по поводу WinHTTP.
Я каждый раз заново создаю сессию через WinHttpOpen и в конце ф-ии закрываю ее хендл.
В msdn говорится, что с каждым вызовом WinHttpOpen создаются внутренние структуры данных. Может они не удаляются, когда закрывается хендл и стоит сделать каждую static __declspec(thread)?

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

S>Все же локализовать утечку не могу пока.
AQTime, Rational Purify могут помочь
нужно в один момент узнать все аллокации, затем сделать какие-то действия, посмотреть аллокации в след момент
сделать diff глазами и узнать кто аллоцирует и не удаляет (это если не мемлики, а засасывание памяти идет)
мемлики тулзы сами покажут

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

S>Может тут помогут всякие BoundsChecker? Никогда ими не пользовался.
По опыту могу сказать что достаточно капризная штука, далеко не с каждым проектом будет работать.
Хотя это относится к большинству анализаторов, если проект скажем на 1М строк...
Для мелких может вполне адекватно работать, надо пробовать

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

S>И по поводу WinHTTP.
S>Я каждый раз заново создаю сессию через WinHttpOpen и в конце ф-ии закрываю ее хендл.
S>В msdn говорится, что с каждым вызовом WinHttpOpen создаются внутренние структуры данных. Может они не удаляются, когда закрывается хендл и стоит сделать каждую static __declspec(thread)?
Собственно в этом вся проблема и есть. По моим наблюдениям после закрытия хендла сессия уходит не сразу, порты еще некоторое остаются занятыми. Разбираться тогда в причинах не стал, а перешел на URL моникеры. Проблема испарилась.

Здравствуйте, Аноним, Вы писали:

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

S>>И по поводу WinHTTP.
S>>Я каждый раз заново создаю сессию через WinHttpOpen и в конце ф-ии закрываю ее хендл.
S>>В msdn говорится, что с каждым вызовом WinHttpOpen создаются внутренние структуры данных. Может они не удаляются, когда закрывается хендл и стоит сделать каждую static __declspec(thread)?
А>Собственно в этом вся проблема и есть. По моим наблюдениям после закрытия хендла сессия уходит не сразу, порты еще некоторое остаются занятыми. Разбираться тогда в причинах не стал, а перешел на URL моникеры. Проблема испарилась.

А можно в 2-х словах об URL моникере? что это? полная альтернатива winInet/winhttp?
какие у них возможности? прокси само находит? https? POST запросы? хидеры можно запрашивать? можно ли контроллировать редиректы(каждый редирект самому получать)? и т.п.

Есть ли в сети какой пример класса с их использованием. сходу не нашел...

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

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

S>>Все же локализовать утечку не могу пока.
U>AQTime, Rational Purify могут помочь
U>нужно в один момент узнать все аллокации, затем сделать какие-то действия, посмотреть аллокации в след момент
U>сделать diff глазами и узнать кто аллоцирует и не удаляет (это если не мемлики, а засасывание памяти идет)
U>мемлики тулзы сами покажут

Установил AQtime) Вы не подскажите, как в нем выполнить вышеуказанные действия. пока не разобрался как сделать точку останова. триггеры на код(ф-ю, которая к нету обращается) подобавлял, а как сделать, чтобы код остановился в указанной точке — не пойму.

Здравствуйте, Аноним, Вы писали:

А>Дело было 3 года назад, сразу и не нашел тот проект. В целом все просто, вот кусок кода, остальное в MSDN очень подробно описано.
А>По именам классов легко найдешь остальное, здесь очень маленькая часть.

Спасибо. понаходил. В ATL есть класс такой же — CBindStatusCallback, также в гугл коде нашел пример

Еще вопрос по поводу синхронного и асинхронного режима. К примеру, я хочу сделать асинхронную закачку(для возможности отмены) и вызывать все это дело в отдельном потоке, имитируя синхронность через, например, события + WaitForSingleObject

т.е. хочется реализовать примерно следующий алгоритм:
1. создаем моникер.
2. ждем завершения закачки.
3. возвращаем управление в вызывающий поток.

как организовать такой поток? моникер ведь будет работать в том потоке, в котором создан(или нет?) — следовательно этот поток нельзя загружать WaitForSingleObject... или, например, использовать ATL::CWorkerThread — он основан на WaitForMultipleObjects
Подозреваю, что нужно организовывать цикл обработки сообщений, но никогда этого не делал вручную, как это будет выглядеть примерно?

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

S>Еще вопрос по поводу синхронного и асинхронного режима.
Вспомнил вот еще почему я на моникеры перешел. Дело в том, что кроме контроля ликов, там процесс синхронизации хорошо разрешен. Вообще нет нужды заморачиваться этим вопросом, моникер сам все отследит и сообщит обо всех своих действиях и состояниях, а уж как ты организуешь закачку(выгрузку) синхронно или асинхронно — по большому барабану. То же самое и с потоками. Я делал на одну закачку(выгрузку) — один поток из пула потоков. Цепляйся к обработчикам состояния моникера, там абсолютно все есть.

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

S>Еще вопрос по поводу синхронного и асинхронного режима. К примеру, я хочу сделать асинхронную закачку(для возможности отмены) и вызывать все это дело в отдельном потоке, имитируя синхронность через, например, события + WaitForSingleObject?

По поводу потоков, нашел статью в МСДН — там это решается с помощью MsgWaitForMultipleObjects

Как в моникерах делается ПОСТ запрос — пример от МС

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

S>Внутри используется WinHTTP, MSXML.

Если используется DOM, то скорее всего это MSXML отжирает память
Если задача позволяет, то лучше использовать SAX reader, он и памяти использует мало и XML зачитывает не в пример быстрее DOM'а (в основном за счет того, что нет COM-вызовов на каждый чих)

Здравствуйте, Аноним, Вы писали:

А>Для утечек COM памяти есть простенький StackWalker (наверное есть что то лучше, просто всегда его пользовал).

А эта утилита видит утечки не только в своем коде? используемые сервера также включает..?
Не нашел ее на первых страницах гугла.. только — класс на codeproject для вывода стека, или это он и есть? тогда как с его помощью можно отлавливать COM лики?

Вот еще кое что выяснилось..
Есть объект размером 300 байт + std::wstring-ги, которые внутри него заполняются еще.. строк там на кб минимум
Такие объекты создаются и удаляются с частотой около 50-70 штук в минуту.
т.е. за 16 часов — около 80-100 метров.

может ли частая аллокация/деаллокация привести к фрагментированию и, как следствие, росту памяти?

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

S>может ли частая аллокация/деаллокация привести к фрагментированию и, как следствие, росту памяти?
да.

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

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

S>>может ли частая аллокация/деаллокация привести к фрагментированию и, как следствие, росту памяти?
G_>да.

Это всегда или зависит от определенных критериев?

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

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

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

S>>>может ли частая аллокация/деаллокация привести к фрагментированию и, как следствие, росту памяти?
G_>>да.

S>Это всегда или зависит от определенных критериев?
Это зависит от настроек прожорливости crt'шного хипа. Со строками(когда у объектов много строк) бывает очень
жуткая каша, ради этого даже визуализатор когда то делали — картинка жуткая) Меняйте концепцию работы с памятью.
Хоть и есть возможность хип дефрагментировать, но лучше сделать все нормально сразу)

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

G_>Это зависит от настроек прожорливости crt'шного хипа. Со строками(когда у объектов много строк) бывает очень
G_>жуткая каша, ради этого даже визуализатор когда то делали — картинка жуткая) Меняйте концепцию работы с памятью.
G_>Хоть и есть возможность хип дефрагментировать, но лучше сделать все нормально сразу)

Так.. убрал ту частую аллокацию. теперь за 16 часов виртуальная память занимает 56 метров
Но в программе и так происходят постоянные аллокации, от которых трудно избавится.. в минуту качается несколько xml-ек. соотв. при их распарсивании создается msxml объект на куче. потом, при анализе, строки копируются во временный буфер.. Потом каждая строка сравнивается с теми, что есть.. а они в свою очередь также копируются в процессе перечисления(каждый объект — COM и у него есть метод get_id(BSTR*) ).. т.о. на 50 объектов — до 2500 аллокаций строк(BSTR).. и так до нескольких раз в минуту))

В общем память используется очень интенсивно

Так... что можно сделать..
— Сравнения оптимизируем..
— Xml.. может есть xml бесплатная либа, которая менее интенсиво использует кучу чем msxml?
— А что такое настройки прожорливости crt-шного хипа? и как их можно настроить..

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

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

S>>а они в свою очередь также копируются в процессе перечисления(каждый объект — COM и у него есть метод get_id(BSTR*) ).. т.о. на 50 объектов — до 2500 аллокаций строк(BSTR).. и так до нескольких раз в минуту))
G_>Брррр. Может у вас комовские строки текут?) используйте _bstr_t или CComBSTR. Тогда не удивительно почему вы не ловите мемлики — этм строки алоцируются с помощью SysAllocString

CComBSTR и использую..
Блин. спасибо! Благодаря вам лик нашел..
а лик такой:

CComBSTR bstr;
for(;;)
{
   pInterface->GetId( &bstr );//а тут никаких тебе ассертов... т.е. CComBSTR удалит только последнюю считанную строку
   //а в CComPtr есть.
   //а в _com_ptr_t указатель релизится при этом..
}

открыл atlcomcli.h..

#ifndef ATL_CCOMBSTR_ADDRESS_OF_ASSERT //а эта штука по умолчанию не задефайнина.. хотя странно
// Temp disable CComBSTR::operator& Assert
#define ATL_NO_CCOMBSTR_ADDRESS_OF_ASSERT
#endif


    BSTR* operator&() throw()
    {
#ifndef ATL_NO_CCOMBSTR_ADDRESS_OF_ASSERT
#pragma warning(push)
#pragma warning(disable:4068)
#pragma prefast(push)
#pragma prefast(disable:325, "We are deliberately checking if this has already been allocated")
        ATLASSERT(!*this);
#pragma prefast(pop)
#pragma warning(pop)
#endif
        return &m_str;
    }

G_>Вряд ли там что-то настроить можно, да и проблема не в нем
Но вы же говорили, что интенсивное использование(аллокация/деалокация) памяти могут приводить к увеличению объема памяти, занимаемой программой.. это так? или для этого нужны определенные условия..?

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

S>CComBSTR и использую..
S>Блин. спасибо! Благодаря вам лик нашел..
Пожалуйста.
Хотя, лучше как можно быстрее от них избавляться и работать с обычными строками — проблем будет меньше .

G_>>Вряд ли там что-то настроить можно, да и проблема не в нем
S>Но вы же говорили, что интенсивное использование(аллокация/деалокация) памяти могут приводить к увеличению объема памяти, занимаемой программой.. это так? или для этого нужны определенные условия..?
Ну это так теоретически — хип состоит из блоков. Т.е. если в текущем наборе не будет найден подходящий по размеру блок, то, теоретически, хип может вырасти(зависит от реализации). А может и более мелкие блоки объединить. Поэтому используйте другие менеджеры памяти

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

S>Есть локальный COM сервер на ATL.
S>Внутри используется WinHTTP, MSXML.

S>Сервер время от времени(до нескольких раз в минуту) качает xml-ку из интернета.
S>Данные, которые одновременно хранятся на сервере занимают 300-400 кб максимум(примерно).

S>вначале exe-шник занимает 3-4 метра.
S>в течении 2-3 часов он растет до 20-23 метров. потом освобождается до 10-12 и опять растет.

S>в сервере 80 длл я насчитал, но вначале их даже больше(смотрел process explorer-ом)

S>Собственно вопрос — можно ли найти причину такого роста памяти? может в WinHTTP есть какие-то буфера или файлы выгружаются из памяти не сразу...
S>Средствами отладки CRT — ликов нет. Для хендлов файлов используются умные указатели — тоже не должно быть ликов.
S>С COM объектами — тоже вроде все нормально, если бы количество AddRef/Release не совпадало — сервер бы зависал при выходе, такое уже было.

м.быть это просто working set ?