ACCESS VIOLATION в Quik 9.3.3.3 при запуске скрипта без сторонних DLL

Страницы: 1
RSS
ACCESS VIOLATION в Quik 9.3.3.3 при запуске скрипта без сторонних DLL
 
Добрый день!

Скрипт, который работал без проблем в версии 8.11, перестал работать в версии 9.3.1.11. Обновление до 9.3.3.3 проблему не решило (см. скриншот).

Сторонние библиотеки не используются вообще. Ни на Lua, ни DLL, т.е. проблема в самом терминале без вариантов. Крэш происходит при запуске скрипта как версией интерпретатора 5.3, так и 5.4

Удалось локализовать проблему в следующих строках:
Код
            SetColor( gSpreadsTable, line, SPREADS_COL_ADJUSTED_BUYER_FORCE, buyerForceBgColor, buyerForceFgColor,
                QTABLE_DEFAULT_COLOR, QTABLE_DEFAULT_COLOR );
            SetColor( gSpreadsTable, line, SPREADS_COL_ADJUSTED_SELLER_FORCE, sellerForceBgColor, sellerForceFgColor,
                QTABLE_DEFAULT_COLOR, QTABLE_DEFAULT_COLOR );
            SetColor( gSpreadsTable, line, SPREADS_COL_MARKET_FORCE_SHORT, QTABLE_DEFAULT_COLOR, mktForceFgColor,
                QTABLE_DEFAULT_COLOR, QTABLE_DEFAULT_COLOR );
            SetColor( gSpreadsTable, line, SPREADS_COL_MARKET_FORCE_LONG, QTABLE_DEFAULT_COLOR, mktForceFgColor,
                QTABLE_DEFAULT_COLOR, QTABLE_DEFAULT_COLOR );

Эти строки выполняются в цикле для каждой строки таблицы по мере обновления данных в ней. Крэш устраняется, если сделать следующие изменения:
Код
            SetColor( gSpreadsTable, line, SPREADS_COL_ADJUSTED_BUYER_FORCE, buyerForceBgColor, buyerForceFgColor,
                QTABLE_DEFAULT_COLOR, QTABLE_DEFAULT_COLOR );
            SetColor( gSpreadsTable, line, SPREADS_COL_ADJUSTED_SELLER_FORCE, sellerForceBgColor, sellerForceFgColor,
                QTABLE_DEFAULT_COLOR, QTABLE_DEFAULT_COLOR );
            --SetColor( gSpreadsTable, line, SPREADS_COL_MARKET_FORCE_SHORT, QTABLE_DEFAULT_COLOR, mktForceFgColor,
            --    QTABLE_DEFAULT_COLOR, QTABLE_DEFAULT_COLOR );
            --SetColor( gSpreadsTable, line, SPREADS_COL_MARKET_FORCE_LONG, QTABLE_DEFAULT_COLOR, mktForceFgColor,
            --    QTABLE_DEFAULT_COLOR, QTABLE_DEFAULT_COLOR );

Идентификаторы колонок определены следующим образом:
Код
SPREADS_COL_ADJUSTED_BUYER_FORCE = 5;
SPREADS_COL_ADJUSTED_SELLER_FORCE = 6;
SPREADS_COL_MARKET_FORCE_SHORT = 15;
SPREADS_COL_MARKET_FORCE_LONG = 16;

Переменная mktForceFgColor может принимать одно из трех значений: QTABLE_DEFAULT_COLOR, RGB( 0, 200, 0 ), RGB( 200, 0, 0 )

Проблема серьезная, требует оперативного решения!
 
bstone, Если "проблема серьезная, требует оперативного решения", так закомментируйте все эти строки - это всего лишь раскраска. :smile:

Кроме того, резануло глаз: "Переменная может принимать одно из трех значений: RGB( 0, 200, 0 )". При чём тут RGB? Поставьте нормальные цвета обычными константами. Больше в коде ошибок не вижу, только длиннющие имена раздражают - хрен поймёшь, где там начало, где конец.
 
Владимир, серьезность проблемы заключается в критической нестабильности последних версий терминала при выполнении скриптов на Lua, информация о которой поможет разработчикам продукта. Пока что мне удалось изолировать один из триггеров, но нет никаких гарантий, что все ограничивается лишь вызовами SetColor(). Я рад, что для вас это всего лишь раскраска, но вам явно не приходило в голову, что она появилась в коде не просто так. Иначе бы ее не было изначально.

