Hi Mr Schönheit,
> Hello Du Yunfen,
>
> I re-send the below mail to you only, since the first attempt wasn't
> successful. Either your email client, or your email server/gateway, has
> a wrong setup: Your mails arrived here with a wrong "From" header, which
> means when I reply to them, they cannot be delivered. Please correct
> this problem, else it's difficult to communicate ...
>
> Also, sending a mail to [EMAIL PROTECTED] fails with the message:
> <[EMAIL PROTECTED]>:
> 210.51.172.242 does not like recipient.
> Remote host said: 550 5.1.1 <[EMAIL PROTECTED]>... User unknown
> Giving up on 210.51.172.242.
> Sounds like the setup of your OOo account has a wrong email address.
> Please fix this, too.
>
>
> Thanks & Ciao
> Frank
>
>
Thanks for your reminding :)! I checked the email, it was just the one I used
before , and the OOo account 's is also correct. Hope it is right this time.
If it is still wrong, I'll try to contact network management.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> 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).
>
OK.:)
>> 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.
>
:)Several days had been gone since we discussed this issue last time, so I
re-described the issue.
But this operation steps is diffrent to last time,This time I found as long as
I connected a local datasource, the programme was sure to be freezed whether
in calc , writer or base.
......
> 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.
>
I see.
>> 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).
>
Thanks for such detailed analysis. Let me continue tracking and thinking it.
Best Wishes.
duyunfen
