Регистрация

Критические баги Progress'а

Все, что связано с продуктами корпорации Progress Software: доска объявлений, анонсы, разное
Старожил
Аватара пользователя
Сообщения: 2871
Зарегистрирован: Ср май 12, 2004 6:03 pm
Откуда: Питер

Критические баги Progress'а

Сообщение George » Вт май 28, 2013 5:50 pm

В этой теме предполагаю сообщать о подтвержденных (воспроизводимых) багах Progress'а, которые могут иметь серьезные последствия для Progress'овых баз и/или для работы Progress'овых приложений.

Баг # OE00225722:
65536: maximum number of sub-transactions


Transaction not completely rolled back when more than 65,536 sub-transactions
http://knowledgebase.progress.com/artic ... /000036325
OpenEdge 10.2B05, 10.2B06, 10.2B07, 11.0, 11.1

The fix for this issue is expected to be in the upcoming release 10.2B08.
As of 4/5/2013, release 10.2B08 is scheduled to be released in Q4, 2013 subjected to changes.

Пример такой транзакции:
Код: Выделить всё
do transaction:
  for each table where ...:
    update table.
  end.
end.

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

Ошибки:
SYSTEM ERROR: Index in for recid could not be deleted. (1422)
** <file-name> already exists with <field/value...>. (132)
Причем ошибка 132 может выдаваться для неуникального (!!!) индекса.

На самом деле индексные ключи содержат правильные значения (соответсвующие последним изменениям, сделанным в рамках транзакции), а вот изменения в самих записях могут оказаться потерянными. Из сотен тысяч записей, измененных в рамках большой транзакции, поврежденными могут оказать единицы, а могут и десятки тысяч записей.

Баг исправлен в hotfix'е, который ставится поверх сервис-пака 10.2B07.

Upd: Лечение базы

Логично предположить, что для устранения ошибок нужно перестроить индексы в базе. Но это неправильное решение. Индексы будут построены для записей, в которых были потеряны последние изменения. Например, в одном случае баг проявил себя в большой транзакции, в рамках которой создавались новые записи. Как известно оператор CREATE создает "голенькую" запись - копию template записи, в которой все поля имеют значения по умолчанию. Из-за бага в базе появилось огромное число таких "голеньких" записей. Перестройка индексов удалит индексные ключи, содержавшие актуальные значения полей и проиндексирует никому ненужные пустышки. Физическое состояние базы будет корректным, чего, к сожалению, нельзя будет сказать о логической консистентности базы. Удалить пустышки и потом перестроить индексы? Но это потеря "части" транзакции, а транзакция, как известно, по определению не может завершиться лишь частично. Нужно разбираться, есть ли возможность повторно выполнить операцию только для этих записей или нужно откатить все изменения, сделанные в рамках проблемной транзакции. Т.е. лечение базы, поврежденной этим багом, - задача нетривиальная.

Upd #2:
На данный момент баг исправлен в следующих hotfix'ах:
10.2B0712 Solaris 64-bit
10.2B0716 Linux 64-bit
10.2B0709 Aix 64-bit

Заказаны hotfix'ы под платформы:
HP-UX Itanium2 (IA64)
Linux 32-bit
Последний раз редактировалось George Пн июн 03, 2013 10:06 am, всего редактировалось 1 раз.

Администратор
Аватара пользователя
Сообщения: 1879
Зарегистрирован: Пт мар 25, 2005 6:05 pm
Откуда: Progress Technologies

Re: Критические баги Progress'а

Сообщение Arelav » Чт май 30, 2013 10:58 am

На вашем месте я бы в срочном порядке запросил Hot Fix! :o

Старожил
Аватара пользователя
Сообщения: 2871
Зарегистрирован: Ср май 12, 2004 6:03 pm
Откуда: Питер

Re: Критические баги Progress'а

Сообщение George » Пн июн 03, 2013 10:24 am

An error 12164 occurs when Client Database Request Statement Caching has been enabled for another Linux user and a query is done on the table _Connect or _MyConnection
http://knowledgebase.progress.com/artic ... 000040544/

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

Вышеуказанная статья акцентирует внимание только на ошибке 12164, но умалчивает о настоящей проблеме - пользователи блокируются, ожидая ресурс STCA (promon/R&D/1/4/2. Status: Blocked Clients).

Если вы включаете statement caching через promon или через изменение _Connect-CachingType (как это делает моя программа DbStatMon.p), убедитесь, что права на рабочие каталоги сессий заданы хотя бы как "drwxr--r--".

Старожил
Аватара пользователя
Сообщения: 2871
Зарегистрирован: Ср май 12, 2004 6:03 pm
Откуда: Питер

