Lukasz Szybalski wrote:
On Thu, Nov 19, 2009 at 1:26 AM, Kay Ramme <[email protected]> wrote:
Hi Lukasz,
could you give a brief overview over your system, the OS, the arch and the
OOo version etc.? That would help debugging this. You find the detailed OOo
version in the "about" dialog.
The upgraded version is :
3.1.1.1-1bpo50+1 sat sept 2009
The memory problem is again in the headless portion.
If I run the program in non-headless package the memory consumption
stays the same. When program loads the odt template the memory
increases by 2% , but when the file is dispose() the memory goes back
down by 2%. In headless mode the memory just keeps going up by 2%
every time a file is loaded and dispose()
If I new a command that would save a memory usage for a process and
save the new values every 5 sec, I would draw you guys a graph to show
how memory is going up.
Somebody mentioned I could attached a debugger to oo? How would I do
that? Is that a command argument that I just add or?
Any ideas on memory usage, and how to fix it?
Hi Lucas,
I had this same problem of memory. In my case it consumed all the RAM
and SWAP and then returned to DisposedException exception. To solve this
problem I did with my application never kept one in the memory forever.
In Python I created a script that used the UNO and my tool called this
script as if it were a command. For example:
unoconverter.py
[code]
import uno
... do something with uno ....
return response
[/code]
service.py
[code]
stdout, stderr = subprocess.Popen("./unoconverter.py --arguments",
shell=True, stdout=PIPE, stderr=PIPE).communicate()
[/code]
Thus, when the UNO is removed from memory and after each time the
openoffice is used the memory used is deallocated.
Thanks,
Lucas
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
--
Gabriel M. Monnerat
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
