При попытке настройки сканера в 1с8.1 происходит выпадание в дамп. При помощи патча A.Rudneva получили вот такой бэктрейс Backtrace: =>1 0x7bc3cd1b __regs_RtlRaiseException+0x55(rec=0x33d354, context=0x33d088) [/srv/shan/Projects/wine/dlls/ntdll/exception.c:868] in ntdll (0x0033d058) 2 0x7bc6d620 raise_segv_exception+0xb1(rec=0x33d354, context=0x33d088) [/srv/shan/Projects/wine/dlls/ntdll/signal_i386.c:1225] in ntdll (0x0033d078) 3 0xdeadbabe (0x03562408) 4 0x7d8d5000 HTMLDOMNode2Vtbl() in mshtml (0x7d8d4f80) 5 0x7d872852 HTMLDOMNode_AddRef(iface=0x7d872982) [/srv/shan/Projects/wine/dlls/mshtml/htmlnode.c:291] in mshtml (0x7d872826) 6 0x458b18ec (0x83e58955) 7 0x00000000 (0x00000000) Handled exception code=c0000005, flags=0, addr=0x42af3ff9, parameters[2]={0, 0} Выпадание в дамп происходит в момент попытке настройки параметров, после предварительных настроек и подключения стандартных библиотек, либо при попытке подключения альтернативной библиотеки (про нее описано ниже) (она немного отличается от той, что в стандартной поставке, но это не существенно) По идеи при настройке сканер настраивать в меня Обработка обслуживания торгового обородувание. Здесь настраиваться связь с файлом ATOBarcodeScan_v2.epf . Мне кажется проблема в нем. Также в описании сказано, что этот файл надо положить в каталог, а каталога не существует. По настройке читать тут http://www.atol.ru/support/encyclopedy/1c/1s81-all/1c81-vvod/
Вываливается в дамп также при попытке использования стандартных драйверов 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
