Bug 10837

Бутылка swine 2.1 bugs/10837 


В 1С и конфигуратор можно заходить под любым пользователем без пароля.
В данном случае воспроизводилось под пользователем Фёдоров.

!!!!! Забыл !!!!!

Проблема воспроизводится если в настройках объединения выбрать параметры:
 
Приоритет Конфигурации - Загружаемая конфигурация 
Метод Объединения      - Замещать объекты

Всего 4 варианта - воспроизвести получилось только в 1-м

(Ответ Konstantin Artyushkin на комментарий0)
> Запустить c:/Program Files/1Cv77/BIN/1cv7l.exe
> 
> Выбрать "Информационная база #2" и запустить в режиме конфигуратора. 
> Меню -> Конфигурация -> открыть конфигурацию.
> Меню -> Конфигурация -> Объединить конфигурации - выбираю по адресу
> С:\\update\1cv7.md
> 
> Внизу появится лог процесса, ждём таких результатов:
> 
> -Режим замещения ведущих объектов
> -Загружаемая конфигурация является приоритетной
> -Замещение Объекта: "Задача"
> -Произошла ошибка в процессе объединения конфигураций

Проблема воспроизводится, но пока непонятно, что именно происходит и что
является ее источником.

(Ответ Dmitry Timoshkov на комментарий2)
> > Выбрать "Информационная база #2" и запустить в режиме конфигуратора. 
> > Меню -> Конфигурация -> открыть конфигурацию.
> > Меню -> Конфигурация -> Объединить конфигурации - выбираю по адресу
> > С:\\update\1cv7.md
> > 
> > Внизу появится лог процесса, ждём таких результатов:
> > 
> > -Режим замещения ведущих объектов
> > -Загружаемая конфигурация является приоритетной
> > -Замещение Объекта: "Задача"
> > -Произошла ошибка в процессе объединения конфигураций
> 
> Проблема воспроизводится, но пока непонятно, что именно происходит и что
> является ее источником.

После практически безрезультатных попыток понять, что именно происходит,
было решено проверить поведение объединения конфигураций под winehq.
Мгновенно выяснилось, что 1С77 под winehq больше не запускается, происходит
падение в dlls/gdi32/freetype.c при попытке получения метрик шрифта примерно
следующим кодом:
hdc = GetDC(0);
GetTextExtentPointW(hdc, L"Пуск", &size); <- crash

Причина падения в том, что шрифт, выбранный на контекст устройства по
умолчанию "System" - битмап шрифт, а код gdi32 пытается работать с ним
как со шрифтом truetype. С ходу выяснить источник регрессии не получилось,
продолжаю разбираться.

(Ответ Dmitry Timoshkov на комментарий3)
> После практически безрезультатных попыток понять, что именно происходит,
> было решено проверить поведение объединения конфигураций под winehq.
> Мгновенно выяснилось, что 1С77 под winehq больше не запускается, происходит
> падение в dlls/gdi32/freetype.c при попытке получения метрик шрифта примерно
> следующим кодом:
> hdc = GetDC(0);
> GetTextExtentPointW(hdc, L"Пуск", &size); <- crash
> 
> Причина падения в том, что шрифт, выбранный на контекст устройства по
> умолчанию "System" - битмап шрифт, а код gdi32 пытается работать с ним
> как со шрифтом truetype. С ходу выяснить источник регрессии не получилось,
> продолжаю разбираться.

Падение, описанное выше, вызывается следующим образом:
1. в первом терминале запустить 'wine winver' (локаль по-умолчанию en_US.UTF-8)
2. во втором терпинале запустить 1С с LANG=ru_RU.UTF-8 - бух - падение.
Хотя это довольно необычная ситуация, но тем не менее падать ничего не должно.
Так как причина падения понятна и тратить время на исследование этой проблемы
дальше нет смысла - откладываю исследование падения в сторону (возможно до
дождливого/морозного свободного вечера).

Что касается ошибки при объединении - здесь пока темный лес. 1С даже не
начинает какой-либо работы, а практически сразу вызывает MessageBox с
сообщением об ошибке. Было проверено несколько теорий: пока безрезультатно.
Основное подозрение на данном этапе вызывает код, работающий с MDI:
1С создает окно со стилем WS_EX_MDICHILD, но в обработчике WM_CREATE
сбрасывает этот стиль, и MDI код в wine считает, что MDI окон для работы
нет, это ведет к тому, что в ответ на сообщение WM_MDIGETACTIVE wine всегда
возвращает 0. WM_MDIGETACTIVE - это последнее, что я вижу перед созданием
окна с сообщением об ошибке. Пока это единственная теория, которую нужно
будет проверить.

