Очередное зависание Lua-скрипта

Страницы: 1
RSS
Очередное зависание Lua-скрипта, в функции getDepoEx
 
QUIK 13.0.0.165
Заинтересованные могут протестировать, скачав архив рабочего места по ссылке: https://cloud.mail.ru/public/PnRh/78X5kdGEB
Подключаться к серверу не требуется. Достаточно добавить в окно "Доступные скрипты" скрипт getDepoEx.lua (лежит в папке с программой) и запустить его.
Код
function main()
  local n = getNumberOf("depo_limits")
  message("Number depo_limits: " .. n)
  if n > 0 then
    getDepoEx("NC0011100000", "10382", "SBER", "NL0011100043", 20260601)
  end
  message("Завершение работы main.")
end

При запуске скрипта в окне "Системные сообщения" появляется сообщение "Number depo_limits: 4", и скрипт остаётся в запущенном состоянии. Сообщения "Завершение работы main." нет, что говорит о том, что не происходит выхода из функции getDepoEx.
При этом процесс info.exe грузит один из логических процессоров на 100%.
 
Добрый день.

Возможно, дело в том, что цикл, где вы пытаетесь получить позиции по инструменту, не останавливается т.к. в функцию getDepoEx были введены некорректные данные.

В качестве последнего параметра limit_kind указывается срок расчетов и getDepoEx принимает это значение в формате NUMBER. Возможные значения - положительные целые числа, начиная с «0», соответствующие срокам расчетов из таблицы «Позиции по инструментам»: «0» – T0, «1» – T1, «2» – T2 и т.д.

Попробуйте изменить этот момент и проверьте работу скрипта.
 
Не смог промолчать, прочитав ответ техподдержки.

1) В опубликованном в первом сообщении темы коде НЕТ ЦИКЛА.

2) limit_kind может принимать значения типа 20260601, если лимитирование идёт по календарным дням, а не по схеме T0, T1 и т.д.

3) В случае некорректных значений функция getDepoEx всё равно должна завершать свою работу без зависания.

4) Адекватной реакцией техподдержки должна быть попытка воспроизведения проблемы на своём тестовом контуре с одним из выводов: удалось воспроизвести и будем чинить, или не удалось воспроизвести.
 
Для п.2 приведу ссылку на тему форума, где было обсуждение такой схемы лимитирования.
https://forum.quik.ru/forum10/topic8865/
В документации QLua версии 13.0 этот момент не отражён.
 
Здравствуйте.

В ходе тестирования скрипта, у нас не возникло проблем, ошибок или зависаний Рабочего места. В окне сообщений появляются оба сообщения: о количестве позиций по инструментам и о завершении работы main.

Подскажите, пожалуйста, представленная часть кода - это весь скрипт? Запущены ли еще какие-то скрипты параллельно?
 
Oleg Kuzembaev, что показывает следующий скрипт?
Код
function main()
  local sec_code = "SBER"
  local n = getNumberOf("depo_limits")
  if n > 0 then
    message("Number depo_limits: " .. n)
    for i = 0, n - 1 do
      local l = getItem("depo_limits", i)
      message(l.sec_code .. ": limit_kind = " .. l.limit_kind .. "; currentbal = " .. l.currentbal .. "; wa_position_price = " .. l.wa_position_price)
    end
    message(tostring(getDepoEx("NC0011100000", "10382", "SBER", "NL0011100043", 20260601)))
  else
    message("depo_limits not found", 2)
  end
  message("Завершение работы main.")
end
 
Попробовал, не воспроизводиться.QUIK 13.0.0.165.
 
Цитата
Станислав написал:
Попробовал, не воспроизводиться.QUIK 13.0.0.165.
Вы что-то другое пробовали. В архиве, что я выложил (ссылка в первом посте), другие лимиты.
 
Возможно архив кривой
При обновлении остались какие-то старые библиотеки.
Поставьте КВИК с нуля
 
Если использовать архив из первого сообщения, то проблема действительно воспроизводится, однако, только если не подключаться к серверу.
Стоит подключиться к серверу, скрипт корректно выполняется.  
 
Станислав, я не знаю как вы тестируете, но из вашего скрина видно, что код getDepoEx("NC0011100000", "10382", "SBER", "NL0011100043", 20260601) не должен был вернуть table. Ну нет у вас лимитов с такими вводными.

Цитата
Станислав написал:
Стоит подключиться к серверу
и лимиты обновятся, это будет уже другой набор данных.

Цитата
Станислав написал:
Если использовать архив из первого сообщения, то проблема действительно воспроизводится, однако, только если не подключаться к серверу.
Я локализовал проблему, выложил архив, на котором воспроизводится описанная мной проблема. Что ещё нужно?
 
Здравствуйте.

Мы не занимаемся тестированием скриптов. Если у вас есть вопросы по какой-то конкретной функции, просьба озвучить их и мы постараемся помочь.
 
Цитата
Oleg Kuzembaev написал:
В ходе тестирования скрипта, у нас не возникло проблем, ошибок или зависаний Рабочего места.
Вы проверяли на рабочем месте из архива по ссылке в первом посте, без изменения настроек и кода скрипта и без подключения к серверу?
 
