Hello Du Yunfen, one thing beforehand: Great to see you think I'm the right person for this kind of problem :), but actually this touches code areas which I barely know. Thus, I think this discussion is best continued at [EMAIL PROTECTED] I send this mail to the list, and would like to ask you to reply to the list, too.
Further comments inline (and full quote for the new readers). > Hi, Mr Schönheit > > It's still on the issue mentioned last time. > the operation steps as follows: > > .create a new writer(or base ,calc ,draw ...). > .click view->datasource. > .choose a local datasource of nodes ,connect. > .activate the context. > .switch to another input method . > > then the application will freeze.We had Tracked the threads and I found > when it is freezed, the application is still > activated in the thread *[3640]rtl_cache_wsupdate_all* and always in a > cycle which is in ../sal/source/rtl/alloc_cache.c : > rtl_cache_wsupdate_all (void * arg) > { ...... > while (!g_cache_list.m_update_done) > { ...... > } > }, > and This doesn't tell me anything, sorry. > in the thread *[3888]desktop::GetURL_Impl*, the programme run to > ERROR_MORE_DATA in osl_acceptPipe(oslPipeImpl * pPipe=0x02dec57c) which > in ../sal/osl/w32/pipe.c. > > So I want to know what are modules( *sal* and *vos* ) used to achieve > and the possible contact between switch the input method and connected > a local datasource ? I don't know ... sal is the "system abstraction layer", vos is some older code for low-level system independent stuff, where nearly everything in vos has a modern replacement in sal or osl. > Thanks. > Best Wishes. > > duyunfen > > > ps: the threads: > > [3100]WinMain > ntdll.dll!7c92eb94() > user32.dll!77d194be() > user32.dll!77d1b42d() > user32.dll!77d184fc() > user32.dll!77d185a4() > user32.dll!77d1b3f9() > user32.dll!77d1b393() >> vcl680mi.dll!SalFrameWndProcW(HWND__ * hWnd=0x001008e4, unsigned int > nMsg=80, unsigned int wParam=1, long lParam=-534640636) Line 6060 + 0x16 C++ > user32.dll!77d18734() > user32.dll!77d18816() > imm32.dll!7630e489() > user32.dll!77d1f805() > user32.dll!77d189cd() > user32.dll!77d18a10() > vcl680mi.dll!ImplDispatchMessage(const tagMSG * lpMsg=0x0101f698) Line > 200 + 0xa C++ > vcl680mi.dll!ImplSalDispatchMessage(tagMSG * pMsg=0x0101f698) Line 716 + > 0x9 C++ > vcl680mi.dll!ImplSalYield(unsigned char bWait='', unsigned char > bHandleAllCurrentEvents=0) Line 746 + 0x9 C++ > vcl680mi.dll!WinSalInstance::Yield(bool bWait=true, bool > bHandleAllCurrentEvents=false) Line 791 + 0xd C++ > vcl680mi.dll!Application::Yield(bool bAllEvents=false) Line 554 C++ > vcl680mi.dll!Application::Execute() Line 516 + 0x7 C++ > soffice.exe!desktop::Desktop::Main() Line 1803 C++ > vcl680mi.dll!ImplSVMain() Line 255 C++ > vcl680mi.dll!SVMain() Line 296 C++ > soffice.exe!sal_main(int __formal=1, int __formal=1) Line 82 C++ > soffice.exe!WinMain(void * _hinst=0x00400000, void * _dummy=0x00000000, > char * _cmdline=0x00051f0a, int _nshow=1) Line 74 + 0x39 C++ > soffice.exe!WinMainCRTStartup() Line 390 + 0x1b C > kernel32.dll!7c816fd7() > ntdll.dll!7c935b4f() This thread *might* be part of the problem, since it seems that dispatching a message blocks for whatever reasons. However, I don't know enough about that kind of stuff. > > [3640]rtl_cache_wsupdate_all > ntdll.dll!7c92eb94() > ntdll.dll!7c92e9c0() > kernel32.dll!7c8025cb() > kernel32.dll!7c802532() >> sal3.dll!rtl_cache_wsupdate_wait(unsigned int seconds=10) Line 1450 C > sal3.dll!rtl_cache_wsupdate_all(void * arg=0x0000000a) Line 1547 + 0x9 C > kernel32.dll!7c80b683() > > [3956]oslWorkerWrapperFunction > ntdll.dll!7c92eb94() > ntdll.dll!7c92e9c0() > kernel32.dll!7c8025cb() > ntdll.dll!7c946abe() > kernel32.dll!7c802532() >> sal3.dll!osl_waitCondition(void * Condition=0x00000f48, const > TimeValue * pTimeout=0x03d7ff54) Line 112 + 0xe C > vos3MSC.dll!vos::OCondition::wait(const TimeValue * pTimeout=0x03d7ff54) > Line 75 + 0x10 C++ > vos3MSC.dll!vos::OTimerManager::run() Line 492 + 0x14 C++ > vos3MSC.dll!vos::threadWorkerFunction_impl(void * pthis=0x02de6eb4) Line > 50 + 0xc C++ > sal3.dll!oslWorkerWrapperFunction(void * pData=0x03313eb0) Line 81 + 0xd C > msvcr71.dll!63fb9565() > ntdll.dll!7c946abe() > kernel32.dll!7c80b683() > ntdll.dll!7c946abe() > > [3888]desktop::GetURL_Impl > ntdll.dll!7c92eb94() > ntdll.dll!7c92e9c0() > kernel32.dll!7c8025cb() > ntdll.dll!7c92fb6c() > ntdll.dll!7c92da69() > kernel32.dll!7c802532() > kernel32.dll!7c831608() >> sal3.dll!osl_acceptPipe(oslPipeImpl * pPipe=0x02dec57c) Line 418 + 0x17 C > vos3MSC.dll!vos::OPipe::accept(vos::OStreamPipe & Connection={...}) Line > 232 + 0xf C++ > soffice.exe!desktop::OfficeIPCThread::run() Line 575 + 0x13 C++ > vos3MSC.dll!vos::threadWorkerFunction_impl(void * pthis=0x02e0a804) Line > 50 + 0xc C++ > sal3.dll!oslWorkerWrapperFunction(void * pData=0x0330e778) Line 81 + 0xd C > msvcr71.dll!63fb9565() > kernel32.dll!7c80b683() > soffice.exe!desktop::GetURL_Impl(const String & rName={...}) Line 2786 + > 0xd C++ > soffice.exe!desktop::GetURL_Impl(const String & rName={...}) Line 2786 + > 0xd C++ > c0c40000() > soffice.exe!desktop::GetURL_Impl(const String & rName={...}) Line 2786 + > 0xd C++ > soffice.exe!desktop::GetURL_Impl(const String & rName={...}) Line 2786 + > 0xd C++ > c0c40000() > soffice.exe!desktop::GetURL_Impl(const String & rName={...}) Line 2786 + > 0xd C++ > soffice.exe!desktop::GetURL_Impl(const String & rName={...}) Line 2786 + > 0xd C++ > c0c40000() > soffice.exe!desktop::GetURL_Impl(const String & rName={...}) Line 2786 + > 0xd C++ > soffice.exe!desktop::GetURL_Impl(const String & rName={...}) Line 2786 + > 0xd C++ > c0c40000() > soffice.exe!desktop::GetURL_Impl(const String & rName={...}) Line 2786 + > 0xd C++ > soffice.exe!desktop::GetURL_Impl(const String & rName={...}) Line 2786 + > 0xd C++ > c0c40000() > soffice.exe!desktop::GetURL_Impl(const String & rName={...}) Line 2786 + > 0xd C++ > soffice.exe!desktop::GetURL_Impl(const String & rName={...}) Line 2786 + > 0xd C++ > c0c40000() > soffice.exe!desktop::GetURL_Impl(const String & rName={...}) Line 2786 + > 0xd C++ > soffice.exe!desktop::GetURL_Impl(const String & rName={...}) Line 2786 + > 0xd C++ > c0c40000() > soffice.exe!desktop::GetURL_Impl(const String & rName={...}) Line 2786 + > 0xd C++ > soffice.exe!desktop::GetURL_Impl(const String & rName={...}) Line 2786 + > 0xd C++ > c0c40000() > soffice.exe!desktop::GetURL_Impl(const String & rName={...}) Line 2786 + > 0xd C++ > soffice.exe!desktop::GetURL_Impl(const String & rName={...}) Line 2786 + > 0xd C++ > c0c40000() > soffice.exe!desktop::GetURL_Impl(const String & rName={...}) Line 2786 + > 0xd C++ > soffice.exe!desktop::GetURL_Impl(const String & rName={...}) Line 2786 + > 0xd C++ > c0c40000() > soffice.exe!desktop::GetURL_Impl(const String & rName={...}) Line 2786 + > 0xd C++ > soffice.exe!desktop::GetURL_Impl(const String & rName={...}) Line 2786 + > 0xd C++ > c0c40000() > soffice.exe!desktop::GetURL_Impl(const String & rName=) Line 2786 + 0xd C++ This thread's stack looks suspicious - too many GetURL_Impl instances here, I somehow think this stack is corrupted. Besides this, I think this thread might also be a part of the freeze. > > [3096]Win32 Thread > [476]Win32 Thread > > [3444]oslWorkerWrapperFunction > ntdll.dll!7c92eb94() > ntdll.dll!7c92e9c0() > kernel32.dll!7c8025cb() > kernel32.dll!7c802532() > nspr4.dll!3001886c() > nspr4.dll!300149fc() > nspr4.dll!30014b23() > nspr4.dll!30014516() > mozabdrv2.dll!MNS_XPCOM_EventLoop() + 0xd0 C++ > mozabdrv2.dll!_MNS_Mozilla_UI_Thread() + 0x2b C++ >> sal3.dll!oslWorkerWrapperFunction(void * pData=0x06151d50) Line 81 + 0xd C > msvcr71.dll!63fb9565() > kernel32.dll!7c80b683() This thread might also be part of the problem. When accessing the Mozilla code shipped with OOo (for access to Mozilla and other address books), all this access runs in a dedicated thread, for technical reasons. 3444 looks as if it is exactly this thread. Might be interesting to know at which line in MNS_XPCOM_EventLoop the thread is stuck here. To check whether this is code is part of the problem, you might try to simply remove te mozabdrv2.dll from your installation. This will prevent it being loaded, without problems at the UI (only various address books are not available then). > [3564]Win32 Thread > [3924]Win32 Thread > [1832]Win32 Thread > [1188]Win32 Thread > [980]Win32 Thread > [3332]Win32 Thread Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Sitz der Gesellschaft: - - Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten - - Amtsgericht München: HRB 161028 - - Geschäftsführer: Wolfgang Engels, Dr. Roland Bömer - - Vorsitzender des Aufsichtsrates: Martin Häring - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]