(Ответ Dmitry Timoshkov на комментарий4)
> > После практически безрезультатных попыток понять, что именно происходит,
> > было решено проверить поведение объединения конфигураций под winehq.
> > Мгновенно выяснилось, что 1С77 под winehq больше не запускается, происходит
> > падение в dlls/gdi32/freetype.c при попытке получения метрик шрифта примерно
> > следующим кодом:
> > hdc = GetDC(0);
> > GetTextExtentPointW(hdc, L"Пуск", &size); <- crash
> > 
> > Причина падения в том, что шрифт, выбранный на контекст устройства по
> > умолчанию "System" - битмап шрифт, а код gdi32 пытается работать с ним
> > как со шрифтом truetype. С ходу выяснить источник регрессии не получилось,
> > продолжаю разбираться.
> 
> Падение, описанное выше, вызывается следующим образом:
> 1. в первом терминале запустить 'wine winver' (локаль по-умолчанию
> en_US.UTF-8)
> 2. во втором терпинале запустить 1С с LANG=ru_RU.UTF-8 - бух - падение.
> Хотя это довольно необычная ситуация, но тем не менее падать ничего не
> должно.
> Так как причина падения понятна и тратить время на исследование этой проблемы
> дальше нет смысла - откладываю исследование падения в сторону (возможно до
> дождливого/морозного свободного вечера).

Префикс, указанный в задаче 10868 полностью повторяет описанную выше проблему
и в этом префиксе падение при вызове GetTextExtentPointW() воспроизводится
со 100% вероятностью и не зависит от локали и запущена или нет еще какая-то
программа в этом префиксе. Поэтому пришлось исследовать проблему и искать
причины и возможное решение.

Как оказалось, падение вызвано порчей памяти, при чем порча памяти происходит
исключительно тогда, когда GetFileAttributes() возвращает ошибку для файла
шрифта, и ошибка GetFileAttributes() вызвана тем, что файл шрифта находится
вне используемого wine префикса, где-то в /usr/share/fonts и при этом диск
z:, указывающий на / (и позволяющий обращаться к файлам вне префикса через
ссылку z:->/) не существует (вернее специально удален по соображениям
безопасности). Так как конфигурация без ссылки z:->/ используется крайне
редко (а может вообще нигде не используется кроме W@E), то поэтому данная
проблема не была обнаружена до сих пор.

Патч, исправляющий порчу памяти, отправлен в wine-patches.

(Ответ Dmitry Timoshkov на комментарий5)
> Префикс, указанный в задаче 10868 полностью повторяет описанную выше проблему
> и в этом префиксе падение при вызове GetTextExtentPointW() воспроизводится
> со 100% вероятностью и не зависит от локали и запущена или нет еще какая-то
> программа в этом префиксе. Поэтому пришлось исследовать проблему и искать
> причины и возможное решение.
> 
> Как оказалось, падение вызвано порчей памяти, при чем порча памяти происходит
> исключительно тогда, когда GetFileAttributes() возвращает ошибку для файла
> шрифта, и ошибка GetFileAttributes() вызвана тем, что файл шрифта находится
> вне используемого wine префикса, где-то в /usr/share/fonts и при этом диск
> z:, указывающий на / (и позволяющий обращаться к файлам вне префикса через
> ссылку z:->/) не существует (вернее специально удален по соображениям
> безопасности). Так как конфигурация без ссылки z:->/ используется крайне
> редко (а может вообще нигде не используется кроме W@E), то поэтому данная
> проблема не была обнаружена до сих пор.
> 
> Патч, исправляющий порчу памяти, отправлен в wine-patches.

Патч принят.

(Ответ Dmitry Timoshkov на комментарий4)
> Что касается ошибки при объединении - здесь пока темный лес. 1С даже не
> начинает какой-либо работы, а практически сразу вызывает MessageBox с
> сообщением об ошибке. Было проверено несколько теорий: пока безрезультатно.
> Основное подозрение на данном этапе вызывает код, работающий с MDI:
> 1С создает окно со стилем WS_EX_MDICHILD, но в обработчике WM_CREATE
> сбрасывает этот стиль, и MDI код в wine считает, что MDI окон для работы
> нет, это ведет к тому, что в ответ на сообщение WM_MDIGETACTIVE wine всегда
> возвращает 0. WM_MDIGETACTIVE - это последнее, что я вижу перед созданием
> окна с сообщением об ошибке. Пока это единственная теория, которую нужно
> будет проверить.

