I would first try and see whether some Windows debugger (MS Studio or WinDbg) lets you attach to soffice.exe and intercept C++ exceptions of type std::bad_alloc. (Running OOo throws and catches lots of exceptions, so intercepting all C++ exceptions might produce too much noise, but it should normally not produce any std::bad_alloc ones.) The stack trace of the throw then hopefully gives a clue already, without any additional debug-build-hassle.
-Stephan On Apr 28, 2011, at 4:56 PM, Grover Blue wrote: > "perhaps it's necessary to build OOo with debug information first" > > I don't know how to do that, but I'm willing to try with some help. The only > source I could find was for the java libraries. This is a very critical > problem and needs to be resolved. Too bad there isn't a developer exe > release with debugging enabled. > > > On Tue, Apr 26, 2011 at 10:36 AM, Michael Stahl <michael.x.st...@oracle.com> > wrote: > On 26/04/2011 15:22, Grover Blue wrote: > > I have a muti-threaded application that processes document mostly > > asynchronous. I synchronize all UnoRuntime.* API calls, but not such > > calls as setting a table cell's value, etc. Everything runs fine in > > development, qa and in a production environment for one our clients. We > > have another client, however, where we are experience a complete > > breakdown. While processing, we continually get the following > > exception. Both clients are running version 3.3 of OpenOffice/UNO. Has > > anyone experienced this or is there a way to get more information/debug > > OpenOffice? > > you could run OOo with the debugger attached, and set a breakpoint on > thrown exceptions. but i'm not familiar with windows, and don't know > whether that would actually work on our release builds. > perhaps it's necessary to build OOo with debug information first... > > > Here is how OpenOffice is launched from bootstrapconnector: > > C:\Program Files\OpenOffice.org 3\program\soffice.exe -nologo -nodefault > > -norestore -nocrashreport -nolockcheck -headless -nofirststartwizard > > -accept=pipe,name=uno3869894507064209706;urp; > > > > Here is the RuntimeException: > > > > com.sun.star.uno.RuntimeException: [msci_uno bridge error] UNO type of > > C++ exception unknown: "std.bad_alloc", RTTI-name=".?AVbad_alloc@std@@"! > > it looks like the original exception on the C++ side is std::bad_alloc. > this exception is thrown by operator new() when a memory allocation fails. > there are also lots of places in OOo where this exception is thrown, also > after checking that some allocation failed. > > perhaps there is a leak somewhere? > does the OOo process actually use enormous amounts of RAM? > > can you see a problem by exporting the same document that fails to PDF via > the UI? -- ----------------------------------------------------------------- To unsubscribe send email to dev-unsubscr...@openoffice.org For additional commands send email to sy...@openoffice.org with Subject: help
