Bug 2357

Created attachment 694 [details]
Вывод wine --attach

У нас ошибка воспроизвелась немного по-другому - запускаем wine --attach (вывод в логе) далее все повисает.

Отмечаю полное повторение баги - http://rt.etersoft.ru/Ticket/Display.html?id=7697
Таже система, тот же wine.

(In reply to comment #0)
> ubuntu 8.04 + Wine@Etersoft Network 1.0.9.
> 
> При wine --attach выдает следующее:
> 
> alex@ServU:~$ wine --attach
> First running... Using WINEPREFIX=/home/alex/.wine
> Dir /var/lib/wine/default is not prepared dir
Ну так а wine --admin делался до этого?
Тогда нужно показать содержимое /var/lib/wine/default

(In reply to comment #2)
> Отмечаю полное повторение баги -
> http://rt.etersoft.ru/Ticket/Display.html?id=7697
> Таже система, тот же wine.
Не очень понятно из заявки в чём проблема.
У нас воспроизводится?
Клиента попросить запустить
$ sh -x /usr/bin/wine --attach
и прислать нам вывод.

wine --admin делался.

Проблема клиента явно в том, что не делалось wine --admin. 
У нас проблема, действительно, в другом. У меня примерно такой же лог как у Лёни.

(In reply to comment #6)
> Проблема клиента явно в том, что не
> делалось wine --admin. 

Не обязательно. В одной из версий была бага, когда проверялось наличие reg-файла ДО его копирование в $SYSDIR, я исправлял.
Кажется, ещё возможнен такой случай, когда на $SYSDIR не хватает прав, и при выполнении --admin реестр не копируется.

$ sh -x /usr/wine --attach обязательно
А ещё лучше, если будет возможность посмотреть и --admin, и --attach.

не понял особо о чем речь тут, но смысл проблемы с которой сталкивался я в том, что не работает wine --{admin,attach} с указанием директории
без указания директории все работало.

Пока локальный клбч HASP у нас не поддерживается. По этому ждем решения 1879

(In reply to comment #9)
> Пока локальный клбч HASP у нас не
> поддерживается. По этому ждем решения 1879
> 

Не туда написал!!!

Created attachment 708 [details]
вывод рабочего $sh -x wine --attach

Проблема решилась: как и описано в заявке, в группе wineadmin состояли оба пользователя, поэтому второй юзер не мог сделать wine --attach.
После его удаления из группы все встало на свои места, багу закрываем.

Created attachment 709 [details]
вывод attach с указанием дирректории

а вот с указанием директории, как и указал Борис, не работает

При указании директории проблема воспроизводится точь-в-точь как у клиента, (вообще странно, как у него wine игнорит двух юзеров в группе wineadmin)

Так, я исправлял уже эту багу с двумя админами!
Сейчас найду и прицеплю в связанные...

http://bugs.etersoft.ru/show_bug.cgi?id=1115
Не совсем то, но можно видеть, что совсем недавно --attach у второго админа работал.

Вспроизведение баги:

$ WINEDEBUG=+wineboot /usr/bin/wine-glibc wineboot.exe --update
Warning: could not find DOS drive for current working directory '/home/guest2', starting in the Windows directory.
trace:wineboot:pendingRename Entered
trace:wineboot:pendingRename Value not present - nothing to rename
trace:wineboot:ProcessRunKeys processing L"RunServicesOnce" entries under HKLM
trace:wineboot:ProcessRunKeys processing L"RunServices" entries under HKLM
err:wineusb:ServiceMain bad hardware ID
err:wineusb:ServiceMain bad hardware ID
trace:wineboot:ProcessRunKeys processing L"RunOnce" entries under HKLM
trace:wineboot:ProcessRunKeys No commands to execute.
trace:wineboot:ProcessRunKeys done
trace:wineboot:main Operation done
trace:wineboot:pendingRename Entered
trace:wineboot:pendingRename Value not present - nothing to rename
trace:wineboot:ProcessRunKeys processing L"RunServicesOnce" entries under HKLM
err:rpc:I_RpcReceive we got fault packet with status 0x3e6
Failed to create MSI service

*** Bug 2264 has been marked as a duplicate of this bug. ***

*** Bug 2225 has been marked as a duplicate of this bug. ***

Статус 0x306, он же 998 для RPC, означает ERROR_NOACCESS.

Исключение возникает в функции NdrSendReceive, куда возвращается статус NOACCESS.

  status = I_RpcSendReceive(stubmsg->RpcMsg);
  if (status != RPC_S_OK)
    RpcRaiseException(status);

Конечно же, простое отламывание этого эксепшна ни к чему хорошему не приводит :)
Генерируется из другого места.

Исключение возникает в функции NdrSendReceive, куда возвращается статус NOACCESS.

  status = I_RpcSendReceive(stubmsg->RpcMsg);
  if (status != RPC_S_OK)
    RpcRaiseException(status);

Конечно же, простое отламывание этого эксепшна ни к чему хорошему не приводит :)
Генерируется из другого места.

Пакет с ptype == PKT_FAULT приходит из функции rpcrt4_conn_read

static inline int rpcrt4_conn_read(RpcConnection *Connection,
                     void *buffer, unsigned int len)
{
  return Connection->ops->read(Connection, buffer, len);
}

WINEDEBUG=+all даёт такой кусок в ходе выполнения RPCRT4_receive_fragment (до того момента, как вернётся пакет PKT_FAULT)

0009:trace:rpc:RPCRT4_receive_fragment (0x14e3070, 0x33a5e8, 0x33a574)
0009:Call KERNEL32.ReadFile(00000070,0033a508,00000010,0033a4bc,00000000) ret=7ebb32d4
0009:trace:file:ReadFile 0x70 0x33a508 16 0x33a4bc (nil)
0009:trace:ntdll:NtReadFile (0x70,(nil),(nil),(nil),0x33a3c8,0x33a508,0x00000010,(nil),(nil)),partial stub!
0009:trace:ntdll:NtReadFile = SUCCESS (16)
0009:Ret  KERNEL32.ReadFile() retval=00000001 ret=7ebb32d4

Я так понимаю, что чтение выполняется успешно. Значит проблема в содержании ответа. Либо там мусор, либо отправитель (сервер) неверно отвечает.

Ошибка связана с некорректной работой службы mountmgr.sys
После исключения её из сборки (alt20) выполнение --update проходит корректно.

В alt20 воспроизводится на некоторых машинах. Например, на pav

В eter21 добавлен патч, убирающий генерацию исключения, приводящего к блокировкам.

Работает wineboot --update, запущенный отдельно.
При выполнении этой же команды в ходе обновления (wine --update) блок возникает где-то в другом месте.

Пока не получается воспроизвести проблему, используя ww (а значит, добавлять нужные трейсы).
$ ww wineboot --update с любой комбинацией переменных окружения работает успешно.

Обходной вариант, убирающий блокировку.

В .update-timestamp указываем disable.
Не понял пока, что произойдёт с командой wineboot --update, но выполняться она будет в весьма урезанном варианте.
wine --update начинает работать без проблем.

(In reply to comment #30)
> Обходной вариант, убирающий блокировку.
> 
> В .update-timestamp указываем disable.
> Не понял пока, что произойдёт с командой
> wineboot --update, но выполняться она будет в
> весьма урезанном варианте.
Судя по коду wineboot
            if (!strncmp( buffer, "disable", sizeof("disable")-1 )) goto done;
            if (!force && timestamp == strtoul( buffer, NULL, 10 )) goto done; 
при указанном disable вообще не будет выполняться обновление никогда

После исправления 2457 всё должно быть хорошо.

Debian, последняя сборка. Актуально.

Денис, воспроизведи, пожалуйста, на последних сборках. На любой системе, на какой сможешь.

Ubuntu 8.04 сборка wine и libwine от 20 сентября. Ошибка воспроизвелась.

Ошибка - stack overflaw (из баги #2399)

Последний коммит из доступных в опубликованном репозитории:

commit be2b81806f46aaed0c241d312d0466b28d430cb9
Author: Vitaly Lipatov <lav@etersoft.ru>
Date:   Thu Sep 18 12:53:53 2008 +0400

    enable mountmgr again

Есть ли правки позднее? Если есть, то нужна сборка current под все системы (в первую очередь - для Ubuntu 8.04)

Проблему считаем исправленной в 1.0.9-eter24.
Эту багу не переоткрывайте, если что, создавайте новую с чётким описанием проблемы.