Summary: | Не реализована часть WBEM, нужная для запуска 1С:Континент-страхование | ||
---|---|---|---|
Product: | WINE@Etersoft | Reporter: | Vitaly Lipatov <lav> |
Component: | OLE / DDE / RPC | Assignee: | BUGS@Etersoft <bugs> |
Status: | CLOSED INVALID | QA Contact: | |
Severity: | major | ||
Priority: | P4 | CC: | kondratyuk, olezha |
Version: | 1.0.10 | ||
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | All | ||
Whiteboard: | |||
Заявки RT: | Связано с: | 3723 | |
Дата напоминания: | |||
Bug Depends on: | 3761 | ||
Bug Blocks: | 468, 100, 2933, 3810 |
Description
Vitaly Lipatov
2009-03-20 15:28:34 MSK
[перенесено из #3066] Добавили в wine библиотеку wbemdisp. Пользы это никакой не принесло. В библеотеке сделаны ISWbemLocator и ISWbemServices. Ещё запрашивается IConnectionPointContainer и несколько других интерфейсов. На данный момент падает в модуле 1С после обращения к IClassFactory_QueryInterface с riid, равным NULL (!) Так не бывает, на этом идеи пока закончились... В wbemprox_IClassFactory_QueryInterface передаются riid и ppvObj, равные null. Если выделять память под ppvObj и записывать туда значение (например, какой-нибудь интерфейс), то падает при попытке обратиться к нему. Если сделать *ppvObj = NULL; то падает при чтении нулевого адреса. Скорее, проблему нужно искать в том, что при выполнении программы библиотеке вообще приходит подобная задача (тем более, с такими странными указателями). А падение дальше - лишь следствие того, что почему-то этот QueryInterface вызван в этот момент. Нужен тест, воспроизводящий проблему. В существующем тесте (в отличие от 1С) не вызывается ConnectServer и не получается интерфейс ISWbemServices. Воспроизведение - в бутылке rt/9051-2 wbemdisp является ссылкой на библиотеку в моём проекте: /srv/kondratyuk/Projects/wine/dlls/wbemdisp/wbemdisp.tlb (In reply to comment #4) > Нужен тест, воспроизводящий проблему. > В существующем тесте (в отличие от 1С) не > вызывается ConnectServer и не получается > интерфейс ISWbemServices. > Тест на vbs правельный, но для того чтобы получить services надо знать строку подключения....те самые строки с мусором что мы получали из 1С. как только выясним строку подключения, необходимо просто добавить параметры подключения со строкой вот в эту строку и должно заработать Set wbemServices = wbemlocator.ConnectServer <Сюда добавить параметры через запятую> Глупая ошибка. Унаследовали SWbemLocator от IUnknown вместо IDispatch. Поэтому функция, к которой обращается программа стала вместо GetTypeInfoCount - ConnectServer. Переделал на IDispatch, попутно дополнив интерфейс пропущенным в конце методом... QueryInterface возвращал SWbemLocator при запросе IConnectionPointContainer. Далее предполагался метод Enum..., который у нас заменялся на GetTypeInfoCount. Возвращаемая единица представлялась адресом интерфейса, после чего программа просто падала. Исключил все левые IID из SWbemLocator_QueryInterface. Падать перестало, смотрим дальше... Запрашиваются (в порядке появления в логах): 00000126-0000-0000-c000-000000000046 (IRunnableObject) e7210190-61f4-11d4-941d-008048da11f9 fd7b6cc3-dc8e-11d2-b8d0-008048da0335 b196b283-bab4-101a-b69c-00aa00341d07 (IProvideClassInfo) a6ef9860-c720-11d0-9337-00a0c90dcaa9 (IDispatchEx) Попробуем добавить IProvideClassInfo для начала. Программа пытается получить ITypeInfo через IProvideClassInfo::GetClassInfo Добавил IProvideClassInfo 1С падает при обращении по нулевому указателю после вызова IProvideClassInfo:GetClassInfo. Вроде мы не возвращаем нигде нулей... Не вижу ничего (кроме wbemprox_ISWbemLocator_QueryInterface), откуда мог бы возвращаться левый указатель... При возврате ненулевого значения в *ppvObj падает именно при переходе к этому значению-адресу, игнорируя возвращаемые E_NOINTERFACE. С нулём, похоже, то же самое. IRunnableObject добавлен В нём вызывается метод Run, имеющий только входные параметры. Что бы мы ни возвращали - программе всё равно. Падает по-прежнему... Остались только эти два (неизвестных) интерфейса: {e7210190-61f4-11d4-941d-008048da11f9} {fd7b6cc3-dc8e-11d2-b8d0-008048da0335} Падения носят случайный характер, то read, то write, то unhandled exception... Есть вариант - создать левый интерфейс с множеством методов (func1, func2, func3) и посмотреть, что же хочет программа от них. Или хотя бы - в каком интерфейсе будет падать. В виндовом WbemScripting не существует (не поддерживается через SWbemLocator): IDispatchEx IRunnableObject ISWbemServices e7210190-61f4-11d4-941d-008048da11f9 fd7b6cc3-dc8e-11d2-b8d0-008048da0335 Убрал лишнее, оставив только ISWbemLocator и IProvideClassInfo Скорее всего, проблема в IProvideClassInfo_GetClassInfo. Нынешний хак на его реализацию приводит к падениям. Нужно переделывать. Совсем без реализации - сообщение "Ошибка OLE" от 1С... С результатами теста немного поторопился, IDispatchEx существует, нужно сделать и посмотреть, что к чему... IDispatchEx запрашивается, но никак не используется. Так что его делать рано. Появилась заглушка для IDispatchEx. Только вот 1ска её всё-таки игнорирует - запрашивает, получает, а потом не использует. Возможно стоит задуматься о использовании midl, а не widl....поможет решить ряд проблем, таких как параметр lcid и раннее и позднее связывание меньшими затратами. А если еще ее написать на плюсах, то будет быстрее ( в смысле времени на разработку ). Откладываем, bugs@ в ближайшее время делать ничего не будет. Задача относится к релизу 2.1. , который больше не поддерживается. Аннулирую. |