Отправлено: 18.09.10 08:37. Заголовок: После многократных вызовов и возвратов уменьшается bliLocAvl()

Привет всем.

После загрузки программы bliLocAvl() = 22 Кб. В процессе работы, когда юзера многократно входят/выходят из разных режимов, углубляясь порой на 15 уровней вызовов, функция bliLocAvl() показывает значения < 10Kb. Рано или поздно, но это значение уменьшается до 5 кб, после чего идёт вывал по UE 667 (Eval Stack fault).
Программа собрана blinker'ом 6, из сторонних библиотек используются ADS for NetWare 7.x и SIX.
Так же в сборке задействованы dosidle.obj & __wait_b.obj

Многие функции переделаны под использование local-массивов вместо private-переменных, но бОльшая часть остаётся с private-переменными. То есть, symbol table достаточно здоровая.

В чём может быть причина уменьшения Eval-стека после возвратов из разных режимов ?

 Отправлено: 18.09.10 09:42. Заголовок: Надо оптимизировать ..

Надо оптимизировать код, используеться много переменных, рекурсия и тд. По ошибке:



667 Eval stack crashed

The evaluation stack (containing LOCAL variables, etc.) and/or MEMVAR table has grown too much and crashed into a locked VM segment in near memory. The system has run out of memory because the VM system only locks segments near the evaluation stack when the memory is very old.
Action: Some suggestions to resolve this problem are:
1) Decrease the STACK or PROCEDURE DEPTH setting for the linker.
2) Decrease the number of LOCAL, STATIC or PRIVATE variables in use at one time. i.e., use arrays instead of individual variables.
3) Decrease the number of ITEMS allocated if using ITEM.API of CA-Clipper.
4. Free more conventional memory for use by the VM System.
Note: There could also be an error in the runtime error handler.
See Also: Error 650.


650 Out of stack space

This error is often the result of another error -- CA-Clipper encounters an error while it is trying to handle the first error.
Action: Some suggestions to resolve the problem are:
1) Use STACK or PROCEDURE DEPTH command to instruct the linker to increase the stack space at link time.
2) Check for recursion. Some modifications to the CA-Clipper ERRORSYS.PRG may cause a recursive call, which will exhaust the call stack.
3) Try using the default CA-Clipper ERRORSYS.PRG if the ERRORSYS.PRG was modified, in order to test for runaway recursion caused by an error occurring while attempting to handle an Error object.
4) Check for UDFs/.PRGs that have the same name as an internal CA-Clipper function.
5) Check for use of an incorrect or invalid version of the ERRORSYS.PRG. i.e., the Summer '87 CA-Clipper ERRORSYS.PRG does not use an Error object.