Тест проводился на подключенном к серверу терминале, что является корректным условием для работы скрипта.
 
Цитата
Oleg Kuzembaev написал:
Тест проводился на подключенном к серверу терминале, что является корректным условием для работы скрипта.
Зря Вы это написали, т.к. в таком случае документацию необходимо обновлять и точно указывать для каких методов не гарантируется корректная работа при отсутствии соединения. Более того, если в процессе работы происходит разрыв соединения и в этот момент скрипт выполняет метод, который может привести к "зависанию" терминала, то это уже совсем не корректно, а вполне себе ошибка. И чтобы её избежать необходимо понимать какие методы необходимо обрамлять предварительной проверкой на наличие соединения.
 
Цитата
Nikolay написал:
Цитата
Oleg Kuzembaev написал:
Тест проводился на подключенном к серверу терминале, что является корректным условием для работы скрипта.
Зря Вы это написали, т.к. в таком случае документацию необходимо обновлять и точно указывать для каких методов не гарантируется корректная работа при отсутствии соединения. Более того, если в процессе работы происходит разрыв соединения и в этот момент скрипт выполняет метод, который может привести к "зависанию" терминала, то это уже совсем не корректно, а вполне себе ошибка. И чтобы её избежать необходимо понимать какие методы необходимо обрамлять предварительной проверкой на наличие соединения.
если правильно понял, то зависание происходит при отсутствии лимитов
Такая ситуация невозможна при разрыве соединения.
Ситуация возникает лишь при старте терминала.
Да и то при отсутствии колбека конфигурации, цикла в main и каких-либо ожиданий прихода данных,
либо проверки их доступности.
Более нелепого (мягко скажу)  скрипта я еще не видел.
----------------------------
Но соглашусь, что зависания не должно быть даже в самых  дурацких скриптах.
------------------------------------
Раньше такой же эффект был с функцией получения пути к скрипту, если ее поставить первой строкой в скрипте.
Проблему после указания на нее исправили.
 
Цитата
Oleg Kuzembaev написал:
Тест проводился на подключенном к серверу терминале
На момент публикации моего сообщения 30.05.2026 getDepoEx в опубликованном скрипте не завершала работу как при подключении к серверу, так и без подключения. Как я раннее писал, зависание происходит не всегда. И, помимо открытого графика, на это влияют лимиты по бумаге, которые запрашиваются в getDepoEx. В другой день, с другими лимитами, с другими параметрами в запросе зависания может не происходить. Поэтому я и сохранил то состояние, при котором можно гарантированно воспроизвести проблему и найти ошибку.
Спустя несколько дней, когда вы всё-таки соизволили запустить тест, лимиты по счёту 10382 уже обновились. Если вы вообще проверяли на том же счёте.
Но, видимо, ваша цель не устранение ошибок в вашем софте, а - отчитаться, что "у нас всё хорошо".

Цитата
Oleg Kuzembaev написал:
на подключенном к серверу терминале, что является корректным условием для работы скрипта.
Является ли вызов функции getDepoEx при отсутствии соединения с сервером некорректным?
Добавьте тогда в документацию, какие функции нельзя запускать при отсутствии соединения с сервером и что необходимо предпринять при разрыве соединения с сервером.
 
Цитата
Oleg Kuzembaev написал:
Тест проводился на подключенном к серверу терминале
А на каком счёте тестировали? С рабочего места из моего архива или со своего, со своими настройками?
Поэтому я и спросил, что показывает у вас скрипт из сообщения #6, чтобы понимать, а то ли вы вообще тестировали.
 
При тестировании использовался представленный вами терминал с исходным скриптом. Воспроизвести ошибку не удалось.
А также была проведена попытка повторить ошибку на другом терминале с исходным скриптом и с измененной версий. Повторить не удалось.

Для анализа проблемы потребуется дамп файл, который нужно получить с     помощью утилиты procdump со специальной командной строкой,     инструкцию приводим ниже:
   
    Утилита Procdump доступна по ссылке https://download.sysinternals.com/files/Procdump.zip,     нужно скачать архив Procdump.zip и распаковать его в отдельный     каталог.
    Как только терминал зависнет (а если получится, то немного перед     этим) нужно из каталога с утилитой выполнить команду:
    procdump.exe -s 1 -n 30 -accepteula info.exe .
   
    После этого в каталоге, откуда выполняли команду, появятся эти     DMP-файлы.
    Просьба выполнить эту инструкцию и отправить архивом эти файлы. Для этого выложите на     удобный для вас файлообменник и предоставьте ссылку на архив.
 
Цитата
Oleg Kuzembaev написал:
Воспроизвести ошибку не удалось.
После подключения к серверу спустя несколько дней лимиты по бумагам обновляются. Очевидно, что это уже не те данные, на которых воспроизводилась ошибка в представленном скрипте.
Вы проверяли на моём архиве без подключения к серверу?
 
Проверка проходила с подключением и без него.
 
Oleg Kuzembaev, все пользователи (целых два человека), которые провели тестирование на данных из архива, сообщают, что проблема воспроизводится.
Что у вас показывает скрипт из сообщения #6?
Страницы: 1
Читают тему
Наверх