Как завалить AOS AX 2009

[fed]

У нас вчера падало при попытке исполнения следующего кода:

while select    vInventBatch3
        join            vInventDim
        where           vInventBatch3.EraIsvInventDimId == vInventDim.inventDimId
                        &&
                        vInventDim.InventSiteId == vSiteId
                        &&
                        vInventDim.InventLocationId == vInventLocationId
        join            vInventBatchPrice2
        where         vInventBatchPrice2 &&
                         vInventBatchPrice2.inventBatchId == vInventBatch3.inventBatchId
                        &&
                        vInventBatchPrice2.itemId == vInventBatch3.itemId
        {
            ..
        }

Каким-то макаром компилятор пропустил конструкцию 'join table where table && table.field==constant', но сервер во время исполнения умирал выдавая на рабочую станцию сообщение типа "Internal error number 174 found in script".

Аналогичная ситуация была когда программист написал что-то типа:
Select table1
where table1.field1==constant || (table2 && table1.field==table2.field). Хотя здесь я точную форму запроса-убийцы не помню. Идея состояла в том, что сервер похоже что пытался table2 как-то засунуть в сгенерированный SQL-запрос, но сходил с ума и падал. Сообщение было таким-же. Вылечили заменив вторую половину условия на (table2.recid!=0 && table1.field==table2.field).
Справедливости ради, замечу что у нас не очень свежее ядро (примерно февральское).

[gl00mie]

Цитата:

Сообщение от fed

Аналогичная ситуация была когда программист написал что-то типа:

Select table1 where table1.field1==constant || (table2 && table1.field==table2.field).

Вылечили заменив вторую половину условия на (table2.recid!=0 && table1.field==table2.field)

Приведенный запрос - именно то, с чего началась тема! Если в select проверяется табличный буфер на "непустоту", а буфер на самом деле совсем пустой (null), и все это работает с клиента, то АОС валится на раз. И лечится как раз аналогично - переделкой проверки с буфера целиком на какое-то из его полей.

[fed]

Цитата:

Сообщение от gl00mie

Приведенный запрос - именно то, с чего началась тема! Если в select проверяется табличный буфер на "непустоту", а буфер на самом деле совсем пустой (null), и все это работает с клиента, то АОС валится на раз. И лечится как раз аналогично - переделкой проверки с буфера целиком на какое-то из его полей.

Не уверен. Там все на сервере работало. Вообще после того как я по неформальным каналам спросил знакомых в микрософте, они там выковырали описание внутренней ошибки 174, типа это означает "Какая-то фигня в выражении where". То есть - мне кажется что там все-таки сервер пытался сгенерить именно select с table2, но накрывался при попытке найти подходящее место.

[Logger]

Цитата:

Сообщение от fed

Не уверен. Там все на сервере работало.

Зачтено

Считаем это другим случаем завала АОСА.
Счет в серии 1:1:1

Кто больше ?

[Logger]

Цитата:

Сообщение от fed

То есть - мне кажется что там все-таки сервер пытался сгенерить именно select с table2, но накрывался при попытке найти подходящее место.

Что больше всего напрягает в этой ситуации - почему сервер накрывается ? Ну отваливался бы рабочий поток с одной сессией пользователя и все, так ведь аос целиком ложится!
В 3-ке, например, при попытке распаковать на сервере наследник RunBaseBatch-а из кривого контейнера, клиент отваливался, а серверу хоть бы что , несмотря на то что код исполнялся на сервере.

[gl00mie]

Цитата:

Сообщение от Logger

Что больше всего напрягает в этой ситуации - почему сервер накрывается ? Ну отваливался бы рабочий поток с одной сессией пользователя и все, так ведь аос целиком ложится!

Мне кажется, AOS просто не ловит соответствующие исключения, а раз так, то возникают они где-то там, где он не ожидает их словить. Вспоминается, как он валился однажды - при этом в eventlog писалось (виндой, а не самим AOS'ом) следующее:

Faulting application name: Ax32Serv.exe, version: 5.0.1500.2985, time stamp: 0x4c29d4fc
Faulting module name: Ax32Serv.exe, version: 5.0.1500.2985, time stamp: 0x4c29d4fc
Exception code: 0xc0000005
Fault offset: 0x0000000000650359
Faulting process id: 0x834
Faulting application start time: 0x01cb21cd511ff28c

Что примечательного в этом сообщении? А то, что виртуальный адрес 0x0000000000650359 находится посреди процессорной инструкции - вблизи него исполняемый код выглядит так:

.00000000`00650355: 4084FF     test  dil,dil
.00000000`00650358: 7411       jz   .00065036B
.00000000`0065035A: 488903     mov   [rbx],rax
.00000000`0065035D: 488B4630   mov   rax,[rsi][030]
.00000000`00650361: 483B18     cmp   rbx,[rax]
.00000000`00650364: 7517       jnz  .00065037D

т.е. по адресу 0x0000000000650358 начинается двухбайтовая инструкция условного перехода. Если же начать смотреть с адреса 0x0000000000650359, то увидим совсем левый код:

.00000000`00650359: 114889     adc  [rax][-077],ecx
.00000000`0065035C: 03488B     add  ecx,[rax][-075]
.00000000`0065035F: 4630483B   xor  [rax][03B],r9b
.00000000`00650363: 187517     sbb  [rbp][017],dh

Т.е. управление перешло по левому адресу (так совпало, что в сегмент кода, а могло бы куда угодно). Отсюда вывод: либо у AOS'а разрушился стек, либо он криво инициализировал какие-то структуры в памяти, используемые для передачи управления. При таком раскладе не удивительно, что он валится целиком, а не просто отстреливает одну сессию, как в трешке.

[_scorp_]

Цитата:

Сообщение от Logger

почему сервер накрывается ?

Потому что криво написали обработку исключений на сервере.

[Logger]

Цитата:

Сообщение от _scorp_

Потому что криво написали обработку исключений на сервере.

Ну это понятно.
Вопрос почему такое допустили. Неприятно когда у тебя в системе одновременно вылетает 150 юзеров.