Re: Критические баги Progress'а

Сообщение George » Вт июн 04, 2013 3:56 pm

George писал(а):Заказаны hotfix'ы под платформы:
HP-UX Itanium2 (IA64)
Linux 32-bit

Hotfix'ы готовы:
10.2B0723 HPUXIA 64-bit
10.2B0723 Linux X86

Обратите внимание, что в файле README есть инструкция по инсталляции hotfix'ов.

Старожил
Сообщения: 16
Зарегистрирован: Пт ноя 16, 2007 5:48 pm

Re: Критические баги Progress'а

Сообщение xGoodWin » Чт ноя 21, 2013 12:58 am

Доброго времени суток!

Платформа Linux 32bit. Версия 10.2B0723. Был установлен SP07, затем hotfix 16, затем hotfix 23.
Нашел следующий баг: на этой версии перестает работать команда proutil db -C holder.

Если откатываешься на версию 10.2B07 (на 10.2B0716!), то команда работает корректно.

Как это победить?

Старожил
Аватара пользователя
Сообщения: 2871
Зарегистрирован: Ср май 12, 2004 6:03 pm
Откуда: Питер

Re: Критические баги Progress'а

Сообщение George » Чт ноя 21, 2013 3:17 am

xGoodWin писал(а):Как это победить?

Сообщить куда надо подробности о баге. :)
Например что в данном случае означает "не работает"?

А proutil -C busy работает?

Был установлен SP07, затем hotfix 16, затем hotfix 23.

После установки hotfix'а права на исполнимые файлы Progress'а установлены именно так как сказано в описании к hotfix'у?

Старожил
Сообщения: 94
Зарегистрирован: Чт май 21, 2009 4:41 pm

Re: Критические баги Progress'а

Сообщение idl » Чт ноя 21, 2013 12:08 pm

Хочу добавить 5 копеек - в readme хотфиксов написано
Код: Выделить всё
chmod +s _dbutil _mprosrv _mprshut prodb _progres _proutil _rfutil prodel _amspriv _dbagent _proapsv _probrkr xsdto4gl _ora* ora*


Видимо, правильнее было бы
Код: Выделить всё
chmod u+s ...


и второе,
_amspriv есть не на всех платформах,
а вот
_pphpriv забыли

Старожил
Сообщения: 16
Зарегистрирован: Пт ноя 16, 2007 5:48 pm

Re: Критические баги Progress'а

Сообщение xGoodWin » Пт ноя 22, 2013 12:58 am

Спасибо за комментарии.

Под тезисом "перестает работать команда proutil db -C holder" я подразумевал отсутствие результата выполнения команды, например:
Код: Выделить всё
$ proutil bank -C holder
OpenEdge Release 10.2B0723  as of Mon May 20 06:31:22 EDT 2013

Код: Выделить всё
$ proutil bank -C busy
OpenEdge Release 10.2B0723  as of Mon May 20 06:31:22 EDT 2013



А при нормальном выполнении команды явно виден результат:
Код: Выделить всё
$ proutil bank -C holder
OpenEdge Release 10.2B07  as of Mon May 20 06:31:22 EDT 2013

** The database bank is in use in multi-user mode. (276)

Код: Выделить всё
$ proutil bank -C busy
OpenEdge Release 10.2B07  as of Mon May 20 06:31:22 EDT 2013

** The database bank is in use in multi-user mode. (276)


George писал(а):После установки hotfix'а права на исполнимые файлы Progress'а установлены именно так как сказано в описании к hotfix'у?


Да, все по инструкции. Но как справедливо заметил idl, корректнее было бы выполнить chmod u+s, _amspriv на нашей платформе нет, а _pphpriv есть.
В итоге, я сделал проще:
Код: Выделить всё
cd $DLC/bin
chown root *
chgrp root *
chmod 755 *
chmod u+s


После этого оба квалификатора (holder & busy) стали отрабатывать корректно - возвращать правильный результат.

Старожил
Аватара пользователя
Сообщения: 2871
Зарегистрирован: Ср май 12, 2004 6:03 pm
Откуда: Питер

Re: Критические баги Progress'а

Сообщение George » Пт ноя 22, 2013 3:29 am

xGoodWin писал(а):Под тезисом "перестает работать команда proutil db -C holder" я подразумевал отсутствие результата выполнения команды

Результатом работы утилит holder/busy в первую очередь является их код возврата, а не текст сообщения, который они выдают в stout.
Впрочем в данном случае и код возврата, скорее всего, был некорректным.