При чем тут RGB? RTFM

И спасибо за ваше ценное мнение о длине идентификаторов и ошибках. Однако я сразу отметил, что код стабильно работал в 8-х версиях терминала. Ошибок в нем действительно нет.
 
Похожая проблема уже была озвучена ранее, но тогда от нее отмахнулись, т.к. она была в версии 9.3.1.11:
Critical error ACCESS_VIOLATION in script...

Следует отметить, что у меня тоже иногда сообщение об ошибке выглядит как на моем скриншоте, а иногда как "Critical error ACCESS VIOLATION..."
 
bstone, А вот "критическая нестабильность последних версий терминала" и меня достала выше крыши - я просто боюсь новых версий, которые постоянно модифицируются по идиотским пожеланиям местной публики в результате чего перестаёт работать даже то, что раньше работало.

Это ДЛЯ ВСЕХ "всего лишь раскраска", я ею пользуюсь более, чем активно - мои таблицы вообще раскрашены как попугай, и вызовы организованы примерно так:
SetColor(table,row,col,0xFF00,0xCCCC,-1,-1);
RGB - это функция, которое возвращает трёхбайтовое число, так я использую само это число. А если Вы будете присваивать переменной функцию, а не её результат, то кто знает, какая моча интерпретатору в голову вдарит?
 
Цитата
bstone написал:
Эти строки выполняются в цикле для каждой строки таблицы по мере обновления данных в ней. Крэш устраняется, если сделать следующие изменения:
Дело совсем не в этих строках.
Ошибка возникает или накапливается совсем в другом месте. Просто у тебя так совпало, что наличие именно этих строк выглядит критичным.

Ну вот просто: -чем две закоментаренные строки отличаются от двух предыдущих?
И нет никакой гарантии, что если убрать все четыре SetColor-а то падать перестанет. Просто будет падать в другом месте, при других условиях.
Цитата
bstone написал:
Похожая проблема уже была озвучена ранее, но тогда от нее отмахнулись, т.к. она была в версии 9.3.1.11:
Хочу заметить, что тут картина наоборот. на 9.2 работает, а на 8.11 ломается.
Цитата
bstone написал:
Однако я сразу отметил, что код стабильно работал в 8-х версиях терминала. Ошибок в нем действительно нет.
Так себе утверждение.
Если код выполняется - не факт что он не содержит ошибок.
Просто не создавались условия, при которых они возникают.

Нужен полный код скрипта, чтобы изучив его с какой-то уверенностью говорить что он "не содержит ошибок".
 
Kalmar, код выполняется интерпретатором Lua и не использует DLL. Что в нем может вызывать AV в 9-й версии терминала, что не вызывало AV в 8-й? Очевидно, что это не код самого скрипта, который не имеет доступа к адресному пространству ни процесса интерпретатора, ни терминала.

Цитата
Kalmar написал:
Ну вот просто: -чем две закоментаренные строки отличаются от двух предыдущих?И нет никакой гарантии, что если убрать все четыре SetColor-а то падать перестанет. Просто будет падать в другом месте, при других условиях.
Ну я пишу, что есть по факту. Скрипт молотит без этих строк и не рушит терминал. С ними крэш воспроизводится 100%. Из чего следует, что работа с таблицами из Lua сломана в 9-й версии.
Цитата
Kalmar написал:
Хочу заметить, что тут картина наоборот. на 9.2 работает, а на 8.11 ломается.
Действительно, не обратил внимания! Немного сбило с толку, что там попросили воспроизвести в 9.3.3.3  
 
bstone, здравствуйте.

Просьба прислать полный код используемого скрипта, запуская который сталкиваетесь с ошибкой AV для анализа
 
Цитата
Daniil Pozdnyakov написал:
bstone, здравствуйте.

Просьба прислать полный код используемого скрипта, запуская который сталкиваетесь с ошибкой AV для анализа
Такая же ошибка. Удалось воспроизвести ее и выделить.
на QUIK 9.4.2.1 и 9.5.0.42 и 9.2.0.121
LUA 5.4.1

Полный код:

Код
dofile(getScriptPath() .. "\\dll_test_crash.lua")
is_run = true                  