Добавил пачку тестов для WM_MDIGETACTIVE, и новые тесты показывают несколько
неожиданное поведение под wine - они терпят неудачу в самых различных местах.
Отправил патчи с тестами в wine-patches и начал разбираться с причинами
неудач в тестах.

(Ответ Dmitry Timoshkov на комментарий7)
> > Что касается ошибки при объединении - здесь пока темный лес. 1С даже не
> > начинает какой-либо работы, а практически сразу вызывает MessageBox с
> > сообщением об ошибке. Было проверено несколько теорий: пока безрезультатно.
> > Основное подозрение на данном этапе вызывает код, работающий с MDI:
> > 1С создает окно со стилем WS_EX_MDICHILD, но в обработчике WM_CREATE
> > сбрасывает этот стиль, и MDI код в wine считает, что MDI окон для работы
> > нет, это ведет к тому, что в ответ на сообщение WM_MDIGETACTIVE wine всегда
> > возвращает 0. WM_MDIGETACTIVE - это последнее, что я вижу перед созданием
> > окна с сообщением об ошибке. Пока это единственная теория, которую нужно
> > будет проверить.
> 
> Добавил пачку тестов для WM_MDIGETACTIVE, и новые тесты показывают несколько
> неожиданное поведение под wine - они терпят неудачу в самых различных местах.
> Отправил патчи с тестами в wine-patches и начал разбираться с причинами
> неудач в тестах.

Патчи с тестами приняты. Добавил несколько тестов, повторяющих действия 1С
при создании MDI дочернего окна, так же продолжил исследование причин неудач
в тестах.

Совершенно слуйчано заметил, что данная задача блокирует задачу 8430. Чтение
комментариев к задаче 8430 показало, что эта задача 10837 фактически является
повтором задачи 8430, и Сергей Гуральник в рамках исследования задачи 8430
уже выяснил, что использование ole32.dll из Windows XP позволяет выполнить
объединение конфигураций в 1С без ошибок.

Как только мне стало известно о том, что проблема скорее всего находится
в ole32, то было уже естественно проверить и подтвердить, что использование
ole32=n действительно решает проблему объединения конфигураций. Имея эту
информацию изначально, можно было бы избежать потери времени на новое
исследование проблемы.

Далее использование правильных каналов отладочных сообщений и добавление
множества новых позволило выяснить точное место возникновения проблемы:
почти сразу за вызовом IEnumSTATSTG::Next() 1С вызывает IStorage::Revert()
и выводит сообщение об ошибке. Кстати, это объясняет, почему +relay log
не позволяет видеть практически вообще никакой активности: работа с IStorage
происходит с использованием таблицы виртуальных методов, которые не видны
при отладке с помощью +relay.

Дальнейшее исследование свелось к экспериментам и написанию нового теста
для IEnumSTATSTG::Next(). В процессе исследованиея одно из предположений
подтвердилось: IEnumSTATSTG::Next() в случае завершения перечесления всех
элементов должен не просто вернуть S_FALSE, но и полностью обнулить структуру
данных, переданную приложением. Как только было добавлено обнуление структуры
при возврате S_FALSE, 1С сразу же смогла полностью выполнить и завершить
объединение конфигураций. Но, по завершении объединения 1С начала сообщать
об ошибке открытия документа. Дальнейшее исследование показало, что это
та же самая проблема, что и в задаче 10868, и приложение патчей, решающих
проблему в той задаче, позволяют избежать сообщений об ошибке и по окончании
объединения конфигураций.

Патчи с тестами и исправлением для IEnumSTATSTG::Next() отправлены в
wine-patches.

(Ответ Dmitry Timoshkov на комментарий9)
> Совершенно слуйчано заметил, что данная задача блокирует задачу 8430. Чтение
> комментариев к задаче 8430 показало, что эта задача 10837 фактически является
> повтором задачи 8430, и Сергей Гуральник в рамках исследования задачи 8430
> уже выяснил, что использование ole32.dll из Windows XP позволяет выполнить
> объединение конфигураций в 1С без ошибок.

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

(Ответ Dmitry Timoshkov на комментарий10)
 объединение конфигураций в 1С без ошибок.