Да, все по инструкции. Но как справедливо заметил idl, корректнее было бы выполнить chmod u+s, _amspriv на нашей платформе нет, а _pphpriv есть.
В итоге, я сделал проще:
Код: Выделить всё
cd $DLC/bin
chown root *
chgrp root *
chmod 755 *
chmod u+s


После этого оба квалификатора (holder & busy) стали отрабатывать корректно - возвращать правильный результат.

Проще не всегда значит правильно. В таком варианте SQL92 будет работать некорректно - для его исполнимого модуля (_sqlsrv2) set-userid бит не нужен и даже вреден.
Тоже самое для _waitfor.

How should I set permissions for Progress executables and database files on UNIX
http://knowledgebase.progress.com/artic ... le/P100887

Старожил
Аватара пользователя
Сообщения: 2871
Зарегистрирован: Ср май 12, 2004 6:03 pm
Откуда: Питер

Re: Критические баги Progress'а

Сообщение George » Ср май 21, 2014 11:29 am

George писал(а):An error 12164 occurs when Client Database Request Statement Caching has been enabled for another Linux user and a query is done on the table _Connect or _MyConnection
http://knowledgebase.progress.com/artic ... 000040544/

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

Вышеуказанная статья акцентирует внимание только на ошибке 12164, но умалчивает о настоящей проблеме - пользователи блокируются, ожидая ресурс STCA (promon/R&D/1/4/2. Status: Blocked Clients).

Данный баг исправлен в hotfix'е 10.2B0807:

Issue ID: PSC00286145
---------------------
Database Request Statement Cache errors when attempting to unlock object but holds no prior lock.

Issue ID: PSC00286643
---------------------
promon -> R&D -> Blocked Clients screen showing many users blocked on STCA lock.
Database performance is impacted and bi file growth is being seen.

Из плохих новостей - нужно быть осторожным с использованием сигнала SIGUSR1 для получения protrace файла проблемного процесса:
kill -s USR1 issued from a script against _progres batch programs sometimes results in a error 49.
http://knowledgebase.progress.com/artic ... 000050309/

Это очень печально поскольку с помощью этого сигнала можно легко и просто получать очень полезную информацию. Через Statement Cache можно получить практически ту же информацию, но для этого нужно иметь наготове соответствующую программу, о необходимости которой народ, как правило, вспоминает только когда "гром уже грянул".

Старожил
Аватара пользователя
Сообщения: 1523
Зарегистрирован: Чт сен 27, 2001 4:00 am
Откуда: Москва

Re: Критические баги Progress'а

Сообщение dmi » Ср май 21, 2014 2:48 pm

George писал(а):Из плохих новостей - нужно быть осторожным с использованием сигнала SIGUSR1 для получения protrace файла проблемного процесса:
kill -s USR1 issued from a script against _progres batch programs sometimes results in a error 49.
http://knowledgebase.progress.com/artic ... 000050309/


У меня 10.2B08/AIX64. При переходе на 10.2B08 с SP06 заметил, что в логах стала появляться 49-ая ошибка. У меня сервер приложений работает с БД через shared memory.
Для поиска долгоиграющих процессов я сделал циклическую процедуру, которая смотрит вывод asbman -query и ищет процессы. Утилита старая и давно при переходе на v10 я дополнил её как раз вызовом proGetStack и анализом AIX-protrace для построения дерева вызовов.
До SP08 проблем не было. Но тут у нас добавилась библиотека по серьезным вызовам веб-сервисов, я на неё грешил - там проблемы были.
Попробую через statement caching сделать (код написан, но пока не работает)
/dmi

http://pro4gl.ru - 4gl блог

Старожил
Аватара пользователя
Сообщения: 2871
Зарегистрирован: Ср май 12, 2004 6:03 pm
Откуда: Питер

Re: Критические баги Progress'а

Сообщение George » Ср май 21, 2014 6:34 pm

dmi писал(а):При переходе на 10.2B08 с SP06 заметил, что в логах стала появляться 49-ая ошибка.

Посмотри в knowledgebase статьи о багах, которые лечатся в V10.2B параметром -reusableObjects 0.
Появление reusable objects, похоже, привело к тому, что Progress'овые сессии превратились в решето, через многочисленные дыры которого утекает память. Такие утечки рано или поздно заканчиваются ошибкой memory violation или другим летальным образом. Protrace файлы, оставленные после таких ошибок, должны указать на их источник.

Но тут у нас добавилась библиотека по серьезным вызовам веб-сервисов, я на неё грешил - там проблемы были.

Memory mapped library?

