Thanks for the tip, Stephan. I'll try that tomorrow at let everyone know how it works out!
On Thu, Apr 28, 2011 at 4:32 PM, Stephan Bergmann < stephan.bergm...@oracle.com> wrote: > 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 > -- ----------------------------------------------------------------- To unsubscribe send email to dev-unsubscr...@openoffice.org For additional commands send email to sy...@openoffice.org with Subject: help
