Всем привет!

В системе завелся странный полтергейст. Выглядит то следующим образом: Периодически при проводке (предварительно созданной) счет-фактуры в miro или mir4 случается дамп. (Творится это в течение уже 2-х лет, но сейчас проблема стала заметно актуальна). Каких-либо закономерностей обнаружить не удалось. Проблема плохо воспроизводима. Разные счет-фактры у разных пользователей в разное время. Примерно в 5% проводок это происходит. В QAS (копии системы) воспроизвести ни разу не получилось. Дамп - RAISE_EXCEPTION ERROR_DP в программе C_TEXTEDIT_CONTROL================CP. Если попробовать пройти в дебагере, выполняя эту проводку, и сравнить со стеком вызовов из дампа, то видно что развилка в выполнении ABAP когда дамп случается в ФМ MRM_INVOICE_POST на строке IF NOT editor IS INITIAL. Если условие выполняется - то вызывается форма text_save и в ней (а точнее в методе который она в свою очередь вызывает GET_TEXT_AS_R3TABLE) - и случается дамп. Т.е. в тех редких 5% случаев переменная editor (глобальная) каким-то образом получает некое значение (и затем случается дамп). В коде MRM_INVOICE_POST единственная операция с editor выгдядит как MOVE i_editor TO editor. Более ничего через поиск в коде не обнаруживается. В стеке вызовов дампа видно что i_editor подается на вход MRM_INVOICE_POST как INITIAL. Но затем каким-то чудесным образом внутри MRM_INVOICE_POST editor получает некое значение (ссылку на адрес класса - это так же видно в секции дампа Вызовы), вызывает по условию IF форму text_save - ну и далее случается дамп.
Надеюсь описал ситуацию достаточно внятно

вероятно открывали закладку нотиса (текст примечаний в заголовке) ,
экран saplmr1m 6160, ссылка на контрол(окошко) с текстом осталась,
а с самим контролом к моменту сохранения что-то произошло,
контрол при попытке сохранения нотиса попытался определить свои
размеры через data provider и не смог

trop, спасибо!
Это уже другая проблема что с контролом что-то происходит. Повторюсь - в обычной ситуации дело до C_TEXTEDIT_CONTROL================CP вообще не доходит.
Т.е. при попытке воспроизвести ставим брейкпоинт в text_save - бегаем по всем закладкам - все что видим - и проводим. В точку прерывания не попадаем.
Интересно как так случается, что editor приобретает изневедома значение? Как это может случаться?

editor только на pbo экрана 6160 может получить значение,
экран вызывается при входе на закладку с примечаниями в заголовке

покажите стэк из дампа: abap->активные вызовы

Инициализировать контрол можно и в BADI INVOICE_UPDATE, в методе IF_EX_INVOICE_UPDATE~CHANGE_AT_SAVE , к примеру.

За любителями ASSIGN нужен глаз да глаз.

Я думаю, что проблема поглубже будет, примерно как в этой теме Abap dump error after putting text into the "Note Tab" of MIRO
Что-то связанное с вызовом ФМ или апдейта с последующим коммитом в расширении.

остаётся ставить точки на commit, rollback и в конструкторе контрола,
и можно убедиться, что в (sapmssy0)orders[] есть строка saplmr1m editor_reset

https://yadi.sk/i/SGVuQCZiq49YN
https://yadi.sk/i/4d58CgPkq49aX
https://yadi.sk/i/is7nypPqq49b6

Это фотки дампа.

Джон, инициализировать editor можно из кучи мест, это мне понятно. Например если заполнить закладку Notes заголовка счет-фактуры (тот самый экран, о котором пишет trop).
НО вот какая фигня (мне неясная) - в этом случае i_editor конечно будет проинициализирована тоже, выше по стеку вызовов в MRM_INVOICE_POST. И тут никакой магии нет.
Просто насколько я понимаю, в случае той последовательности шагов, при которой случается дамп - editor как-то ловко приобретает некое значение. Должно быть видно на этих 3-х фотках.

Джон, Abap dump error after putting text into the "Note Tab" of MIRO - у этих товарищей немного другой случай. Они сделали в энхансменте соммит. И у них как я понимаю - ВСЕГДА, если заполнить notes - случается этот дамп, поскольку при заполненном notes стандарт вызывает некорректную Z-логику.
У меня же в NOTES все чисто. Никаких пробелов и подобного не замечено. Тем не менее иногда дамп.
Если поле NOTES заполнить - дампа нет. У проведенных счет-фактур, на которых случился дамп - чем-либо заполненного NOTES мной не замечено (возможно потому что в системе нет ни одной счет фактуры с заполненным notes).

trop, целиком дамп выложить не могу - закрытый контур. Но могу пофоткать нужные части..

Да, к большому сожалению невозможно сторнировать проведенную с дампом счет-фактуру чтобы попытаться повторить трюк (и понять - дамп зависит от данных или от веления господне)

Вижу, что Вы суть не уловили. В той теме не уточняется для каких фактур вызывается процедура с коммитом. Вполне возможно, что также как и у Вас в 5% случаев срабатывает. Но и это совсем не важно. Основной посыл - ищите проблему в своих расширениях. Вы же продолжаете упорствовать, что это стандартный код все портит.
В принципе, Ваше право - пусть это останется волшебством или фичей, раз Вы уже 2 года с этим живете.

