Re: [dev] how to reduce memory usage of unopkg
Jürgen Schmidt wrote: Christoph Lutz wrote: So it is a C++ out-of-memory condition, not a Java-related one. It might be the included WollMux.rdb that triggers this, but its hard to say without further information. If you have a self-built OOo, you could try re-debugging with a non-stripped libuno_cppu.so.3, or with one built afresh with debug=x (module cppu). thanks! we currently don't have got a self-build OOo, so we will see what we can do to give more information. Is there anything besides that meanwhile might help to find the cause? Do you think splitting the content of the package in two packages could help? that shouldn't be necessary, more interesting is the question why the memory consumption is so high. You can try to deploy the rdb file alone and if the memory consumption is still so high it would make sense if you can provide your type library for further investigation. Make sure that your type library contains only your own new IDL types. I would guess that one of the types in that rdb triggers a bug that leads to an erroneously ridiculously large memory request. But that is only a guess. -Stephan Juergen regards, Christoph - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] how to reduce memory usage of unopkg
Christoph Lutz wrote:
unopkg add ourUNOPackgage --shared
on our debian-system with the original JRE1.5.0 java packages from sun
requires about 300 MB of memory. Is it possible to reduce the memory
usage of unopkg?
huh !!
what is the side of the package ?
package size is 450 kB.
what does it contain ?
here is the output of the unopkg list command. As you can see, there
is a uno.pkg with some java-code and some .XCUs.:
Name: WollMux.uno.pkg
URL:
vnd.sun.star.expand:$UNO_USER_PACKAGES_CACHE/uno_packages/z5Trb4_/WollMux.uno.pkg
is registered: yes
Media-Type: application/vnd.sun.star.package-bundle
Description: UNO Package Bundle
bundled Packages: {
Name: WollMux
URL:
vnd.sun.star.expand:$UNO_USER_PACKAGES_CACHE/uno_packages/z5Trb4_/WollMux.uno.pkg/basic/WollMux/
is registered: yes
Media-Type: application/vnd.sun.star.basic-library
Description: OpenOffice.org Basic Bibliothek
Name: WollMux.rdb
URL:
vnd.sun.star.expand:$UNO_USER_PACKAGES_CACHE/uno_packages/z5Trb4_/WollMux.uno.pkg/WollMux.rdb
is registered: yes
Media-Type: application/vnd.sun.star.uno-typelibrary;type=RDB
Description: UNO RDB Type Library
Name: Jobs.xcu
URL:
vnd.sun.star.expand:$UNO_USER_PACKAGES_CACHE/uno_packages/z5Trb4_/WollMux.uno.pkg/Jobs.xcu
is registered: yes
Media-Type: application/vnd.sun.star.configuration-data
Description: Konfigurationsdaten
Name: ProtocolHandler.xcu
URL:
vnd.sun.star.expand:$UNO_USER_PACKAGES_CACHE/uno_packages/z5Trb4_/WollMux.uno.pkg/ProtocolHandler.xcu
is registered: yes
Media-Type: application/vnd.sun.star.configuration-data
Description: Konfigurationsdaten
Name: Controller.xcu
URL:
vnd.sun.star.expand:$UNO_USER_PACKAGES_CACHE/uno_packages/z5Trb4_/WollMux.uno.pkg/Controller.xcu
is registered: yes
Media-Type: application/vnd.sun.star.configuration-data
Description: Konfigurationsdaten
Name: WollMux.uno.jar
URL:
vnd.sun.star.expand:$UNO_USER_PACKAGES_CACHE/uno_packages/z5Trb4_/WollMux.uno.pkg/WollMux.uno.jar
is registered: yes
Media-Type: application/vnd.sun.star.uno-component;type=Java
Description: UNO Java Component
}
So the failing unopkg add ourUNOPackgage --shared is for
ourUNOPackgage == WollMux.uno.pkg, right? (Just asking because if
the unopkg add consistently fails for that package, a unopkg list
couldn't list it.) :)
is it using this amount for a long time ?
we get a memory allocation error from the jvm, which kills the process
Do you have a stack trace of that Java OutOfMemoryError? unopkg does
execute some code from the jar during registration, so this might shed
some light on what is happening.
-Stephan
BTW:
we are using 'aliend' RPMs of OOo2 2.0.3 and the latest JRE update
from Sun (1.5.0u8).
The error occures with a 512 MB PC, didn't see it happen on PCs with 1 GB.
regards
Christoph Lutz
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] how to reduce memory usage of unopkg
unopkg add ourUNOPackgage --shared So the failing unopkg add ourUNOPackgage --shared is for ourUNOPackgage == WollMux.uno.pkg, right? (Just asking because if the unopkg add consistently fails for that package, a unopkg list couldn't list it.) :) yes, the failing command is 'unopkg add WollMux.uno.pkg --shared', but the output of unopkg list is from a PC that has 1GB of memory which doesn't fail ;-) Do you have a stack trace of that Java OutOfMemoryError? unopkg does execute some code from the jar during registration, so this might shed some light on what is happening. Running in gdb: /opt/openoffice.org2.0/program/unopkg.bin add WollMux.uno.pkg ... . lots of undefined symbols follow (no debugging symbols found) ... /opt/openoffice.org2.0/program/uno.bin --quiet --singleaccept -u uno:pipe,name=284dada2fd8a4f5fcbb7897677e94c255 562e79b55472364126972d91b7e48;urp;uno.ComponentContext - -env:UNO_SERVICES=file:///opt/openoffice.org2.0/program/s ervices.rdb -env:INIFILENAME= ... . some more undef syms ... terminate called after throwing an instance of 'std::bad_alloc' what(): St9bad_alloc Program received signal SIGABRT, Aborted. [Switching to Thread -1542403152 (LWP 15636)] 0xa775a83b in raise () from /lib/tls/libc.so.6 (gdb) bt #0 0xa775a83b in raise () from /lib/tls/libc.so.6 #1 0xa775bfa2 in abort () from /lib/tls/libc.so.6 #2 0xa793bad1 in __gnu_cxx::__verbose_terminate_handler () from /opt/openoffice.org2.0/program/libstdc++.so.6 #3 0xa7939505 in __cxa_call_unexpected () from /opt/openoffice.org2.0/program/libstdc++.so.6 #4 0xa7939542 in std::terminate () from /opt/openoffice.org2.0/program/libstdc++.so.6 #5 0xa79396d2 in __cxa_throw () from /opt/openoffice.org2.0/program/libstdc++.so.6 #6 0x080595f0 in boost::detail::sp_counted_base_implrtl::Bootstrap*, boost::checked_deleterrtl::Bootstrap : :~sp_counted_base_impl () #7 0x08059620 in operator new () #8 0xa7d15ce2 in typelib_typedescriptionreference_getDescription () from /opt/openoffice.org2.0/program/libuno_cppu.so.3 #9 0xa413ef42 in component_canUnload () from /opt/openoffice.org2.0/program/liburp_uno.so #10 0xa413f07d in component_canUnload () from /opt/openoffice.org2.0/program/liburp_uno.so #11 0xa41318d5 in component_canUnload () from /opt/openoffice.org2.0/program/liburp_uno.so #12 0xa7d5a577 in osl_yieldThread () from /opt/openoffice.org2.0/program/libuno_sal.so.3 - ---Type return to continue, or q return to quit--- #13 0xa7a3ab63 in start_thread () from /lib/tls/libpthread.so.0 #14 0xa780a18a in clone () from /lib/tls/libc.so.6 ATB Christoph Lutz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] how to reduce memory usage of unopkg
Christoph Lutz wrote: unopkg add ourUNOPackgage --shared So the failing unopkg add ourUNOPackgage --shared is for ourUNOPackgage == WollMux.uno.pkg, right? (Just asking because if the unopkg add consistently fails for that package, a unopkg list couldn't list it.) :) yes, the failing command is 'unopkg add WollMux.uno.pkg --shared', but the output of unopkg list is from a PC that has 1GB of memory which doesn't fail ;-) Do you have a stack trace of that Java OutOfMemoryError? unopkg does execute some code from the jar during registration, so this might shed some light on what is happening. Running in gdb: /opt/openoffice.org2.0/program/unopkg.bin add WollMux.uno.pkg ... . lots of undefined symbols follow (no debugging symbols found) ... /opt/openoffice.org2.0/program/uno.bin --quiet --singleaccept -u uno:pipe,name=284dada2fd8a4f5fcbb7897677e94c255 562e79b55472364126972d91b7e48;urp;uno.ComponentContext - -env:UNO_SERVICES=file:///opt/openoffice.org2.0/program/s ervices.rdb -env:INIFILENAME= ... . some more undef syms ... terminate called after throwing an instance of 'std::bad_alloc' what(): St9bad_alloc So it is a C++ out-of-memory condition, not a Java-related one. It might be the included WollMux.rdb that triggers this, but its hard to say without further information. If you have a self-built OOo, you could try re-debugging with a non-stripped libuno_cppu.so.3, or with one built afresh with debug=x (module cppu). -Stephan Program received signal SIGABRT, Aborted. [Switching to Thread -1542403152 (LWP 15636)] 0xa775a83b in raise () from /lib/tls/libc.so.6 (gdb) bt #0 0xa775a83b in raise () from /lib/tls/libc.so.6 #1 0xa775bfa2 in abort () from /lib/tls/libc.so.6 #2 0xa793bad1 in __gnu_cxx::__verbose_terminate_handler () from /opt/openoffice.org2.0/program/libstdc++.so.6 #3 0xa7939505 in __cxa_call_unexpected () from /opt/openoffice.org2.0/program/libstdc++.so.6 #4 0xa7939542 in std::terminate () from /opt/openoffice.org2.0/program/libstdc++.so.6 #5 0xa79396d2 in __cxa_throw () from /opt/openoffice.org2.0/program/libstdc++.so.6 #6 0x080595f0 in boost::detail::sp_counted_base_implrtl::Bootstrap*, boost::checked_deleterrtl::Bootstrap : :~sp_counted_base_impl () #7 0x08059620 in operator new () #8 0xa7d15ce2 in typelib_typedescriptionreference_getDescription () from /opt/openoffice.org2.0/program/libuno_cppu.so.3 #9 0xa413ef42 in component_canUnload () from /opt/openoffice.org2.0/program/liburp_uno.so #10 0xa413f07d in component_canUnload () from /opt/openoffice.org2.0/program/liburp_uno.so #11 0xa41318d5 in component_canUnload () from /opt/openoffice.org2.0/program/liburp_uno.so #12 0xa7d5a577 in osl_yieldThread () from /opt/openoffice.org2.0/program/libuno_sal.so.3 - ---Type return to continue, or q return to quit--- #13 0xa7a3ab63 in start_thread () from /lib/tls/libpthread.so.0 #14 0xa780a18a in clone () from /lib/tls/libc.so.6 ATB Christoph Lutz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] how to reduce memory usage of unopkg
Christoph Lutz wrote: So it is a C++ out-of-memory condition, not a Java-related one. It might be the included WollMux.rdb that triggers this, but its hard to say without further information. If you have a self-built OOo, you could try re-debugging with a non-stripped libuno_cppu.so.3, or with one built afresh with debug=x (module cppu). thanks! we currently don't have got a self-build OOo, so we will see what we can do to give more information. Is there anything besides that meanwhile might help to find the cause? Do you think splitting the content of the package in two packages could help? that shouldn't be necessary, more interesting is the question why the memory consumption is so high. You can try to deploy the rdb file alone and if the memory consumption is still so high it would make sense if you can provide your type library for further investigation. Make sure that your type library contains only your own new IDL types. Juergen regards, Christoph - 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]
