1С 8.0 бухгалтерия базовая Воспроизведено в бутылке 1c80base на euclid'е fixme:mshtml:HTMLDocument_QueryInterface (0x6c59178)->({00000003-0000-0000-c000-000000000046} 0x32d398) interface not supported fixme:shdocvw:WebBrowser_QueryInterface (0x68ee660)->({00000003-0000-0000-c000-000000000046} 0x32d3b8) interface not supported fixme:mshtml:HlinkTarget_SetBrowseContext (0x6c59178)->((nil)) wine: Unhandled page fault on read access to 0x00000000 at address 0x1cc09e56 (thread 0028), starting debugger... ... =>1 0x1cc09e56 in html (+0x49e56) (0x0032e3b4) 2 0x7d9410c0 set_parsecomplete+0x28f(doc=0x6c68dc8) [/srv/kondratyuk/Projects/wine/dlls/mshtml/task.c:295] in mshtml (0x0032e414) 3 0x7d9413f9 process_task+0x54(task=0x6c941a0) [/srv/kondratyuk/Projects/wine/dlls/mshtml/task.c:356] in mshtml (0x0032e454) 4 0x7d941777 hidden_proc+0x43(hwnd=0x30066, msg=32776, wParam=0, lParam=0) [/srv/kondratyuk/Projects/wine/dlls/mshtml/task.c:431] in mshtml (0x0032e4a4) 5 0x7e9b9daa WINPROC_wrapper+0x1a() in user32 (0x0032e4d4)
Падение при исполнении этой функции: void call_property_onchanged(ConnectionPoint *This, DISPID dispid) { DWORD i; for(i=0; i<This->sinks_size; i++) { if(This->sinks[i].propnotif) { FIXME("%p %d\n", This->sinks[i].propnotif, dispid); IPropertyNotifySink_OnChanged(This->sinks[i].propnotif, dispid); } } } Вызов IPropertyNotifySink_OnChanged приводит к падению.
При простом отключении выполнения проблемной строки - грузится и отображается нормально. Но как только становится активным окном - сразу же сваливается. =>1 0x1cc0e382 in html (+0x4e382) (0x0032e914) 2 0x11ea2937 in bsl (+0x32937) (0x0032e9d0) 3 0x11ea2cba in bsl (+0x32cba) (0x0032ea64) Непосредственно перед падением - множество неудачных попыток получить IMarshal. С патчем на заглушки к IMarshal всё ещё хуже - либо неправильный патч, либо ведёт в более проблемную зону...
Есть подозрение, что на этот раз падает после этого QI: warn:mshtml:HTMLDOMNode_QI (0x28a4d40)->({3050f1ff-98b5-11cf-bb82-00aa00bdce0b} 0x32e218) "Неизвестный" интерфейс: IHTMLElement={3050F1FF-98B5-11CF-BB82-00AA00BDCE0B}
Нет, к этому QI обращается не всегда. А вот падает - всегда. Из чего можно слелать вывод, что причина кроется в другом.
Created attachment 1055 [details] лог по html
Последний лог может не иметь отношение к проблеме. Это использование нового gecko наверняка дало такое падения. С этой проблемой стоит разбираться отдельно.
Очень похоже, что падение происходит опять где-то тут: fixme:mshtml:HTMLElement_get_outerHTML (0x2c67588)->(0x32dcb8) Такое уже было в баге #1902 и для 1.0.9 вылечилось простой инициализацией возвращаемой строки. Фикс есть в 1.0.10, но тем не менее падает. Наверное, стоит отключить эту правку и посмотреть на поведение 1С
Нет, как минимум, 1cfile не падает с правкой, но падает без неё. Значит, она работает и на новых исходниках. Но вот то, что обычного пробела не хватает - это очень может быть...
Падение происходит в клиентской части, после вызова IPropertyNotifySink_OnChanged с dispid==DISPID_READYSTATE Сам вызов происходит из вайновской функции call_property_onchanged()
Для проверки отключил уведоления о READYSTATE Падает теперь дальше. warn:mshtml:HTMLDOMNode_QI (0x2ae3ea8)->({3050f1ff-98b5-11cf-bb82-00aa00bdce0b} 0x32d6a0) Это получение IHTMLElement, падение после неудачного вызова этой функции - уже привычное дело.
Да, попытки копать в сторону QI дают результат. Единственная проблема - корректно через HTMLDOMNode получить объект IHTMLElement. Вопрос, актуальный для всех встречаемых в QI ...Element-объектов (см. багу #3484)
Сейчас проблема воспроизводится на новой сборке 1.0.10 alt10/alt6 с новым Gecko
(In reply to comment #10) > warn:mshtml:HTMLDOMNode_QI (0x2ae3ea8)->({3050f1ff-98b5-11cf-bb82-00aa00bdce0b} > 0x32d6a0) > Это получение IHTMLElement Нужно посмотреть раньше по трейсам. IHTMLElement должен возвращаться до вызова HTMLDOMNode (это как бы страховочный вариант,а так все *Element должны обрабатываться раньше), хотя бы из HTMLElement_QI: }else if(IsEqualGUID(&IID_IHTMLElement, riid)) { TRACE("(%p)->(IID_IHTMLElement %p)\n", This, ppv); *ppv = HTMLELEM(This);
Собственно, проблема с IHTMLElement перестала воспроизводиться. Единственная проблема, из-за которой падаем - использование функции IPropertyNotifySink_OnChanged() с передачей в неё DISPID_READYSTATE Отключение вызова через проверку на dispid исключает падения, но неизвестно, к каким проблемам может привести в будущем. Могу сделать хак к релизу: for(i=0; i<This->sinks_size; i++) { - if(This->sinks[i].propnotif) + if(This->sinks[i].propnotif && dispid != DISPID_READYSTATE) IPropertyNotifySink_OnChanged(This->sinks[i].propnotif, dispid); }
commit 357011ee2ee831cd80e5bacac50484c1dd1eb06b Author: Konstantin Kondratyuk <kondratyuk@etersoft.ru> Date: Tue Apr 7 14:36:09 2009 +0400 mshtml: Turn off notifies for DISPID_READYSTATE (eterbug #2942) Видимо, FIXED. Будем надеяться, что в наших сборках не появится ряд глюков gecko из-за отключенных уведомлений.
> mshtml: Turn off notifies for DISPID_READYSTATE (eterbug #2942) Патч вызывает зависание теста для dom в mshtml.
