Bug 2517

Вываливается в дамп также при попытке использования стандартных драйверов 1с для сканера.

Проверил. Всё работает

Бага просто не воспроизвелась. Даже проброс работает.

Ошибка снова вернулась, возможно она как то связана с 2820.
Воспоизводится и без подключенного торгового оборудования.
После установки IE ошибка исчезает.

Посмотреть можно в бутылке 1c81/1c8.1.11.67, база Управление торговлей.
Сервис - Торговое оборудование - Подключение и настр - Сканер штрих кодов. Выбрать модель и нажать Параметры.

Эта бага никак не может быть связана с 2820.
2820 - для установленного IE, тут ошибка при работе gecko.

Мои изыскания по баге #2105 как минимум меняют ход выполнения.
Через wwxp (с попыткой добавить IMarkupServices) падает при создании именно этого интерфейса.
Нужно проверить после нормальной реализации (хотя бы на уровне заглушек).

Created attachment 969 [details]
лог

>лог
http://rt.etersoft.ru/Ticket/Display.html?id=9232
Та же ошибка.

У меня такая ошибка не возникает:
msimtf:CActiveIMM_Create

Класс встречается только в материалах, связанных с wine, название класса и интерфейса пока не могу установить. Ну да вряд ли дело в них.

IMarkupServices не влияет.
В 1.0.10 стало падать независимо от наличия моего патча.

Падение классическое - чтение 1ской памяти после возвращение откуда-то из заглушки нулевого указателя.

1C как всегда не проверяет возвращаемое HRESULT значение. На этот раз - в функции HTMLElementCollection_item, откуда возвращается pDisp==NULL и E_INVALIDARG. Тем не менее, программа смело обращается к этому нулевому указателю, из-за чего и падает.

Проверка: вернул вместо NULL 0x3 -> падение стало таким
wine: Unhandled page fault on read access to 0x00000003...

Про 0x3 - это не совсем к этой баге, можно не принимать во внимание...

1С оперирует типом VT_INT вместо задокументированного в MSDN VT_I4. Конечно, для 32битной машины эти типы не отличаются, но всё же в вайне не реализована работа с VT_INT. Работает ли такое в Windows - нам ещё предстоит узнать.

Добавление куска кода, реализующего (в обход всех норм MSDN) работу метода с типом VT_INT, не помогает. Корректно возращается указатель на (видимо) IDispatchEx, но 1С всё равно падает, правда уже немножко по-другому.
Backtrace:
=>0 0x42af4148 in frntend (+0x214148) (0x7e8e758a)
  1 0x20ec8353 in xml2 (+0x358353) (0x56e58955)
  2 0x00000000 (0x00000000)

Нужно понять, корректно ли - возвращать IDispatch, если методу item передаётся аргумент VT_INT. Нужен тест для винды.

Добавил в вайновский тест проверку на правильность обработки методом типа VT_INT. В винде поддерживается.
Тест и патч выслал в winehq, ждём, что скажут.

Не ждём winehq, идём дальше :)

Самая подозрительная строчка в следующем вылете:
warn:mshtml:HTMLDOMNode_QI (0x2ecb380)->({3050f204-98b5-11cf-bb82-00aa00bdce0b} 0x32d464)
К тому же она последняя перед множеством релизов перед падением и единственная, возвращающая NULL.
Почему там warn, а не fixme - можно только догадываться, но подозреваю, что на этот раз падение происходит именно в этом NULL'е.

Стоило вернуть левый указатель в этой функции - 1С прошла дальше и упала на вызове метода из этого левого интерфейса. Что доказывает, что она обращается по этому указателю. 

Вывод: В HTMLDOMNode_QI нужно обрабатывать приведённый UID. Кстати, это IHTMLBaseElement

Конечно же, такой интерфейс не объявлен в вайновском mshtml.idl.
Исследования виндового *.tlb дают следующее:

[
    uuid(3050F204-98B5-11CF-BB82-00AA00BDCE0B),
    dual
]
dispinterface IHTMLBaseElement {
    properties:
    methods:
        [id(0x000003eb), propput]
        void href([in] BSTR href);
        [id(0x000003eb), propget]
        BSTR href();
        [id(0x000003ec), propput]
        void target([in] BSTR target);
        [id(0x000003ec), propget]
        BSTR target();
};

[
    odl,
    uuid(3050F204-98B5-11CF-BB82-00AA00BDCE0B),
    dual,
    oleautomation
]
interface IHTMLBaseElement : IDispatch {
    [id(0x000003eb), propput]
    HRESULT href([in] BSTR href);
    [id(0x000003eb), propget]
    HRESULT href([out, retval] BSTR* href);
    [id(0x000003ec), propput]
    HRESULT target([in] BSTR target);
    [id(0x000003ec), propget]
    HRESULT target([out, retval] BSTR* target);
};

Если я правильно понимаю, в idl это будет просто записью о dual-интерфейсе, наследуемом от IDispatch (т.е. часть про dispinterface не будет играть большую роль?) Плюс нужно будет внести константы в mshtmdid.h

Есть ещё coclass, содержащий IHTMLBaseElement:

[
    uuid(3050F276-98B5-11CF-BB82-00AA00BDCE0B)
]
coclass HTMLBaseElement {
    [default] dispinterface  DispHTMLBaseElement;
    [default, source] dispinterface  HTMLElementEvents;
    [source] dispinterface  HTMLElementEvents2;
    interface  IHTMLElement;
    interface  IHTMLElement2;
    interface  IHTMLElement3;
    interface  IHTMLElement4;
    interface  IHTMLUniqueName;
    interface  IHTMLDOMNode;
    interface  IHTMLDOMNode2;
    interface  IHTMLBaseElement;
};

Решение в сборке eter41

eter41\eter17
Принято

Исправил IHTMLBaseElement
Проверил после внесения изменений - падений не наблюдается.

при входе в базу 1с v8.1 падает. см. 7106

Не воспроизвелось, все настройки сканера доступны.
бутылка <wine@cellar bottle bugs/2517

WINE@Etersoft version 1.3.13-eter1.4

в ine@eterschool bottle bugs/2517
WINE@Etersoft 1.0 School 1.7.1-eter1.4/1  - не запускается 1сv8.1