Hi Mikhail,
I have been preparing the linux build. Following the "Non_Product_Build"
you suggested me and the "Installing#Installing_more_than_one_version"
entry from OOo wiki, in my Fedora 7, I got the build installed,
seemingly successfully. However, when I tried to run the office from
console the application crashed before the main frame showed up. The
attachment is the output in the console. Could you please check it and
tell me if there's something not right?
As we discussed in our last IRC meeting, I also checked the crash of
i63661, unfortunately it still exists in my SRC680_m238 build, for
information I attached the stack, it's almost the same as that generated
in the old SRC680_m225 build. Should we do more verification work in
this condition?
And I hope you had a splendid vacation with your family back in Russia,
I'll be very happy if you would like to share some of your stories with
me in private mails. ;-)
Best Regards,
Felix.
Zhang Xiaofei
Hi Mikhail,
The patches have been attached to the issue. Thank you very much for
helping me on this task, and I'm eagerly looking forward to the next one.
Thanks and Best Regards, :-)
Felix.
Mikhail Voitenko
Hi Felix,
Thank you for the new patches. I would say you could attach them
already to the issue. But since you will need the new version for
further development anyway, you could try the patches on the new
version to check whether the strange crash is still reproducible in
your environment.
I think there is no need to wait for m239 in this case, m238 is
relative stable and I currently can not see any benefit from using
m239 instead.
I will looks for the next task :)
Best Regards,
Mikhail.
Zhang Xiaofei wrote:
Zhang Xiaofei
Hi Mikhail,
Thanks for testing the patches, however I am afraid the result is
still uncertain. I rebuilt the full build and the crash still
exist, since my build is based on SRC680_m225, I guess it is better
I integrate the patches to a newer one and retest it? I have got
the source of SRC680_m238 but I hear SRC680_m239, which will be
used as the foundation of OOo 3.0 is being released soon, should I
wait for the latter one? I'm looking forward to your suggestions.
Thanks,
Felix.
P.S. I feel very sorry for the typos exist in the last patches, I
corrected them and made the new patches.
Mikhail Voitenko
Hi Felix,
Sorry for the delay. I have just tried your patch and it works
pretty well by me. So there seems to be something wrong with your
build.
Best regards,
Mikhail.
Zhang Xiaofei wrote:
Hi Mikhail,
Thanks very much for your replay, I have modified the patch to
sw, however my modification caused the build to collapse. I feel
awfully sorry to bother you again and again, but apparently there
is something I misunderstood in your instructions, could you
check the patch and point it out for me, or direct me to an
example that inserts a wrapper into the MediaDescriptor service,
please?
Thanks and Best Regards,
Felix.
Mikhail Voitenko 写道:
Hi Felix,
The problem is that the new writer patch does not exchange the
InteractionHandler any more. Instead it shows the broken package
notifications using the new wrapper, that is unnecessary. As I
have written in the last IRC meeting, the wrapper should be
insert into the InteractionHandler after the repairing has
failed or user has canceled the repairing, in other words it
should be done just after the NotifyBrokenPackage interaction is
shown.
Best Regards,
Mikhail.
Zhang Xiaofei wrote:
Hi Mikhail,
Thanks to your advice in our last IRC meeting, I have remade
the patches so that the wrapper handles the interaction
instead. Unfortunately the modifications still do not prevent
the filter selection box from appearing. Could you help to
review the patches and give me some suggestions please?
With Thanks and Best Regards,
Felix.
zhangxiaofei 写道:
Hi Mikhail,
I'm sorry I encountered some problem. The implementation of
the wrapper was OK in the compilation phase, but when I tried
to initialize an instance of it, I got the link error as in
the log. I'm not sure if the problem lies in the
implementation, or it is because I did not initialize it in
the right way. Could you help me with this please?
Thanks and Best Regards,
Felix.
Mikhail Voitenko 写道:
Hi Felix,
In this case a wrapper is just an implementation that
implements the same set of interfaces as the original object,
and redirects most of the calls to the original object. It
just slightly changes the behavior by aborting the filter
selection interception.
There is no necessity to register the wrapper as a service in
this case. The object will be just created with C++ "new"
operator and after that it's lifetime will be controlled by
refcounting as it happens for all the UNO-objects. In other
words the factory for the object is the source code itself in
this case, because of this the XInitialization interface is
also not necessary here ( XInitialization is used only on
object initialization and should not be used further ).
Theoretically XServiceInfo should be implemented, since it is
a wrapper for the service.
And since in this case the source code has access to the C++
interface, it can use C++ API in addition to the UNO API ( in
this case we will use the constructor to provide the original
interaction handler ). But only while the object is
accessible as C++ object. Since the InteractionHandler
wrapper is inserted into the MediaDescriptor ( in other words
it is transported using UNO API ), the source code that will
retrieve it from there will be able to use UNO API only.
Best Regards,
Mikhail.
Zhang Xiaofei wrote:
Hi Mikhail,
Thanks you very much for your instructions. Sorry I'm not
very familiar with this wrapper concept, so I may need your
help on these questions:
- Does a wrapper of an interface basically has the same
intention to an implementation of an service, only the
latter implements multiple interfaces?
- How can a implemented wrapper be used in further
programming? Since there's not registration as a component I
guess we should just make an instance of the class and call
its member functions?
Thanks and Best Regards,
Felix.
Mikhail Voitenko 写道:
Hi Felix,
thank you for the stacks. The problem here is that after
the user has decided to do no recovery the filter detection
process actually should be stopped. Unfortunately it seems
that the current design does not allow to do it, and the
shown filter selection dialog is just a part of the filter
detection process that goes further.
We could use a workaround, implement a wrapper around
interaction handler, that would prevent showing of the
filter selection dialog. We could probably prevent
appearing of any dialog during the further detection, but I
would prefer to avoid possibility of non wished quite
actions. Even if they are not possible now, they could be
implemented in future.
So the wrapper will implement the task::XInteractionHandler
interface. The constructor will get the original
interaction handler and in case
XInteractionHandler::handle() call is called the
implementation will call the original handler except the
case that the "document::NoSuchFilterRequest" is provided.
You can find an example of similar wrapper implementation
in sfx2/source/doc/docfile.cxx:SfxMediumHandler_Impl. I
think it makes sense that the class is implemented in
"comphelper" since the problem should be solved not only
for writer, but also for other applications.
Best Regards,
Mikhail.
Zhang Xiaofei wrote:
Hi Mikhail,
I'm glad to know the previous issue is solved. :-)
The problem of i63661 is still reproducible here, I
recorded the stacks respectively to all the three boxes
are shown, (while the third one may be not so useful,) the
previous two are almost the same except for the 16th line:
===================================
+swd680mi.dll!SwFilterDetect::detect(com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue>
& lDescriptor={...}) Line 317 + 0x22 C++
(stack1_promptdialog)
-swd680mi.dll!SwFilterDetect::detect(com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue>
& lDescriptor={...}) Line 326 + 0x22 C++
(stack2_notifydialog)
-----------------------------------
Some tracing shows that bRepairAllowed has the right value
0, sorry I didn't got enough time to finish the tracing,
maybe the problem lies around line 426 of
G:\OOo\SRC680_m225\sw\source\ui\uno\swdetect.cxx. I'll
have to continue it next Monday. Could you give me some
hints on this, please?
Thanks and Best Regards,
Felix.
Mikhail Voitenko 写道:
Hi Felix,
Thank you for checking the scenario. I have marked the
issue as non reproducible and have sent it to QA.
A new task could the the issue i63661. Please test
whether the problem is still reproducible. If it is,
please get the call stack at the place where the dialog
regarding document repair is shown, just break in the
debugger while the dialog is visible. There are two
places, where the recovery might be activated, so we need
to detect which one is affected.
Best Regards,
Mikhail.
------------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
------------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
------------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
bootstrap.uno.dll!Registry::operator=() + 0x15 C++
bootstrap.uno.dll!RegistryKey::openKey() + 0x3f C++
bootstrap.uno.dll!stoc_simreg::RegistryKeyImpl::RegistryKeyImpl() +
0x89 C++
bootstrap.uno.dll!stoc_simreg::SimpleRegistryImpl::getRootKey() + 0x70
C++
bootstrap.uno.dll!stoc_defreg::NestedKeyImpl::computeName() + 0xd0
C++
bootstrap.uno.dll!stoc_defreg::NestedKeyImpl::getResolvedName() + 0x42
C++
bootstrap.uno.dll!stoc_defreg::NestedKeyImpl::computeName() + 0x74
C++
bootstrap.uno.dll!stoc_defreg::NestedKeyImpl::getResolvedName() + 0x42
C++
bootstrap.uno.dll!stoc_defreg::NestedKeyImpl::computeName() + 0x74
C++
bootstrap.uno.dll!stoc_defreg::NestedKeyImpl::getResolvedName() + 0x42
C++
bootstrap.uno.dll!stoc_defreg::NestedKeyImpl::computeName() + 0x74
C++
bootstrap.uno.dll!stoc_defreg::NestedKeyImpl::openKey() + 0x43 C++
bootstrap.uno.dll!stoc_smgr::ORegistryServiceManager::loadWithImplementationName()
+ 0x86 C++
bootstrap.uno.dll!stoc_smgr::ORegistryServiceManager::queryServiceFactories()
+ 0x7d C++
bootstrap.uno.dll!stoc_smgr::OServiceManager::createInstanceWithContext() +
0x36 C++
bootstrap.uno.dll!stoc_smgr::OServiceManager::createInstance() + 0x1e
C++
filterconfig1.dll!filter::config::TypeDetection::impl_askDetectService() +
0x6e C++
filterconfig1.dll!filter::config::TypeDetection::impl_detectTypeDeepOnly() +
0x3bb C++
filterconfig1.dll!filter::config::TypeDetection::queryTypeByDescriptor() +
0x1cd C++
fwk680mi.dll!framework::LoadEnv::impl_detectTypeAndFilter() + 0x135
C++
fwk680mi.dll!framework::LoadEnv::startLoading() + 0x55 C++
fwk680mi.dll!framework::LoadEnv::loadComponentFromURL() + 0x82 C++
fwk680mi.dll!framework::Desktop::loadComponentFromURL() + 0xa3 C++
> sfx680mi.dll!SfxApplication::OpenDocExec_Impl(SfxRequest & rReq={...})
> Line 1420 + 0x50 C++
sfx680mi.dll!SfxStubSfxApplicationOpenDocExec_Impl(SfxShell *
pShell=0x026f79d0, SfxRequest & rReq={...}) Line 1123 + 0xf C++
sfx680mi.dll!SfxDispatcher::Call_Impl(SfxShell & rShell={...}, const
SfxSlot & rSlot={...}, SfxRequest & rReq={...}, unsigned char bRecord=0) Line
338 + 0xb C++
sfx680mi.dll!SfxDispatcher::_Execute(SfxShell & rShell={...}, const
SfxSlot & rSlot={...}, SfxRequest & rReq={...}, unsigned short eCallMode=1)
Line 1106 C++
sfx680mi.dll!SfxDispatcher::Execute(unsigned short nSlot=5501, unsigned
short eCall=1, unsigned short nModi=0, const SfxItemSet & rArgs={...}) Line
1489 C++
sfx680mi.dll!SfxDispatcher::Execute(unsigned short nSlot=5501, unsigned
short eCall=1, const SfxItemSet & rArgs={...}) Line 1461 C++
sfx680mi.dll!SfxApplication::OpenDocExec_Impl(SfxRequest & rReq={...})
Line 1018 C++
sfx680mi.dll!SfxStubSfxApplicationOpenDocExec_Impl(SfxShell *
pShell=0x026f79d0, SfxRequest & rReq={...}) Line 1123 + 0xf C++
sfx680mi.dll!SfxDispatcher::Call_Impl(SfxShell & rShell={...}, const
SfxSlot & rSlot={...}, SfxRequest & rReq={...}, unsigned char bRecord='')
Line 338 + 0xb C++
sfx680mi.dll!SfxDispatcher::PostMsgHandler(SfxRequest *
pReq=0x0865cb20) Line 1650 C++
sfx680mi.dll!SfxDispatcher::LinkStubPostMsgHandler(void *
pThis=0x026cbf40, void * pCaller=0x0865cb20) Line 1610 + 0xf C++
tl680mi.dll!Link::Call(void * pCaller=0x0865cb20) Line 158 + 0x19
C++
sfx680mi.dll!SfxHintPoster::Event(SfxHint * pPostedHint=0x0865cb20)
Line 98 + 0x31 C++
sfx680mi.dll!SfxHintPoster::LinkStubDoEvent_Impl(void *
pThis=0x026ce650, void * pCaller=0x0865cb20) Line 92 + 0x12 C++
tl680mi.dll!Link::Call(void * pCaller=0x0865cb20) Line 158 + 0x19
C++
vcl680mi.dll!ImplHandleUserEvent(ImplSVEvent * pSVEvent=0x085e40b8)
Line 2033 C++
vcl680mi.dll!ImplWindowFrameProc(Window * pWindow=0x026c3db8, SalFrame
* __formal=0x026d5008, unsigned short nEvent=22, const void *
pEvent=0x085e40b8) Line 2528 + 0x9 C++
vcl680mi.dll!ImplHandleUserEvent(HWND__ * hWnd=0x0001113c, long
lParam=140394680) Line 4488 + 0x20 C++
vcl680mi.dll!SalFrameWndProc(HWND__ * hWnd=0x0001113c, unsigned int
nMsg=1154, unsigned int wParam=0, long lParam=140394680, int & rDef=1) Line
5993 + 0xd C++
vcl680mi.dll!SalFrameWndProcW(HWND__ * hWnd=0x0001113c, unsigned int
nMsg=1154, unsigned int wParam=0, long lParam=140394680) Line 6148 + 0x19 C++
user32.dll!77d18734()
user32.dll!77d18816()
user32.dll!77d189cd()
user32.dll!77d19402()
user32.dll!77d18a10()
vcl680mi.dll!ImplDispatchMessage(const tagMSG * lpMsg=0x0100f558) Line
200 + 0xa C++
vcl680mi.dll!ImplSalDispatchMessage(tagMSG * pMsg=0x0100f558) Line 722
+ 0x9 C++
vcl680mi.dll!ImplSalYield(unsigned char bWait='', unsigned char
bHandleAllCurrentEvents=0) Line 740 + 0x9 C++
vcl680mi.dll!WinSalInstance::Yield(bool bWait=true, bool
bHandleAllCurrentEvents=false) Line 797 + 0xd C++
vcl680mi.dll!Application::Yield(bool bAllEvents=false) Line 558
C++
vcl680mi.dll!Application::Execute() Line 516 + 0x7 C++
soffice.exe!desktop::Desktop::Main() Line 1702 C++
vcl680mi.dll!ImplSVMain() Line 263 C++
vcl680mi.dll!SVMain() Line 304 C++
soffice.exe!sal_main_with_args(int __formal=1, int __formal=1) Line
117 C++
soffice.exe!main(int argc=1, char * * argv=0x00036f08) Line 83 + 0x21
C++
soffice.exe!WinMain(void * _hinst=0x00400000, void * _dummy=0x00000000,
char * _cmdline=0x00051f0c, int _nshow=1) Line 83 + 0x29 C++
soffice.exe!WinMainCRTStartup() Line 390 + 0x1b C
kernel32.dll!7c816fd7()
[EMAIL PROTECTED] program]$ soffice
libGL error: drmMap of framebuffer failed (ÎÞЧµÄ²ÎÊý)
libGL error: reverting to (slow) indirect rendering
Environment
$XENVIRONMENT ""
$DISPLAY ":0.0"
$SAL_VISUAL ""
$SAL_FONTPATH ""
$SAL_NOSEGV ""
$SAL_IGNOREXERRORS ""
$SAL_PROPERTIES ""
$SAL_WM ""
$SAL_SYNCHRONIZE ""
Client
Host "localhost.localdomain"
Display
Host ":0.0"
Vendor (Release) "The X.Org Foundation (10300000)"
Protocol 11.0
Screen (count,def) 0 (1,0)
shift ctrl alt Shift_L (0xFFE1) Control_L (0xFFE3) Alt_L
(0xFFE9)
XMaxRequestSize 262140 16777212 [bytes]
Properties 0x1000FCB
Screen
Resolution/Size 96*96 1024*768 15.9"
Black&White 0 16777215
RGB 0xff0000 0xff00 0xff
Visual 24-bit TrueColor ID=0x24
sh: crash_report: command not found---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
