Кот (Все сообщения пользователя)

О, спасибо! Попробую этот вариант!  

Та же самая, зачем менять то, что работает?!  

Проблема решена. Код :

for iord=lastact,N do
   local tab=getItem('orders',iord); -- получаем заявку i
  if tab~=nil then if tab.account==acc then if bit.band(tab.flags,0x1)==0x1 then
    ...
  end; end; end;
end;

Перебирал большое число заявок (все) и засорял память, хоть и срабатывал сравнительно редко.
До сих пор не понимаю как в qlua сделать локальную переменную массива (таблицы), чтобы при её обработке в цикле не возникало жора памяти?!

Тот который не перегружает занимает 1200 мБ, другой, который перегружает 1870 мБ.

Пока что создаётся впечатление, что это работа OnTrnsReply(reply), так как перегрузка памяти идёт именно в моменты активной торговли другими системами.

Соответственно встаёт вопрос - как с этим бороться? Может быть стоит прописать reply= { } чтобы чистить память сразу из Коллбэка?
Потому что никакой сложной обработки у меня нет, фактически все завершается первой строчкой  :  if  reply.account~=Account then return; end;
Да и в остальном коде только поиски по тексту ошибки. Мегабайтам там уходить некуда!  

Это всё уже сделано и объемы данных минимизированны в обоих копиях КВИК. Тем более одно дело память КВИК (300мБ-1500мБ), другое дело память Lua скрипта, которая почему-то засоряется.

Случилось у меня такое интересное наблюдение :

Торговый робот на одной копии QUIK у одного брокера работает нормально, создаёт таблицу данных (43 мБ) и в течении всего времени работы поддерживает выделение памяти на этом уровне.
Тот же самый работ на другой копии QUIK (той же версии 8.13.1.6), но у другого брокера испытывает скачки памяти (в таблицах Qlua) с интервалом приблизительно в 3-5 секунд : память растёт от 43мБ до 86 мБ, после чего опять возвращается к уровню 43мБ.

Никакой разницы в роботах или версиях QUIK нет. Все тяжелые вычисления проводятся с намного большей периодичностью (меньшей частотой), приблизительно раз в 30-60 секунд и в обязательном порядке сопровождаются вызовом сборщика мусора. В промежутках между вычислениями сборщик мусора не вызывается, а вся нагрузка это не частые запросы типа Poll (опрос) к котировкам и таблицам заявок. Среди колбэков только легковесные OnOrder(), OnTrnsReply() и всё. При этом на обоих экземплярах QUIK ведётся торговля другими торговыми алгоритмами приблизительно с одинаковой интенсивностью, то есть все обработчики вызываются одинаково регулярно и их выполнение точно не занимает в памяти 40 мБ.

Подскажите, в чём может быть проблема?!  

Всем спасибо, проблема действительно была в DLL.
Забыл предусмотреть return в "исключительных" случаях. (

Спасибо.
Нет, Lua не менял.

Спасибо, учту версия Lua 5.4.1.

Обращаюсь к форуму, потому что уже сам не понимаю где ловить ошибку.

История :

Quik 8.13
Боевой робот, достаточно масштабный, но стабильно работающий более года.
Внешняя библиотека DLL на Cpp.

После совершенно незначительных обновлений библиотеки (тип переменных) и управляющего библиотекой скрипта Lua (тип переменных)  скрипт регулярно падает с двумя видами ошибок -
1. Access Violation at adress XXX
2. Unknown Exception at adress XXX

При этом сам Quik остается рабочим, просто завершает скрипт.

Помогите сузить круг поиска, правильно ли я понимаю, что проблема исключительно в DLL или, возможно, во внутренних функциях, например GetParamEx() и подобных?

Спасибо.

Попробую, спасибо.

Уважаемый Quik Clients Support, а не могли бы вы уточнить как выставить данную заявку из QLua скрипта?

А пока ARQA отмалчивается и даже не предлагает зарегестрировать обращение, Квик выдает все новые подвиги ...



Никаких предпосылок к тому, чтобы мешать свечи BRU и BRV нет - все данные целые, отсутствуют пробелы, но Квик, почему-то упорно миксует разные инструменты в одной таймсерии. Так скоро и Газпром с Норникелем начнет мешать, ради забавы.  

Добрый день.
Суть проблемы в том, что Квик 8.13.1.16 создает неверные данные по инструментам срочного рынка, заполняя пропуски другими данными, взятыми с торгов другими инструментами.

На графике фьючерса это выглядит так :



Эта же проблема возникает при склеивании фьючерсов - отсутствие сделок и пропуск свечи автоматически приводит к замене ее на свечу с "соседнего" инструмента. В результате данные отображаются неверно и корректировать их становится невозможно.

Вывод по CreateDataSource повторяет те же ошибки.

Возможно, существует какая-то настройка, но мне ее найти не удалось.