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 Права на директории выставлены уже и 2777.
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); Конечно же, простое отламывание этого эксепшна ни к чему хорошему не приводит :) Генерируется из другого места.
Пакет с 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. Эту багу не переоткрывайте, если что, создавайте новую с чётким описанием проблемы.
