Здравствуйте, samodelkin, Вы писали:
S>Добрый день, интересует возможность получит вместе с HtmLayout.dll еще и отладочные символы в виде HtmLayout.pdb. Возможно ли это ?
Я строю отдельный билд (т.н. retail SDK version) для зарегистрированных юзеров, он содержит pdb.
Здравствуйте, c-smile, Вы писали:
CS>Я строю отдельный билд (т.н. retail SDK version) для зарегистрированных юзеров, он содержит pdb.
Тогда как можно зарегистрироваться ? Дело в том, что я пытаюсь разобрать случаи утечек памяти в приложении, которые ведут в htmlayout.dll, соответственно без отладочных символов мне не разобраться.
Здравствуйте, samodelkin, Вы писали:
S>Здравствуйте, c-smile, Вы писали:
CS>>Я строю отдельный билд (т.н. retail SDK version) для зарегистрированных юзеров, он содержит pdb.
S>Тогда как можно зарегистрироваться ? Дело в том, что я пытаюсь разобрать случаи утечек памяти в приложении, которые ведут в htmlayout.dll, соответственно без отладочных символов мне не разобраться.
А каким образом наличие PDB поможет "разобрать случаи утечек памяти"?
Рекомендую пользовать dom::element как smart pointer для HELEMENT. Зело помогает.
Здравствуйте, c-smile, Вы писали:
CS>А каким образом наличие PDB поможет "разобрать случаи утечек памяти"?
В таком случае я увижу, какие места привели к утечкам и возможно пойму, как этого избежать. Пока же я просто вижу, что они есть и call-stack примерно следующией:
htmlayout+0x4fd08
Смещение 0x4fd08 мне ни о чем не говорит.
CS>Рекомендую пользовать dom::element как smart pointer для HELEMENT. Зело помогает.
Здравствуйте, samodelkin, Вы писали:
S>Здравствуйте, c-smile, Вы писали:
CS>>А каким образом наличие PDB поможет "разобрать случаи утечек памяти"?
S>В таком случае я увижу, какие места привели к утечкам и возможно пойму, как этого избежать. Пока же я просто вижу, что они есть и call-stack примерно следующией: S>htmlayout+0x4fd08 S>Смещение 0x4fd08 мне ни о чем не говорит.
Я сильно подозреваю что и имя моей функции тебе ничего не скажет.
Есть такая штука class htmlayout::dom::expando .
С её помощью можно отследить висящие DOM элементы.
Алгоритм примерно следующий:
1) момент X проходим по всем элементам и назначаем на каждый свое expando.
При этом добавляем эти expando в map<HELEMENT,expando*>.
2) Закрываем окно или грузим другой документ. В процессе выгрузки будет вызван
expando::finalize() для всех элементов с expando.
По finalize() удаляем DOM элемент из map<HELEMENT,expando*>.
По завершению данной операции в map<> останутся зависшие элементы.
В большинстве случаев достаточно просто вывести их tag name чтобы понять где оно и что оно.
Здравствуйте, c-smile, Вы писали:
CS>Здравствуйте, samodelkin, Вы писали:
S>>Здравствуйте, c-smile, Вы писали:
CS>>>А каким образом наличие PDB поможет "разобрать случаи утечек памяти"?
S>>В таком случае я увижу, какие места привели к утечкам и возможно пойму, как этого избежать. Пока же я просто вижу, что они есть и call-stack примерно следующией: S>>htmlayout+0x4fd08 S>>Смещение 0x4fd08 мне ни о чем не говорит.
CS>Я сильно подозреваю что и имя моей функции тебе ничего не скажет.
CS>Есть такая штука class htmlayout::dom::expando . CS>С её помощью можно отследить висящие DOM элементы. CS>Алгоритм примерно следующий:
CS>1) момент X проходим по всем элементам и назначаем на каждый свое expando.
А что делать с элементами у которых уже есть expando?
Здравствуйте, alsemm, Вы писали:
CS>>1) момент X проходим по всем элементам и назначаем на каждый свое expando. A>А что делать с элементами у которых уже есть expando?
Здравствуйте, c-smile, Вы писали:
CS>Я сильно подозреваю что и имя моей функции тебе ничего не скажет.
CS>Есть такая штука class htmlayout::dom::expando . CS>С её помощью можно отследить висящие DOM элементы. CS>Алгоритм примерно следующий:
CS>1) момент X проходим по всем элементам и назначаем на каждый свое expando. CS>При этом добавляем эти expando в map<HELEMENT,expando*>. CS>2) Закрываем окно или грузим другой документ. В процессе выгрузки будет вызван CS>expando::finalize() для всех элементов с expando. CS>По finalize() удаляем DOM элемент из map<HELEMENT,expando*>.
CS>По завершению данной операции в map<> останутся зависшие элементы. CS>В большинстве случаев достаточно просто вывести их tag name чтобы понять где оно и что оно.
со своим собственно подготовленным html.
Поэтому даже не представляю, что мне потом делать с dom-элементами. Предполагаю, что не освобождается image, локальный путь на который указан в моем html.
А что мне делать с неосвобожденными dom-элементами после того, как я пойму, что они например не выгружаются ? Есть ли специальные функции для их выгрузки ?
Здравствуйте, samodelkin, Вы писали:
S>Здравствуйте, c-smile, Вы писали:
CS>>Я сильно подозреваю что и имя моей функции тебе ничего не скажет.
CS>>Есть такая штука class htmlayout::dom::expando . CS>>С её помощью можно отследить висящие DOM элементы. CS>>Алгоритм примерно следующий:
CS>>1) момент X проходим по всем элементам и назначаем на каждый свое expando. CS>>При этом добавляем эти expando в map<HELEMENT,expando*>. CS>>2) Закрываем окно или грузим другой документ. В процессе выгрузки будет вызван CS>>expando::finalize() для всех элементов с expando. CS>>По finalize() удаляем DOM элемент из map<HELEMENT,expando*>.
CS>>По завершению данной операции в map<> останутся зависшие элементы. CS>>В большинстве случаев достаточно просто вывести их tag name чтобы понять где оно и что оно.
S>Я на самом деле вызываю функцию, наподобие этой:
S>
S>со своим собственно подготовленным html. S>Поэтому даже не представляю, что мне потом делать с dom-элементами. Предполагаю, что не освобождается image, локальный путь на который указан в моем html.
Все images гарантированно освобождаются при загрузке нового документа во view.
Фактически коллекция images есть member variable в root node. Т.е. если никто root node не держит то и images удаляются.
S>А что мне делать с неосвобожденными dom-элементами после того, как я пойму, что они например не выгружаются ? Есть ли специальные функции для их выгрузки ?
Неосвобожденные DOM элементы означают что у тебя больше вызовов HTMLayout_UseElement() чем HTMLayout_UnUseElement()
что есть add_ref/release пара. И это само собой надо фиксить.
Здравствуйте, c-smile, Вы писали:
CS>Здравствуйте, alsemm, Вы писали:
CS>>>1) момент X проходим по всем элементам и назначаем на каждый свое expando. A>>А что делать с элементами у которых уже есть expando?
CS>Ну значит они уже сидят в той map<>.
Нет не седят — это чужие expando, не мои. Например когда у меня на старнице несколько native behavior-ов от разных "поставщиков".
Здравствуйте, c-smile, Вы писали:
CS>Неосвобожденные DOM элементы означают что у тебя больше вызовов HTMLayout_UseElement() чем HTMLayout_UnUseElement() CS>что есть add_ref/release пара. И это само собой надо фиксить.
