Отправлено: 23.08.13 15:50. Заголовок: Сборщик мусора / очистка памяти

Первые два рабочих дня "новой" программы помимо ожидаемых ошибок, связанных с "длинными" именами переменных/функций принесли пару-тройку ситуаций, в которых я ничего не могу понять.

Общий смысл таков, что в некоторых местах, связанных с интенсивными расчетами (напр. подгтовка прайс-листа на 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 и в каких случаях ?

 Отправлено: 23.08.13 18:12. Заголовок: Sergy пишет: Но что..

Sergy пишет:

цитата:

Но что это дает ?

Работа с базой будет быстрее если она живет на харде или живет в памяти , как думаешь ? ;)
Я говорю исключительно о временных базах (ну там отчетик создать или еще что)

 Отправлено: 23.08.13 18:15. Заголовок: Sergy пишет: 3) мас..

Sergy пишет:

цитата:

3) массив копеечный - 20-30 элементов максимум - id заказов, которые будут погружены в автомобиль, осуществляющий доставку.

Точно зацикливания нет ? Харбор тянет сотни тысяч и миллионы элементов массива

Local i := 1, a := {}

while .t.
AADD(a, i++)
if i % 1000 == 0
? i
endif
enddo

у меня свалился с такой же ошибкой 9009 на размере массива 31 млн элементов, при RAM 2GB

 Отправлено: 23.08.13 18:20. Заголовок: Sergy пишет: Так чт..

Sergy пишет:

цитата:

Так что со сборкой мусора? Никто на Harbour ее не использует?

Никогда специально не использовал, неявная сборка мусора справляется. Если появляются ошибки типа 900x, то это либо баг в стороннем коде (код харбора вылизан донельзя), либо простая причина вроде зацикливания.

 Отправлено: 23.08.13 18:33. Заголовок: Pasha пишет: Точно ..

Pasha пишет:

цитата:

Точно зацикливания нет ? Харбор тянет сотни тысяч и миллионы элементов массива

Совершенно точно. Эта операция повторяется в среднем 100-200 раз в день на многих машинах.
Оператор пробил заказ - ставит его на доставку.
Выбирает машину, указывает адрес клиента из списка.

Эта функция возвращает список id заказов, которые находятся в этой машине. так что там миллион не получится никак.

 Отправлено: 23.08.13 18:37. Заголовок: Pasha пишет: код ха..

Pasha пишет:

цитата:

код харбора вылизан донельзя

После вчерашних мытарств с банальным SETKEY и HB_SETKEY я в этом не особо уверен.

 Отправлено: 23.08.13 18:56. Заголовок: Dima пишет: Работа ..

Dima пишет:

цитата:

Работа с базой будет быстрее если она живет на харде или живет в памяти , как думаешь ? ;)

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

 Отправлено: 23.08.13 18:59. Заголовок: Sergy пишет: Called..

Sergy пишет:

цитата:

Called from CRLIST(187) in trade206.prg

А что тут происходит?

 Отправлено: 23.08.13 19:01. Заголовок: PSP пишет: А что ту..

PSP пишет:

цитата:

А что тут происходит?

Вроде ниче криминального:
Скрытый текст

FUNC CRList(dDate) // -> {dDate,{id маршрутов},{описания маршрутов}} LOCAL area,res,sx res := {dDate,{},{}} area:=SELECT() SELECT caroute SEEK DTOS(dDate) DO WHILE (caroute->date == dDate) IF caroute->vault sx := caroute->id+" "+Vault(caroute->date,"CR"+caroute->id,,"") // описание задано начальником транспорта ELSE sx := "Маршрут "+caroute->id // описание маршрута не задано, просто номер ENDI AADD(res[2],caroute->id) // id << вот строка 187 AADD(res[3],PADR(sx,25)) // описание SKIP ENDD SELECT(area) RETURN res // {dDate,{ids},{описания}}

По сути - выбирается список машин на выбранную дату и собираются в небольшой массив: {дата, {id машин}, {описания по этим id: кто куда едет}}

Больше в день 10 машин никогда не бывает.

 Отправлено: 23.08.13 19:28. Заголовок: Добавьте где-нибудь ..

Добавьте где-нибудь проверку ! Empty(dDate)
или if dbSeek(DTOS(dDate))

у меня давно такие проверки как безусловный рефлекс

 Отправлено: 23.08.13 19:32. Заголовок: Pasha пишет: Добавь..

Pasha пишет:

цитата:

Добавьте где-нибудь проверку ! Empty(dDate) или if dbSeek(DTOS(dDate)) у меня давно такие проверки как безусловный рефлекс

ок, попробую

 Отправлено: 23.08.13 22:12. Заголовок: Sergy пишет: ок, по..

Sergy пишет:

цитата:

ок, попробую

Если передать этой функции пустую дату, то обязательно произойдет зацикливание.
Чтобы его гарантированно избежать, во всех выборках данных надо добавлять:

do while ! eof() .and. ...

 Отправлено: 24.08.13 00:16. Заголовок: Думаю, зацикливание ..

Думаю, зацикливание произойдет в том случае, если не дата пустая, а в таблице не будет записей с датой, большей чем заданная. Надо будет обязательно поставить проверку на eof().

 Отправлено: 24.08.13 08:09. Заголовок: Sergy пишет: Думаю,..

Sergy пишет:

цитата:

Думаю, зацикливание произойдет в том случае, если не дата пустая, а в таблице не будет записей с датой, большей чем заданная. Надо будет обязательно поставить проверку на eof().

нет, зацикливание будет только при пустой дате

SEEK DTOS(dDate)

при пустой дате переместит на eof