Старожил
Аватара пользователя
Сообщения: 1523
Зарегистрирован: Чт сен 27, 2001 4:00 am
Откуда: Москва

Re: Критические баги Progress'а

Сообщение dmi » Чт май 22, 2014 1:43 am

George писал(а):Посмотри в knowledgebase статьи о багах, которые лечатся в V10.2B параметром -reusableObjects 0.
Появление reusable objects, похоже, привело к тому, что Progress'овые сессии превратились в решето, через многочисленные дыры которого утекает память. Такие утечки рано или поздно заканчиваются ошибкой memory violation или другим летальным образом. Protrace файлы, оставленные после таких ошибок, должны указать на их источник.


Проблема в том, что protrace либо 0, либо текстовый заголовок "Progress stack trace" (точно не помню, самая первая строка не до конца). И файл держит процесс. Reusable objects появились давно же? а у меня все началось с апгрейда 10.2BSP6 -> 8 и одновременного вывода нового функционала. (больше я так делать не буду, решил downtime сэкономить). На тестовой среде всё ok, но там нагрузка меньше на порядки.
Я склоняюсь к тому, чтобы сохранять каждый protrace для PID последовательно и таким образом узнать, что он делал до того, как стал "зомби". Может там видно будет.

George писал(а):Memory mapped library?


Лучше назвать это фреймворком - я не совсем точно выразился. А библиотек 3 штуки, все memory mapped . (~400Mb) (отдельно 9.1e tty, серверная часть нашего софта и триггера)
И logreader надо переделать - там странная любовь к конкатенации строк, которые за 32K уже не работают.
/dmi

http://pro4gl.ru - 4gl блог

Старожил
Аватара пользователя
Сообщения: 2871
Зарегистрирован: Ср май 12, 2004 6:03 pm
Откуда: Питер

Re: Критические баги Progress'а

Сообщение George » Пт май 23, 2014 10:31 am

dmi писал(а):Проблема в том, что protrace либо 0, либо текстовый заголовок "Progress stack trace" (точно не помню, самая первая строка не до конца). И файл держит процесс.

"Рваные" protrace файлы создаются, насколько я могу судить, когда процесс, а то и саму базу сильно "колбасит" - процесс что-то делает как безумный и если в область этого "что-то" попадают ресурсы базы (например латчи), то и всем остальным процессам становится плохо. Поскольку вскорости процесс умирает, то из-за непродолжительности агонии (несколько секунд или десятков секунд) конечные пользователи, по-видимому, не считают нужным сообщать о таких инцидентах. О том, что базу "колбасило" в течении нескольких секунд, можно догадаться по сканам ai файлов - в частности по "временному беспорядку" транзакционных заметок, когда временные метки заметок RL_TBGN/RL_TEND не соответствуют порядку следования этих заметок в ai файле. Такие моменты можно отловить с помощью моей программы AiScanStat.p.

Reusable objects появились давно же? а у меня все началось с апгрейда 10.2BSP6 -> 8 и одновременного вывода нового функционала. (больше я так делать не буду, решил downtime сэкономить). На тестовой среде всё ok, но там нагрузка меньше на порядки.

Reusable objects появились в V10.2B. Если в течении дня практически гарантированного случается несколько ошибок, в результате которых сессии завершают свою работу аварийно, то почему бы не включить на один день параметр -reusableObjects 0? На функционал приложения это не повлияет. На производительности этот параметр тоже не должен сказаться. Если это не так, то значит приложение активно использует reusable objects и это само по себе полезное знание. Это клиентский параметр. Его можно убрать в любой момент и те сессии, которые будут запущены после этого, будут работать уже в старом режиме.

Я склоняюсь к тому, чтобы сохранять каждый protrace для PID последовательно и таким образом узнать, что он делал до того, как стал "зомби". Может там видно будет.

Если есть проблемы, то обычно за день порождается несколько новых protrace файлов. Я бы рекомендовал попробовать "плясать" не от ошибок в логе базы, а поискать protrace файлы по домашним каталогам всех пользователей и уже среди них выбрать однотипные и разбор начать с наиболее часто встречающихся стеков вызовов, которые завершались созданием protrace файла.

И logreader надо переделать - там странная любовь к конкатенации строк, которые за 32K уже не работают.

Сама идея logreader'а - грузить весь лог во временную таблицу - мне кажется неправильной. В случае удаленных подключений привязка сообщения к номеру сессии, от имени которой в лог записано это сообщение, делается ненадежным образом. Ну и отсутствие встроенных средств выделения сообщений об ошибках среди океана сообщений о нормальных событиях, делает её для меня неинтересной. С правилами, которым подчиняются сообщения в логе базы, в Progress'е, по-моему, вообще полная беда. Для разбора логов я написал свою программу - ParseDbLogs.p. Она работает раза в два медленнее чем logreader, но это плата за классификацию сообщений. Программу еще надо доводить до ума, но и в том виде, в каком она находится сейчас, меня программа сильно выручает.

