RE: [libreoffice-users] question about "Binary URP bridge disposed during call" error

Hi Stephan,

I redo the batch testing and you are right: my program killed soffice.bin after waiting 2 minutes 
and can't open 
a file for printing through  "m_xDesktop->loadComponentFromURL()". And the function then throw a 
"Binary URP bridge disposed during call" exception.  (And no LibreOffice crash happen for my new 
printing program. )

This issue happened randomly and most of the time the same file can be opened correctly.  

Basically, the testing case is to start soffice.bin and print 10 files then close it. The testing 
case will be repeated thousands time. 
If I restart soffice.bin every time a printing job finished, "loadComponentFromURL()" always return 
quickly. 

I am wondering why "m_xDesktop->loadComponentFromURL()" sometimes get stuck and how to generate 
debugging information when it get stuck?
  
Best Regards,

Shawn

-----Original Message-----
From: Stephan Bergmann [mailto:sbergman@redhat.com] 
Sent: Wednesday, February 24, 2016 6:40 AM
To: Shawn Cao <SCao@printeron.com>; users@global.libreoffice.org
Subject: Re: [libreoffice-users] question about "Binary URP bridge disposed during call" error

On 02/23/2016 03:18 PM, Shawn Cao wrote:
> Because each testing will open and close LibreOffice, I am not sure 
> how to attach WinDbg with those evanescent processes. Fortunately, 
> Windows will generate dump file for each LibreOffice crash. I open 
> dump file with WinDbg and please refer to attachment for the trace 
> result. I tested 5.1.1.1 and will test latest Dev version soon.

> STACK_TEXT:
> 00e7f2e8 76c23fc8 kernelbase!RaiseException+0x48
> 00e7f348 6a0f9339 msvcr120!_CxxThrowException+0x5b
> 00e7f388 659c020c 
> ucbhelper!com::sun::star::ucb::UniversalContentBroker::create+0x16c
> 00e7f3ec 659b9d36 ucbhelper!ucbhelper::Content::Content+0x46
> 00e7f424 6766a40f mergedlo!`anonymous namespace'::content+0x6f 
> 00e7f45c 67669ec3 mergedlo!utl::UCBContentHelper::Kill+0x73
> 00e7f4c8 66b0ab84 
> mergedlo!desktop::Desktop::RemoveTemporaryDirectory+0x14
> 00e7f4d0 66b0780d mergedlo!desktop::Desktop::doShutdown+0x21d
> 00e7f520 66b025fc mergedlo!desktop::Desktop::Main+0xe3c
> 00e7f69c 67a05886 mergedlo!ImplSVMain+0x46
> 00e7f6c4 67a05c39 mergedlo!SVMain+0x29
> 00e7f6d0 66b1c599 mergedlo!soffice_main+0x79
> 00e7f740 0018101e soffice+0x101e
> 00e7f794 768b3744 kernel32!BaseThreadInitThunk+0x24
> 00e7f7a8 771b9e54 ntdll!__RtlUserThreadStart+0x2f
> 00e7f7f0 771b9e1f ntdll!_RtlUserThreadStart+0x1b

Hm, that's rather odd.

For one, this crash is during "clean" termination of the soffice.bin process, i.e., at a time when 
your external code should no longer communicate with the soffice.bin process anyway.  (Or is your 
external code designed in a way that it might call com.sun.star.frame.XDesktop.terminate while some 
printing activity is still in progress?)

For another, I see no way how
com::sun::star::ucb::UniversalContentBroker::create could throw an exception there during shutdown. 
 It should already have been called during initialization, from Desktop::Main -> 
Desktop::RegisterServices 
-> configureUcb, and if that had already failed with an exception, that
would have caused a call to FatalError, which immediately terminates the process via _exit.

Are you sure that that crash dump correlates to a "Binary URP bridge disposed during call" 
exception in your client, or could it be from a "harmless" crash of an soffice.bin instance after 
your client code had already disconnected (so might normally go rather unnoticed, except for 
leaving behind a crash dump)?

-- 
To unsubscribe e-mail to: users+unsubscribe@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/users/
All messages sent to this list will be publicly archived and cannot be deleted