| Summary: | верси 1.0.9 при выполнениий wine --update вываливается в дебаг | ||
|---|---|---|---|
| Product: | WINE@Etersoft | Reporter: | Alexeev Alexey <alexeev> |
| Component: | Общее | Assignee: | Виталий Перов <vitperov> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P5 | CC: | kondratyuk, lav, sergling, vitperov |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Заявки RT: | Связано с: | 2894 | |
| Дата напоминания: | |||
| Bug Depends on: | |||
| Bug Blocks: | 1537, 1659, 2357, 4604 | ||
|
Description
Alexeev Alexey
2008-04-05 19:46:28 MSD
Да, подтверждаю. Это происходит при выполнении rundll32.exe setupapi.dll,InstallHinfSection DefaultInstall 128 wine.inf похожая ошибка возникала при установке indeo5 через ww. Тоже выдавала: fixme:ntdll:server_ioctl_file Unsupported ioctl 110018 (device=11 access=0 func=6 method=0) На все 100% не уверен, что там было именно device=11, func=6, но вроде как-раз такие значения там и были. Решалось это запуском программы устновки через winexp Да, но Indeo тут ни при чём. Похоже, что вылеты в дебаггер при тестировании многих программ в последнее время - следствие этой ошибки. В том числе и программ из "школьного" проекта. падает при вызове NdrGetBuffer() из svcctl_OpenSCManagerW() NdrGetBuffer() находится в rpcrt4.dll. По умолчанию она используется сторонняя. Если поставить встроенную, дебагер больше не вызывается *** Bug 1698 has been marked as a duplicate of this bug. *** а проблема в том, что комманда _Handle = MACHINE_HANDLEW_bind(MachineName); возвращает ноль Проблемы тут 2: 1)если MACHINE_HANDLEW_bind() возвращает 0, значит где-то внутри ошибка. 2)если она всё же возвращает 0, то это должно корректно обрабатываться. Нет, ошибка в другом месте.
_Handle имеет не нулевое значение, но почему-то
отладочная конструкция
FIXME("_StubMsg=%p, _StubMsg.BufferLength=%d _Handle=%d\n", _StubMsg, _StubMsg.BufferLength, _Handle);
выводит, что _Handle=0:
fixme:service:svcctl_OpenSCManagerW _StubMsg=0x32d790, _StubMsg.BufferLength=168 _Handle=0
Странно как-то
на первый взгляд, функции NdrGetBuffer() передаются вполне корректные значения По-моему ошибка не в Wine, а как-раз в Виндовой дллке: http://support.microsoft.com/kb/835575 замена rpcrt4.dll на более новую (взята с ХР), ничего не меняет. Вообще в http://support.microsoft.com/kb/835575 функция NdrGetBuffer() при вылете в дебаг вызывается из Dsproxy.dll и, если я правильно понял, то они предлагают для решения проблемы загрузить новую Dsproxy.dll. Т.е всё дело в неправильном вызове NdrGetBuffer() А вообще ошибка возникает даже в стандартных тестах для advapi32.dll ещё даже до первого теста. Cкорее всего ошибка в последних изменениях До ошибки в rpcrt4.dll вызывается WaitNamedPipeW() c параметрами name = L"\\\\\\pipe\\svcctl" nTimeOut = 0x00000000 Эта функция возвращает FALSE. После чего идёт 4 освобождения памяти, и вылет в дебаг WaitNamedPipeW() вызывает NtFsControlFile() которая возвращает код ошибки. NtFsControlFile() вызывает server_ioctl_file(), а она в свою очередь показывает ошибку: fixme:ntdll:server_ioctl_file Unsupported ioctl 110018 (device=11 access=0 func=6 method=0) в "чистом" wine (запуск через wwo) данной ошибки не возникает. Скорее всего виноват какой-то наш патч. при вызове NtFsControlFile(), в качестве параметра code передаётся FSCTL_PIPE_WAIT , которая формируется: #define FSCTL_PIPE_WAIT CTL_CODE(FILE_DEVICE_NAMED_PIPE, 6, METHOD_BUFFERED, FILE_ANY_ACCESS) причём константы: FILE_DEVICE_NAMED_PIPE = 11 METHOD_BUFFERED = 0 FILE_ANY_ACCESS = 0. Из дебага видно, что функция server_ioctl_file() распаковывает эти значения нормально, но правильными их не признаёт: fixme:ntdll:server_ioctl_file Unsupported ioctl 110018 (device=11 access=0 func=6 method=0) Если использовать встроенную rpcrt4.dll, то функция уже другая: ioctl 110008 (device=11 access=0 func=2 method=0) , что соответствует комманде FSCTL_PIPE_LISTEN Ошибка не в том, что мы вызываем непоодерживаемый ioctl, а скорее в параметрах. Если заменить функцию 8 на функцию 2 (которая точно ноддерживатеся), то опять получаем fixme:ntdll:server_ioctl_file Unsupported ioctl 110008 (device=11 access=0 func=2 method=0) Функция server_ioctl_file() обращается к wineserver status = STATUS_NOT_SUPPORTED получается следующим образом: (status = wine_server_call( req )) далее ret = wait_reply( req ); далее read_reply_data( &req->u.reply, sizeof(req->u.reply) ); эта функция успешно записывает ответ сервера в буфер: ret = read( ntdll_get_thread_data()->reply_fd, buffer, size ) и возвращается. а далее wait_reply() возвращает какое-то значение внутри полученного ответа: return req->u.reply.reply_header.error; которое и считается как ошибка возможно (но маловераятно), что ошибка в wineserver. Думаю, что в любом случае без трейса wineserver не обойтись А вообще первый признак неправильной работы появляется ещё до вызова svcctl_OpenSCManagerW(). Неправильная работа начинается с : err:service:RPC_Init RpcServerUseProtseq failed with error 1703 а функция RpcServerUseProtseqEp() как-раз находится в rpcrt4.dll Код ошибки 1703 соответствует RPC_S_PROTSEQ_NOT_SUPPORTED Возможно эту операцию не стоит выполнять заменил rpcrt.dll Сейчас в этом месте выдаёт ошибку 1766, что соответствует RPC_S_INTERNAL_ERROR, но тесты выполняются. Тестировал в ветках pure, master и eterhack - везде тесты выполняются. Вылета в дебаг нигде не происходит. При выполнении проваливаются 64 теста ( при запуске через wwo только 24). wwo использует версию wine-0.9.58 В git в ветке pure должна быть самая последняя Если у нас правильно работает git, то логично предположить, что бага где-то в патчах после версии 0.9.58 Но есть ещё одна бага: ведь при запуске через wine (WINE@Etersoft 1.0 SQL (1.0.8)) программа всё-таки вылетает в дебаг Проверил стандартные тесты для advapi32 - service. При использовании встроенной rpcrt4.dll проваливается 12 тестов. При использовании нативной - 63 теста Данная ошибка появляется только в WINE@Etersoft 1.0 SQL (1.0.8) В текущей версии (обновление через git 04.05.2008) данной ошибки нет. Кусок ошибки при установке текущей версии: fixme:ntdll:server_ioctl_file Unsupported ioctl 110018 (device=11 access=0 func=6 method=0) err:module:DelayLoadFailureHook failed to delay load rpcrt4.dll.I_RpcExceptionFilter wine: Call from 0x7ee16ea0 to unimplemented function rpcrt4.dll.I_RpcExceptionFilter, aborting wine: Unimplemented function rpcrt4.dll.I_RpcExceptionFilter called at address 0x7ee16ea0 (thread 0009), starting debugger... WineDbg starting on pid 0008 Unhandled exception: unimplemented function rpcrt4.dll.I_RpcExceptionFilter called in 32-bit code (0x7ee16f16). проблемы с rpcrt4.dll (при использовании сторонней) решаются заменой этой dll на нормальную. Нормальльную можно взять в /var/ftp/pvt/WINE tests/MS/dlls/ Перешли на использование вайновской rpcrt4.dll всегда. При установке сегодняшней сборки опять валится в дебаг, но вроде помогла правка настройки для этой dll в winecfg. Вторая попытка апдейта закончилась более успешно. |