Форум » [x]Harbour » Сборщик мусора / очистка памяти » Ответить

Сборщик мусора / очистка памяти

Sergy: Первые два рабочих дня "новой" программы помимо ожидаемых ошибок, связанных с "длинными" именами переменных/функций принесли пару-тройку ситуаций, в которых я ничего не могу понять. Общий смысл таков, что в некоторых местах, связанных с интенсивными расчетами (напр. подгтовка прайс-листа на 5-6 тысяч наименований, сложная комбинированная работа с разными таблицами одновременно и тп) приводит к совершенно непредсказуемым результатам: - пропадают надписи в SAY в панели с несколькими GET - программа вылетает/виснет - программа неожиданно начинает пытаться открыть документ Word/Excel а то и несколько... Осмысленного объяснения этому процессу дать не могу, поскольку связи с кодом нет точно. Во всяком случае, Clipper в этих местах работал (но зато без звука вылетал в других и намного чаще). На одной машине даже поймал вот такой отчет: --- Application Internal Error - D:\tradewin.exe Terminated at: 2013.08.23 12:12:31 Неисправимая ошибка 9009: hb_xrealloc ене может перераспределить память Called from AADD(0) Called from CRLIST(187) in trade206.prg Called from ADDR2QUEUE(124) in trade206.prg Called from SALE2QUEUE(209) in trade206.prg Called from MAKESALEDOCS(1816) in trade224.prg Called from SALECONT2(593) in trade224.prg Called from DBVIEW2(4807) in trade225.prg Called from DO(0) Called from ACHOICE(0) in ../../../achoice.prg Called from DBVIEW(4784) in trade225.prg Called from SALECONTROL(272) in trade224.prg Called from CHECK4DAMAGE(963) in trade.prg Called from MAIN(234) in trade.prg ------------------------------------------------------------------------ в Clipper я использовал в критичных местах шаманства наподобие MEMORY(-1) и FT_IamIdle() В Harbour я естественно их убрал - полагал, что там, где раньше почти хватало 16 мегов памяти, в 1-2 гигабайтах будет где развернуться без проблем. Похоже, что это не так. Что нужно использовать для Harbour и в каких случаях ?

Ответов - 67, стр: 1 2 3 4 All

Dima: SergKis пишет: Да. Если это случайный сбой Списал пока на него , буду наблюдать.

SergKis: Dima можно самому в "тонком" месте вызывать сборщик мусора и продолжать потом раблту

Dima: SergKis пишет: Dima можно самому в "тонком" месте вызывать сборщик мусора и продолжать потом раблту Как определить тонкое место и его вызвать (сборщика мусора) ?


SergKis: Dima для начала, перед dbAppend или каким то рабочим циклом. Я, например перед созданием окна, вызываю сборщика, принудительно, прога им приостанавливается на это время.

Dima: SergKis пишет: Я, например перед созданием окна, вызываю сборщика Как вызываешь ? Попробовал hb_xfree() , hb_xgrab() , прога не собралась , вероятно они только для вызова из СИ.

Петр: Dima пишет: Попробовал hb_xfree() , hb_xgrab() Это не то. Функции сборщика (gc - garbage collector) hb_gcAll(), hb_gcStep(), hb_gcSetAuto()

SergKis: Dima вызываю HB_GCALL() // там параметр отложенный или нет, я без параметров делаю

Dima: Петр SergKis Спасибо ! Попробую вызывать его перед созданием MEM: базы и понаблюдаю...

Dima: SergKis пишет: Переведи с mem:.. на temporary MEM: я создаю и открываю сразу с помощью DBCREATE , опции temporary не вижу там , печаль...

SergKis: Dima завтра найду, сегодня уже башка не варит, не могу найти место где делал

Dima: SergKis Хорошо.

Pasha: Перевыделение памяти (вызов hb_xrealloc) выполняется в функции hb_memfsWriteAt из модуля contrib\hbmemio\memio.c При каждом вызове dbAppend размер файла в памяти увеличивается, значит, как раз идет вызов hb_xrealloc. Старый блок при этом освобождается, следовательно, происходит дефрагментация памяти. Насколько эта дефрагментация критична при современных гигантских объемах памяти, доступных программе - трудно сказать. Мне трудно представить, что программа забила вся память так, чтобы система не смогла ей выделить довольно небольшой (относительно) блок. Можно сделать тест: в цикле делать dbAppend(), и смотреть, сколько итераций выдержит программа. Другая причина такой ошибки - зацикливание программы, но это, как я понимаю, маловероятно.

Pasha: Дополню: если есть проблема с дефрагментацией памяти, то сборщик мусора при этом не поможет, так как сборщик мусора освобождает память для переменных, которые уже уничтожены, а не дефрагментирует память. В таком случае надо использовать не файлы в памяти, а временные файл на диске, т.е. создать файл вызовом dbCreate(cName, aStruct, cDrv, .t., cAlias), и после закрытия удалить его.

Dima: Pasha Спасибо что прояснил

Dima: Pasha Паша а каковы могут быть причины что программа зависает на QUIT , он же __QUIT() ? У себя повторить не получилось , ловил зависон при входе на удаленный комп через Team Viewer , раз 20. Приложение точно зависает , так как в заголовке окна винда 7 пишет что приложение не отвечает.

SergKis: SergKis пишет:завтра найду hb_dbCreateTemp( <cAlias>, <aStruct>, <cRDD>, <cCodePage>, <nConnection> ) -> <lSuccess> и INDEX ON <key> TAG <(tag)> temporary

Dima: SergKis пишет: <nConnection> А это что и для чего ?

SergKis: Dima этот параметр и dbCreate есть, думаю для развития а INDEX ... TAG ... и без temporary будет временный

SergKis: PS база открывается с заданным алиасом

Dima: SergKis пишет: база открывается с заданным алиасом да это я тупанул ))



полная версия страницы