swine 2.1 garant/780-cs WINE@Etersoft SQL 2.1.3/2.1.0-eter4/3 Версия 7.08.0.163 cs Установка на этапе "проверяется доступность сервера консультаций" завершается падением.
(В ответ на comment #0) > swine 2.1 garant/780-cs > WINE@Etersoft SQL 2.1.3/2.1.0-eter4/3 > > Версия 7.08.0.163 cs > Установка на этапе "проверяется доступность сервера консультаций" завершается > падением. Установка действительно может визуально нормально продолжаться, т.к. падает дочерний процесс. wine: Unhandled page fault on read access to 0x00000050 at address 0x4ffae8 (thread 0083), starting debugger...
(В ответ на comment #2) > wine: Unhandled page fault on read access to 0x00000050 at address 0x4ffae8 > (thread 0083), starting debugger... В надежде узнать откуда берется это исключение сделал +all лог, который может помочь в этом деле. Положение затрудняет то, что перед сообщением об исключении отсутствуют какие-бы то ни было сообщения об ошибках или предупреждения, Пока ничего особо ценного извлечь не удалось.
Продолжаю возиться с логом. Пока наибольшие подозрения вызывает эта последовательность: 007f: destroy_window( handle=000100d8 ) x80044 -> 3 ... 007f: destroy_window() = 0 ... 0080: set_class_info( window=000100d8, flags=00000000, atom=000011212.645:0013:trace:xrender:LookupEntry 3 ... 0080: get_window_text( handle=000100d8 ) 0080: get_window_text() = ERROR_INVALID_WINDOW_HANDLE { text=L"" } ... 11212.646:0080:trace:msg:PostMessageW hwnd 0x100d8 msg 0 (WM_NULL) wp 0 lp 0 ... 0080: get_window_info( handle=000100d8 ) 0080: get_window_info() = ERROR_INVALID_WINDOW_HANDLE { full_handle=00000000, last_active=00000000, pid=0000, tid=0000, atom=0000, is_unicode=0 } ... 11212.646:0080:trace:seh:raise_exception code=c0000005 flags=0 addr=0x4ffae8 ip=004ffae8 tid=0080 Возможно факт уничтожения окна некорректно обрабатывается чем-то из этой цепочки.
Более пристальный анализ хода установки показал что падение происходит в процессе F1ConsultChecker.run. > wine: Unhandled page fault on read access to 0x00000050 at address 0x4ffae8 > (thread 0083), starting debugger... На этом месте при запуске программы находятся нули, т.е код в этом месте генерируется в рантайме. Ничего особенного в нем нет. Вот кусок командной строки используемой при запуске чекера: trace:process:create_process_impl app (null) cmdline L"\"C:\\Program Files\\Garant-Server\\apps\\winNT\\F1ConsultingChecker.run\" -ConsultingTransportConfig \"C:\\Program Files\\Garant-Server\\settings\\garant.ini\" -GCMConfigFile \"C:\\Program Files\\Garant-Server\\garant.ini\" -GPMAdapterConfigSection \"F1Server Params\" -ORBLogFile \".\\..\\..\\logs\\"... Как мне кажется многоточие указывает на то что в лог попала не вся строка (вероятно из-за ограничения какого-нибудь внутреннего буфера отладочной печати). Попытки получить полную командную строку пока безуспешны. Как только я добавляю вывод командной строки через printf или сбрасывая на диск падения тотчас же прекращаются. Похоже на обращение по невалидному адресу/выход за границу буфера. После извлечения целой командной строки можно попытаться запустить чекер автономно, возможно это позволит увидеть проблему в более удобном для исследования виде.
Извлечь командную строку удалось: "C:\Program Files\Garant-Server\apps\winNT\F1ConsultingChecker.run" -ConsultingTransportConfig "C:\Program Files\Garant-Server\settings\garant.ini" -GCMConfigFile "C:\Program Files\Garant-Server\garant.ini" -GPMAdapterConfigSection "F1Server Params" -ORBLogFile ".\..\..\logs\checker.log" -AutoTest Если отдать ее на исполнение то возникает то же самое исключение что описывалось ранее, причем так же нестабильно. Из за этого пока не удается получить backtrace процесса в момент обработки исключения.
(В ответ на comment #7) > (В ответ на comment #6) > > Извлечь командную строку удалось: > Как? Вызвав GetCommandLineA() во время обработки исключения в kernel32/except.c и затем сбросив буфер в дисковый файл. Скажу сразу - это сработало далеко не с первого раза, т.к. падения получаются нестабильно, кроме того любые изменения кода вайна влияют на содержимое стека в момент падения из за чего падения происходят еще реже. P.S. Получение командной строки во время обработки исключения позволяет стопроцентно узнать в каком процессе происходит сбой, не загромождая при этом результат командными строками других процессов.
Просмотрев код гаранта в месте крэша можно увидеть, что его причиной является разыменование нулевых this-указателей (иногда это не 0x0 а 0x1) или точнее попытка прочитать поле объекта используя этот указатель. Продолжаю работать с логом на предмет поиска вызовов которые потенциально могли бы портить стек.
(В ответ на comment #9) > Просмотрев код гаранта в месте крэша можно увидеть, что его причиной является > разыменование нулевых this-указателей (иногда это не 0x0 а 0x1) или точнее > попытка прочитать поле объекта используя этот указатель. Продолжаю работать с > логом на предмет поиска вызовов которые потенциально могли бы портить стек. Иногда бывает, что никто не портил, просто объект не создался или не создавался. Если указатель хранится в стеке, то я бы проверял простой вариант, поставив точку останова на функцию, где происходит падение, и посмотрев, как заполняются локальные переменные.
И все-таки бага проявляется. При установки версии 7.08.1 и 7.09.1 в wine из testing.
(В ответ на comment #16) > И все-таки бага проявляется. > При установки версии 7.08.1 и 7.09.1 в wine из testing. После killall wineserver + wineserver -k повтрная установка работет корректно.
При очередной установке появилась ошибка wine "получены неверные параметры", в консоли: fixme:storage:create_storagefile Storage share mode not implemented. fixme:browseui:ProgressDialog_StartProgressDialog Reserved parameters not null ((nil), 0x33fa44) wine: Unhandled page fault on read access to 0x00000000 at address 0x3b9e98 (thread 0079), starting debugger... после чего установка продолжилась.
Откладываем задачи, к которым не обращались более 100 дней.