> 
> Константин, в чем причина создания повтров для уже существующих задач к тому
> же без явного указания, что это фактический повтор? Такая практика распыляет
> информацию по разным задачам и ведет к потере уже известных результатов
> исследований, и как результат ведет к повторному исследованию возможно уже
> исследованных проблем.

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

Согласен что нужно было явно указать 8430 в первом сообщении из-за проведённой там работы.

Постараюсь ответственней подходить к таким моментам

(Ответ Dmitry Timoshkov на комментарий9)
> Дальнейшее исследование свелось к экспериментам и написанию нового теста
> для IEnumSTATSTG::Next(). В процессе исследованиея одно из предположений
> подтвердилось: IEnumSTATSTG::Next() в случае завершения перечесления всех
> элементов должен не просто вернуть S_FALSE, но и полностью обнулить структуру
> данных, переданную приложением. Как только было добавлено обнуление структуры
> при возврате S_FALSE, 1С сразу же смогла полностью выполнить и завершить
> объединение конфигураций. Но, по завершении объединения 1С начала сообщать
> об ошибке открытия документа. Дальнейшее исследование показало, что это
> та же самая проблема, что и в задаче 10868, и приложение патчей, решающих
> проблему в той задаче, позволяют избежать сообщений об ошибке и по окончании
> объединения конфигураций.
> 
> Патчи с тестами и исправлением для IEnumSTATSTG::Next() отправлены в
> wine-patches.

Винсент попросил немного переделать патчи. Новая версия патчей отправлена
в wine-patches.

(Ответ Dmitry Timoshkov на комментарий12)
> > Дальнейшее исследование свелось к экспериментам и написанию нового теста
> > для IEnumSTATSTG::Next(). В процессе исследованиея одно из предположений
> > подтвердилось: IEnumSTATSTG::Next() в случае завершения перечесления всех
> > элементов должен не просто вернуть S_FALSE, но и полностью обнулить структуру
> > данных, переданную приложением. Как только было добавлено обнуление структуры
> > при возврате S_FALSE, 1С сразу же смогла полностью выполнить и завершить
> > объединение конфигураций. Но, по завершении объединения 1С начала сообщать
> > об ошибке открытия документа. Дальнейшее исследование показало, что это
> > та же самая проблема, что и в задаче 10868, и приложение патчей, решающих
> > проблему в той задаче, позволяют избежать сообщений об ошибке и по окончании
> > объединения конфигураций.
> > 
> > Патчи с тестами и исправлением для IEnumSTATSTG::Next() отправлены в
> > wine-patches.
> 
> Винсент попросил немного переделать патчи. Новая версия патчей отправлена
> в wine-patches.

3 из 4 патчей приняты, к последнему патчу у Винсента снова появилсь замечания.
После небольших изменений последний патч отправлен в wine-patches.

(Ответ Dmitry Timoshkov на комментарий13)
> > > Дальнейшее исследование свелось к экспериментам и написанию нового теста
> > > для IEnumSTATSTG::Next(). В процессе исследованиея одно из предположений
> > > подтвердилось: IEnumSTATSTG::Next() в случае завершения перечесления всех
> > > элементов должен не просто вернуть S_FALSE, но и полностью обнулить структуру
> > > данных, переданную приложением. Как только было добавлено обнуление структуры
> > > при возврате S_FALSE, 1С сразу же смогла полностью выполнить и завершить
> > > объединение конфигураций. Но, по завершении объединения 1С начала сообщать
> > > об ошибке открытия документа. Дальнейшее исследование показало, что это
> > > та же самая проблема, что и в задаче 10868, и приложение патчей, решающих
> > > проблему в той задаче, позволяют избежать сообщений об ошибке и по окончании
> > > объединения конфигураций.
> > > 
> > > Патчи с тестами и исправлением для IEnumSTATSTG::Next() отправлены в
> > > wine-patches.
> > 
> > Винсент попросил немного переделать патчи. Новая версия патчей отправлена
> > в wine-patches.
> 
> 3 из 4 патчей приняты, к последнему патчу у Винсента снова появилсь
> замечания.
> После небольших изменений последний патч отправлен в wine-patches.

Все патчи приняты, портированы и отправлены для принятия в ветку eter-2.1.
Константин, пожалуйста протестируйте исправление.

Отмечаю как решенную. Константин, закройте задачу как подтвердите исправление.

Проверил:

  wine-etersoft-2.1.3-alt31

Проблема больше не воспроизводиться.

Закрываю.