Падает AOS при расчёте спецификации

[S.Kuskov]

Запускается расчет "тяжелой" спецификации. Узлов в спецификации очень много. Прогресс бар рисует несколько десятков часов.
После пары суток расчета АОС просто стопится и соответственно клиент вылетает.
Пробовали запускать клиента непосредственно на сервере, где находится АОС - результат одинаковый.
Пробовали делать все на одном сервере (база, файлы приложения, АОС, клиент) - не помогает.

Сервер БД: windows server 2008r2 enterprice
Сервер с АОС: windows server 2008r2 enterprice

Текст ошибки
закладка "Общие":

Цитата:

Имя сбойного приложения: Ax32Serv.exe, версия: 5.0.1500.4570, отметка времени: 0x4db04218
Имя сбойного модуля: Ax32Serv.exe, версия: 5.0.1500.4570, отметка времени 0x4db04218
Код исключения: 0xc0000005
Смещение ошибки: 0x00000000006561b0
Идентификатор сбойного процесса: 0x%9
Время запуска сбойного приложения: 0x%10
Путь сбойного приложения: %11
Путь сбойного модуля: %12
Код отчета: %13

закладка"Подробности"

- System 

  - Provider 

   [ Name]  Application Error 
 
  - EventID 1000 

   [ Qualifiers]  0 
 
   Level 2 
 
   Task 100 
 
   Keywords 0x80000000000000 
 
  - TimeCreated 

   [ SystemTime]  2013-05-24T02:40:32.000000000Z 
 
   EventRecordID 99147 
 
   Channel Application 
 
   Computer kadvi-server5.kadvi.net 
 
   Security 
 

- EventData 

   Ax32Serv.exe 
   5.0.1500.4570 
   4db04218 
   Ax32Serv.exe 
   5.0.1500.4570 
   4db04218 
   c0000005 
   00000000006561b0

Текст сообщения, следующего за ошибкой:
Закладка "Общие":

Цитата:

Контейнер ошибки , тип 0
Имя события: APPCRASH
Ответ: Нет данных
Идентификатор CAB: 0

Сигнатура проблемы:
P1: Ax32Serv.exe
P2: 5.0.1500.4570
P3: 4db04218
P4: Ax32Serv.exe
P5: 5.0.1500.4570
P6: 4db04218
P7: c0000005
P8: 00000000006561b0
P9:
P10:

Вложенные файлы:

Эти файлы можно найти здесь:
C:\ProgramData\Microsoft\Windows\WER\ReportQueue\AppCrash_Ax32Serv.exe_9665201e2c522956a130c14e3d3e381a89c83c_1840190a

Символ анализа:
Повторный поиск решения: 0
Идентификатор отчета: 4d5f186e-c41b-11e2-821b-00151782df5c
Состояние отчета: 4

Закладка "Подробности"

- System 

  - Provider 

   [ Name]  Windows Error Reporting 
 
  - EventID 1001 

   [ Qualifiers]  0 
 
   Level 4 
 
   Task 0 
 
   Keywords 0x80000000000000 
 
  - TimeCreated 

   [ SystemTime]  2013-05-24T02:40:33.000000000Z 
 
   EventRecordID 99148 
 
   Channel Application 
 
   Computer kadvi-server5.kadvi.net 
 
   Security 
 

- EventData 

    
   0 
   APPCRASH 
   Нет данных 
   0 
   Ax32Serv.exe 
   5.0.1500.4570 
   4db04218 
   Ax32Serv.exe 
   5.0.1500.4570 
   4db04218 
   c0000005 
   00000000006561b0 
    
    
    
   C:\ProgramData\Microsoft\Windows\WER\ReportQueue\AppCrash_Ax32Serv.exe_9665201e2c522956a130c14e3d3e381a89c83c_1840190a 
    
   0 
   4d5f186e-c41b-11e2-821b-00151782df5c 
   4

Если у кого-нибудь есть какие-нибудь мысли, что с этим можно сделать, то буду премного благодарен за любые советы.

[gl00mie]

Цитата:

Сообщение от S.Kuskov

Если у кого-нибудь есть какие-нибудь мысли, что с этим можно сделать, то буду премного благодарен за любые советы.

Как вариант, можно поискать, на каком месте в коде он падает с access violation (оно же 0xc0000005): emeadaxsupport: Finding the X++ call stack that caused a crash. Тут еще надо не забывать, что для анализа дампа 64-битного приложения надо использовать 64-битный же WinDBG. См. также:

Цитата:

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

...опубликовал серию статей про анализ краш-дампов:
Setting up WinDbg and Using Symbols
Finding the AX user that caused an AOS crash (axforum)
Finding the X++ call stack that caused a crash (axforum)
Finding the AX user and the X++ call stack from a memory dump the easy way
So your AOS crashed, is hanging, or you just want to see what it's doing

добавлено emeadaxsupport: What to do if you have a crash

[S.Kuskov]

Вроде как победил я эту багу. Чего-то определённого найти не удалось. Расчет падал на разных изделиях, на разных окружениях, и даже в разных местах одного и того же повторно запускаемого изделия. Ясно только что падение происходило только на больших изделиях.

Алгоритм расчета условно можно разделить на два этапа.
Первичное построение полного дерева узлов по спецификации изделия.
И последующий обход этого дерева с расчетом и сохранением результата.

Первый этап выполнялся без проблем. Так что никаких циклических ссылок или превышения максимального уровня спецификации не было.
Но вот обход в какой-то непредсказуемый момент рушился. Наступал какой-то критический момент. Не знаю, возможно происходило какое-то некорректное перераспределении памяти этого гигантского дерева.

А дерево действительно гигантское. Там на каждом узле при расчете чего только не сохраняется, включая табличные курсоры. Получается, что вся эта масса рассчитываемых данных, которая в итоге запишется в таблицы расчета в полном объеме будет представлена и в памяти процесса... И я задумался вот над чем. Действительно ли для нужд расчета необходимо одномоментно держать в памяти всё это дерево узлов. Я нашел место в расчете, после которого как мне кажется определенная ветка дерева уже больше не понадобится (когда расчет по ней уже произведен и соответствующие данные - сохранены). Я решил на свой страх и риск принудительно обнулять ссылку на такое поддерево.

В конце метода \Classes\BOMCalcItemLine\recalcBOM

protected void recalcBOM()
{
    ...

    this.parmChildBOMCalc(NULL); // KSM fix crash memory 11.02.2015
}

И это сработало. Изделие, которое ранее не рассчитывалось - рассчиталось!
Результаты расчета других расчетов совпали (по крайней мере у меня )