Старожил
Аватара пользователя
Сообщения: 1523
Зарегистрирован: Чт сен 27, 2001 4:00 am
Откуда: Москва

Re: Критические баги Progress'а

Сообщение dmi » Пн июн 02, 2014 11:56 pm

George писал(а):"Рваные" protrace файлы создаются, насколько я могу судить, когда процесс, а то и саму базу сильно "колбасит" - процесс что-то делает как безумный и если в область этого "что-то" попадают ресурсы базы (например латчи), то и всем остальным процессам становится плохо. Поскольку вскорости процесс умирает, то из-за непродолжительности агонии (несколько секунд или десятков секунд) конечные пользователи, по-видимому, не считают нужным сообщать о таких инцидентах.


По большей части это stateless сервер приложений, а клиенты - роботы. Или долгоиграющие процессы-утилиты.

George писал(а): О том, что базу "колбасило" в течении нескольких секунд, можно догадаться по сканам ai файлов - в частности по "временному беспорядку" транзакционных заметок, когда временные метки заметок RL_TBGN/RL_TEND не соответствуют порядку следования этих заметок в ai файле. Такие моменты можно отловить с помощью моей программы AiScanStat.p.


Попробую запустить еще раз.

George писал(а):Reusable objects появились в V10.2B. Если в течении дня практически гарантированного случается несколько ошибок, в результате которых сессии завершают свою работу аварийно, то почему бы не включить на один день параметр -reusableObjects 0? На функционал приложения это не повлияет. На производительности этот параметр тоже не должен сказаться. Если это не так, то значит приложение активно использует reusable objects и это само по себе полезное знание. Это клиентский параметр. Его можно убрать в любой момент и те сессии, которые будут запущены после этого, будут работать уже в старом режиме.


Я включил дополнительное логгирование на сервере и reusable objects - подозреваю уже более сильно, что что-то не то с фреймворком по вызову веб-сервисов. Внешне ничего не поменялось, пока работаю с reusable objects.
Скоро опять пиковое время будет по выгрузкам - посмотрю, как с ними будет

George писал(а):Если есть проблемы, то обычно за день порождается несколько новых protrace файлов. Я бы рекомендовал попробовать "плясать" не от ошибок в логе базы, а поискать protrace файлы по домашним каталогам всех пользователей и уже среди них выбрать однотипные и разбор начать с наиболее часто встречающихся стеков вызовов, которые завершались созданием protrace файла.


Поскольку протрейс нулевого размера, то я хочу получать раз в минуту в "критическое время" (много долгих процессов, активная работа веб-сервисов) стрек-трейсы процессов. Вдруг увижу залип где-нибудь... А в логе "всё просто" - memory violation.
Зато теперь появилась 435-ая ошибка (она и без reusableObjects 0) была.

[14/05/30@17:34:46.871+0400] P-16121992 T-000001 1 AS -- SYSTEM ERROR: lkrels record 165746361 not locked. (435)
[14/05/30@17:34:46.871+0400] P-16121992 T-000001 1 AS -- ** ABL Debug-Alert Stack Trace **
[14/05/30@17:34:46.871+0400] P-16121992 T-000001 1 AS -- --> agreement/comissions/run-comissions-signed.p (agreement/comissions/run-comissions-signed.r) at line 17472

George писал(а):Сама идея logreader'а - грузить весь лог во временную таблицу - мне кажется неправильной. В случае удаленных подключений привязка сообщения к номеру сессии, от имени которой в лог записано это сообщение, делается ненадежным образом. Ну и отсутствие встроенных средств выделения сообщений об ошибках среди океана сообщений о нормальных событиях, делает её для меня неинтересной. С правилами, которым подчиняются сообщения в логе базы, в Progress'е, по-моему, вообще полная беда. Для разбора логов я написал свою программу - ParseDbLogs.p. Она работает раза в два медленнее чем logreader, но это плата за классификацию сообщений. Программу еще надо доводить до ума, но и в том виде, в каком она находится сейчас, меня программа сильно выручает.


Я, кстати, использовал логридер для memory leak detection на клиенте по большей части. Попробую программу для логов,спасибо.
/dmi

http://pro4gl.ru - 4gl блог

След.

Вернуться в PROGRESS - ОБЩЕЕ

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 2