Mathias Bauer wrote:
Herter, S. wrote:
With 1.1.0 - 1.1.3 under Windows we have noticed a memory leak that
occurs during repeated load/print and load/export to PDF. We got
around it by shutting down OOo every 250 uses through the API and
then starting it again. If we don't shut it down we can watch memory
slowly increase until it crashes. Don't know if this is the same
problem, but it occurs with repeated load/print and load/export
functions through the Java API.
Yes, we have seen that there are memory leaks in this scenario and we
are looking after this with increased priority.
Of course "out of memory" situations could cause crashes also as you
suggested, so we need call stack traces for crashes that appear in
load-print/export/save cycles to verify wether this is such a situation
or something different (some "real" crashes ;-)).
Would be glad to provide you with stack traces of "real" crashes, since
our application generates these on a regular basis. Environment is x86
Linux, headless with xvfb. What can I do to generate stack traces
non-interactively (this is a server application)? Improving stability
would certainly be in our interest. Current workaround we're using is
breaking down API calls to "atomic" operations (load, export, print,
close) , calling them in a separate thread and monitoring it for a
certain time for success, in case of timeout/failure OOo is restarted
and the operations unsuccessfull so far are repeated. Only a single
thread at a time interacts with OOo during this process.
Regards,
Sven
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