function OnInit()                                                   

   KomCentrID = AllocTable()                                       
   AddColumn (KomCentrID, 10, "Описание/Действие", true, QTABLE_STRING_TYPE,60)   
   AddColumn (KomCentrID, 20, "Результат", true, QTABLE_STRING_TYPE,20)   
   CreateWindow(KomCentrID)   
   SetWindowPos(KomCentrID,1100,250,400,500)
   
end

function main()                                             
   while is_run do                                          
      Body()                                             
   end
end


function OnStop()                                 
    is_run = false            
end
Код
function Body()                  

sleep(100)

InsertRow(KomCentrID,1)
SetCell(KomCentrID, 1, 10,  "COMPLETE")
SetCell(KomCentrID, 1, 20,  "COMPLETE")
SetColor(KomCentrID,1,20,RGB(217,255,217),RGB(1,1,1),RGB(220,220,220),RGB(0,0,0)) --зеленый

end

Через примерно 100-200 вызовов Body(), QUIK либо закрывается, либо ошибка ACCESS VIOLATION

Посмотрите плиз, дампы также могу выслать.

 
Кстати, если вместо ячейки
Код
SetColor(KomCentrID,1,20,RGB(217,255,217),RGB(1,1,1),RGB(220,220,220),RGB(0,0,0)) --зеленый
закрашивать целую строку
Код
SetColor(KomCentrID,1,QTABLE_NO_INDEX,RGB(217,255,217),RGB(1,1,1),RGB(220,220,220),RGB(0,0,0)) --зеленый
тогда все работает
 
Сергей, Во-первых, уберите нафиг RGB - эта, с позволения сказать, функция возвращает трёхбайтовое число, старший байт которого - B, а младший - R. Во-вторых, в SetColor добавьте ещё два аргумента: -1, он же QTABLE_NO_INDEX.
 
Цитата
Владимир написал:
Сергей, Во-первых, уберите нафиг RGB - эта, с позволения сказать, функция возвращает трёхбайтовое число, старший байт которого - B, а младший - R. Во-вторых, в SetColor добавьте ещё два аргумента: -1, он же QTABLE_NO_INDEX.
С RGB понял идею - передавать сразу значения, не используя доп функцию.
Кстати, есть уже опыт, что использование RGB  может вызывать ACCESS VIOLATION или это вопрос к разработчикам?

С QTABLE_NO_INDEX не понял
Мне же нужно закрасить конкретную ячейку и значит нужно передать конкретные значения. По количеству вроде везде всех аргументов хватает.
 
Цитата
Владимир написал:
Сергей, Во-первых, уберите нафиг RGB - эта, с позволения сказать, функция возвращает трёхбайтовое число, старший байт которого - B, а младший - R. Во-вторых, в SetColor добавьте ещё два аргумента: -1, он же QTABLE_NO_INDEX.
Переделал вот так
Код
SetColor(KomCentrID,1,20,14286809,65793,-1,-1) --зеленый

Красит 100-200 ячеек, дальше ACCESS VIOLATION

 
Сергей, Не знаю, я никогда не пользовался RGB - я сразу давал на вход число вместо функции.
Нет, должно быть ЕЩЁ ДВА аргумента, типа:
SetColor(KomCentrID,1,20,RGB(217,255,217),RGB(1,1,1),RGB(220,220,220),RGB(0,0,0),-1,-1)
Или вот, например, фрагмент кода моего скрипта:
SetColor(T,a[i][0][9],4,D[X(a[i][2][2])],0,-1,-1);
 
Нет, кажется, это я обсчитался с количеством аргументов.  :smile:  
 
Да, ещё момент: ГДЕ ИМЕННО Вы это дело красите? Всё это дело нужно выполнять в потоке мейна.
 
Цитата
Владимир написал:
Да, ещё момент: ГДЕ ИМЕННО Вы это дело красите? Всё это дело нужно выполнять в потоке мейна.

Да, все верно, именно в main . Выше выкладывал код всего скрипта, там видно.

Сейчас запустил в Quik 8.3.1.38 — все отлично работает.

Разработчики помогите! )
 
Сергей, А там может быть вообще всё, что угодно. Я не так давно поменял девятку снова на восьмёрку - там было и Internal error, и Unknown hard error, и General protection error, и, возможно, ещё что-то.
 
