Thanks a lot for your explanation! 
Port and server (report.services.openoffice.org) are specified.
Unfortunatly looping is not reproducible, otherwise I would file an
issue in a flash.

But I do not understand how looping process can write debug info while
being killed?

> -----Original Message-----
> From: Eike Rathke [mailto:[EMAIL PROTECTED] 
> Sent: Monday, August 07, 2006 11:12 PM
> To: dev@openoffice.org
> Subject: Re: [dev] 100% CPU by soffice.bin or crash - sending 
> .dmp file to developers?
> 
> Hi Kirill,
> 
> On Thu, Aug 03, 2006 at 22:45:49 +0400, Kirill S. Palagin wrote:
> 
> > I have found reference to Error Report Tool in help, but I 
> do not see 
> > option to turn reporting on or off. Also double-clicking 
> "crashrep.exe"
> > is not producing any visible effect.
> 
> Invoking the crash reporter manually (respectively by double-clicking
> it) doesn't make much sense. When a crash occurs, stack 
> information is written to some file (don't know right now 
> where that is located on
> Windows) and when the Office then is restartet the next time 
> it offers to recover files that were open during the crash, 
> and after that the crash reporter is invoked, if enabled. 
> Whether it is enabled is configured in 
> <YourOOoPath>/program/bootstrap.ini in the [ErrorReport] 
> section. If there is no server or port specified, the 
> functionality is disabled. Which for builds not originating 
> from the openoffice.org website or its mirrors is the default 
> case, because the infrastructure needed is missing for other builds.
> 
> > Is there special procedure to follow when soffice.bin is 
> stuck at 100% 
> > CPU usage?
> 
> If you kill the Office, the official build should write the 
> crash information. If it doesn't in your case, then there 
> isn't much you could do. If the behavior (looping 
> indefinitely) is reproducible under certain conditions you 
> may file a normal bug report issue, see 
> http://qa.openoffice.org/issue_handling/pre_submission.html
> maybe it could be reproduced on other systems too.
> 
>   Eike
> 
> --
>  PGP/OpenPGP/GnuPG encrypted mail preferred in all private 
> communication.
>  Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3  9E96 2F1A 
> D073 293C 05FD
> 
> ---------------------------------------------------------------------
> 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]

Reply via email to