(saplmr1m)editor прокидывается из подпрогр parked_document_post(saplmr1m)
-> MRM_PARKED_INVOICE_POST -> MRM_INVOICE_CREATE -> MRM_INVOICE_POST
в стандарте i_editor прокидывается в каждом ф/м по ссылке,
а у вас в дампе i_editor=(saplmr1m)editor пуст, а (saplmrmp)editor заполнен
(i_editor и editor в ф/м MRM_INVOICE_POST разведены в разные переменные,
первая из вызывающей гр/ф MR1M, а вторая в гр/ф MRMP)

imho всего 2 варианта:

1) (saplmr1m)editor был пуст и какой -то код заполнил (saplmrmp)editor
в ф/м MRM_INVOICE_POST - между строками :319 move i_editor to editor и :2031 perform text_save,
но если бы было так, то явных причин для дампа вроде нет

2) (saplmr1m)editor был заполнен и передан при вызове подпрогр parked_document_post(saplmr1m),
(saplmrmp)editor заполняется стандартом до вызова ф/м MRM_INVOICE_POST в MRM_INVOICE_PARK :1136
через оператор копирования (move), значением из вызывающей гр/ф - (saplmr1m)editor ,
значит вероятно дело в преждевременном закрытии sap luw через операторы commit|rollback,
т.е. в MRM_INVOICE_POST переменная i_editor, она же (saplmr1m)editor скорее всего очистилась при вызове
commit work где-то в Z через заблаговременный вызов подпрогр perform editor_reset(saplmr1m) on commit
стандартом, контрол был удалён (CALL METHOD editor->destroy_control),
а прежняя ссылка в (saplmrmp)editor осталась, что и привело к дампу

если вариант 2), то надо поставить точку прерывания на MRM_INVOICE_PARK :1136
в месте копирования ссылки на контрол, остановиться там и поставить точку на оператор commit и rollback,
если такой вызовется не однократно в стандарте, а где-то в Z, то надо найти виновника и замучать его

1)вариант - если сделать поиск "where used" для editor - то между строками 319 и 2031 MRM_INVOICE_POST ничего нет. М.б. не так ищу? Не АБАПер :J

2)вариант - про присвоение editor в MRM_INVOICE_PARK - хорошо понятно. А далее - совсем не понятно :J. Как я понимаю из инфы дампа,
на вход в MRM_INVOICE_POST i_editor была передана чистой. Или не так? Т.е. в моем понимании не важно как и было ли вообще присвоено значение в MRM_INVOICE_PARK,
если затем уже в MRM_INVOICE_POST editor был перезаписан значением i_editor (строка :319).
"скорее всего очистилась при вызове commit work где-то в Z" - это речь про Z внутри MRM_INVOICE_POST? Но там нет нигде ни editor ни i_editor, либо я не верно ищу.
B не уверен что там есть Z вообще (сори, не умею отличать стандартные энхансменты от кастом).
Верно ли я понял, что должно быть: 1) что-то, что вызывается в MRM_INVOICE_POST и возвращает i_editor? 2) либо что-то, что вызывается внутри MRM_INVOICE_POST и обращается с editor?

Джон, сенкс, я только пытаюсь найти ошибку в своем понимании как тут все это работает.

емнип, вероятный сценарий того, что происходит по времени:
1) MR1M: заполнено примечание в заголовке
2) MR1M: т.к. примечание заполнено, произойдет вызов -
perform text_save(saplmr1m), в котором отложенный вызов - perform editor_reset(saplmr1m) on commit,
т.е. отложена подпрограмма удаления контрола в момент срабатывания оператора
commit work (завершение sap luw).
в любой транзакции sap (не путать с транзакцией бд) commit work д.б. единственным
для атомарности, т.к. он запускает задачу обновления (update вызовы, отложенные вызовы arfc/qrfc/trfc)
3) MR1M -> MRMP: нажата кнопка моделирования (передача управления mr1m -> mrmp, копирование ссылки на контрол (editor)),
на этот момент в (saplmr1m)editor и (saplmrmp)editor содержат одинаковую ссылку
4) MRMP: вероятно где-то в z коде был вызван оператор commit work (sap luw закрыт преждевременно при моделировании),
при этом произошел вызов подпрограммы editor_reset(saplmr1m) который был отложен в шаге 2,
контрол удалился, (saplmr1m)editor очистился, но копия ссылки в (saplmrmp)editor осталась
5) MRMP: копия невалидной ссылки (saplmrmp)editor осталась (гр/ф MRMP)
и поэтому произошёл вызов подпрограммы (saplmrmp)text_save
(не путать с (saplmr1m)text_save в которой отложенный вызов)
в котором вызов метода get_text_as_r3table

если правильно понял нерабочего примера у вас нет,
заполняете примечание в заголовке и нажимаете моделирование, но перед этим
надо поставить 2 точки:
- ф/м MRM_INVOICE_PARK в нём происходит копировние ссылки i_editor=(saplmr1m)editor в (saplmrmp)editor,
- строка условия перед вызовом text_save(saplmrmp) в MRM_INVOICE_POST

после того как остановится на первой точке нужно пошагово (через F5) протыкать всё подпрограммы и методы до второй точки -
т.к. в дамп у вас не падает, значит не срабатывают какие-то предпосылки к тому z коду в котором вызов commit work,
и поэтому нужно смотреть внимательно все условные операторы и вызовы в которые не заходит при отладке,
искать там вызов commit work,
смотрите внимательно - в начале подпрограмм|методов|ф/м слева на текущей строке бывает иконка в виде спиральки,
если она есть, то нужно обязательно провалиться (F5), иначе не попадёте в секцию расширения