Владимир, ну вот да.
Ошибка то воспроизводится легко, может разработчики обратят внимание.
 
Цитата
Сергей написал:
Цитата
Полный код:

 
Код
  dofile( getScriptPath ()  ..   "\\dll_test_crash.lua" )
is_run  =   true                   

 function   OnInit ()                                                   

   KomCentrID  =   AllocTable ()                                       
    AddColumn  (KomCentrID,  10 ,  "Описание/Действие" ,  true , QTABLE_STRING_TYPE, 60 )   
    AddColumn  (KomCentrID,  20 ,  "Результат" ,  true , QTABLE_STRING_TYPE, 20 )   
    CreateWindow (KomCentrID)   
    SetWindowPos (KomCentrID, 1100 , 250 , 400 , 500 )
   
 end 

 function   main ()                                             
    while  is_run  do                                           
      Body()                                             
    end 
 end 


 function   OnStop ()                                 
    is_run  =   false             
 end   
 
Код
   function   Body ()                  

 sleep ( 100 )

 InsertRow (KomCentrID, 1 )
 SetCell (KomCentrID,  1 ,  10 ,  "COMPLETE")
 SetCell (KomCentrID,  1 ,  20 ,  "COMPLETE")
 SetColor (KomCentrID, 1 , 20 , RGB ( 217 , 255 , 217 ), RGB ( 1 , 1 , 1 ), RGB ( 220 , 220 , 220 ), RGB ( 0 , 0 , 0 ))  --зеленый 

 end   
    Через примерно 100-200 вызовов Body(), QUIK либо закрывается, либо ошибка ACCESS VIOLATION  Посмотрите плиз, дампы также могу выслать.      
Ошибка возникает потому, что Вы создали таблицу с дырками
Если у Вас максимальный номер 20, то надо создать все столбцы с номерами от 1 до 20.
------------------
Пример как надо, чтобы не было мучительно больно
Код
is_run = true

function OnInit()
   KomCentrID = AllocTable()
   for i=1,20 do  AddColumn (KomCentrID,i, "столб."..tostring(i), true, QTABLE_STRING_TYPE,8)  end --надо так
 --  AddColumn (KomCentrID, 10, "столб.10", true, QTABLE_STRING_TYPE,8)   AddColumn (KomCentrID, 20, "столб.20", true, QTABLE_STRING_TYPE,8)    -- а не так
   CreateWindow(KomCentrID)
   SetWindowPos(KomCentrID,110,250,1100,500)
   InsertRow(KomCentrID,-1)
end

function main()

   while is_run do
      Body()
     sleep(100)
   end
end

function OnStop()
    is_run = false
end

function Body()
InsertRow(KomCentrID,1)
SetCell(KomCentrID, 1,10,  "COMP")
SetCell(KomCentrID, 1,20,  "COMP")
SetColor(KomCentrID,1,20,RGB(217,255,217),RGB(1,1,1),RGB(220,220,220),RGB(0,0,0))
SetColor(KomCentrID,1,10,RGB(255,255,0),RGB(1,1,1),RGB(220,220,220),RGB(0,0,0))
end


если вы закомментируете строку for i=1,20..
и удалите коммент в следующей, то получите ваш результат.
Успехов
 
nikolz, Это с какого бодуна, лапуль? В этом дурацком языке ВААПЩЕ НЕ БЫВАЕТ таблиц с дырками. Опять полуграмотные идиоты путают ключи с индексами? В одном из самых первых моих сообщений на этом форуме я писал:
В общем, с языком почти всё ясно: граф (точнее, дерево) объектов построить можно, а простейшую таблицу или даже массив - нельзя.

Лично я действительно всегда создавал столбцы по порядку, начиная с нулевого, а анализируя с минус первого - просто так удобнее. Но мне и в страшном сне не могло присниться, что они должны быть созданы ВСЕ. АУ! ТЕХПОДДЕРЖКА! Неужели этот бред действительно правда? Неужели софт НАСТОЛЬКО убог?
 
nikolz, спасибо, так действительно работает. Привычка с бейсика, нумеровать 10,20,30

В самом деле, бывают же ситуации, когда колонка больше не нужна или нужно вставить колонку между другими. Да и 8.3 работает.
Страницы: 1
Читают тему
Наверх