DO WHILE (caroute->date == dDate)

при пустой дате указатель уже стоит на eof, и всегда будет .t.
это зацикливание

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


Неужели Вы за все время программирования на клиппере ни разу не натыкались на такой случай ? У меня это случилось еще на заре использования клиппера, и с тех пор я ни один цикл по таблице без проверки на eof не делаю.

 Отправлено: 24.08.13 10:06. Заголовок: Sergy пишет: 1) Зад..

Sergy пишет:

цитата:

1) Задача разумеется сетевая 2) в сети работает от 15 до 25 чел в среднем 3) массив копеечный - 20-30 элементов максимум - id заказов, которые будут погружены в автомобиль, осуществляющий доставку.

Sergy пишет:

цитата:

Итого 72шт DBF и 84шт NTX. В среднем открыто 5-10 таблиц + индексы к ним. Половина из этого - на локальном компе (справочники имен/цен/контрагентов, которые меняются редко). Все временные файлы создаются тоже исключительно локально.

Я свои несколько программ перенес на хХарбор уже лет 5 назад.
Программы сетевые, на CDX-индексах, каждая программа открывает примерно 120шт. DBF и 170шт. CDX
Каждый юзер на своем компе открывает 3-4 программы и кучу DOC файлов... НУ нравиться им так работать..
Юзеров которые работают с моими программами 10-15 чел., в зависимости от работы.
И это не считая 1С и КЛИЕТ-серверной проги на Дельфи.
Никто не жалуется из юзеров на скорость и вылет программ. Проблем нет, все работает как часы.
Это хХарбор 1.0.0, а что будет при переходе на Харбор - я уже представляю.
Так что у тебя простые проблемы при переходе, делай тестировки в узких местах, Харбор более требователен к написанию кода, что и правильней !
Где Клипер работал, не факт что Харбор будет работать.
С NTX переходить и необязательно, если времени много, то да конечно можно заняться этим.

 Отправлено: 24.08.13 11:08. Заголовок: Pasha пишет: нет, з..

Pasha пишет:

цитата:

нет, зацикливание будет только при пустой дате SEEK DTOS(dDate) при пустой дате переместит на eof DO WHILE (caroute->date == dDate) при пустой дате указатель уже стоит на eof, и всегда будет .t. это зацикливание при непустой - если дата совпадет, указатель будет перемещаться на следующую запись, а когда достигнет другой даты или eof - будет выход из цикла. зацикливания нет ни при каком случае

Вы абсолютно правы.
Сделал тестовый пример с CRList(NIL) - тут-же получил вылет на DTOS(), а вот если сделать CRList(CTOD("")) - тогда получился сначала зависон, выедание 2х гигов оперативки и через секунд 30-40 - вылет с точно таким-же сообщением об ошибке: неспособности перераспределить память.

Осталось только понять, как пустая дата могла попасть в эту функцию.

цитата:

Неужели Вы за все время программирования на клиппере ни разу не натыкались на такой случай ? У меня это случилось еще на заре использования клиппера, и с тех пор я ни один цикл по таблице без проверки на eof не делаю.

Натыкался конечно и всюду ставлю проверку на EOF(). Почему тут так получилось - хз. Помутнение рассудка какое-то...
Спасибо за помощь.

 Отправлено: 24.08.13 11:16. Заголовок: Sergy пишет: Остало..

Sergy пишет:

цитата:

Осталось только понять, как пустая дата могла попасть в эту функцию

Посмотри все вызовы этой функции и что ей передается (вероятно там косяк)
В самой функции можно устроить проверку на дату. Если она пуста тогда
в цикле можно куда то вывести все Procname , ProcLine что бы понять откуда
пришла пустая дата.

 Отправлено: 26.03.16 15:29. Заголовок: Вот такое поймал Неи..

Вот такое поймал
Неисправимая ошибка 9009: hb_xrealloc ене может перераспределить память
Called from DBSEEK(0)
Обычный Dbseek

Неисправимая ошибка 9009: hb_xrealloc ене может перераспределить память
Called from DBAPPEND(0)
Это при добавлении записи в MEM: базу

Что с этим делать не пойму , вылазит редко.

 Отправлено: 26.03.16 19:35. Заголовок: Обвесь dbAppend() в ..

Обвесь dbAppend() в begin sequnce и цикл
Проверь удаление индекса перед открытием mem:...
Переведи с mem:.. на temporary, раньше проверял, если в отбор на mem: попадало много записей, то без разницы с mem: или файлом на диске работать

 Отправлено: 26.03.16 22:34. Заголовок: SergKis пишет: Обве..

SergKis пишет:

цитата:

Обвесь dbAppend() в begin sequnce и цикл

Ты про вариант как с Ddcreate2 тут ? http://clipper.borda.ru/?1-3-0-00000297-000-10001-0-1415683246
Там подход ясен , так как если по сетке создавать базу то нужен контроль.
А с MEM: работаю же в оперативе и Exclusive.
Временные базы конечно же закрываю и потом "топчу" через Dbdrop с индексами.
Записей не много в MEM: базе , 1000 штук всего , размер под 200 кило.
Чем надежнее temporary в сравнении с mem: ?

 Отправлено: 26.03.16 22:52. Заголовок: Dima пишет:Ты про ва..

Dima пишет:

цитата:

Ты про вариант как с Ddcreate2

Да. Если это случайный сбой, то при повторной попытке может быть ок!
Если это с индексом что то (сбой по dbseek) - это хуже и вылет dbappend как следствие этого
temporary это файловая работа в temp каталоге с удалением после закрытия, вроде так было
для простоты и прояснения ситуации можно и в обчном dbf прокатать