Version: (using Devel) Installed from: Compiled sources Compiler: gcc 4.3.1 OS: Linux The problem is, Umbrello hangs on start, eating all available memory. The systems becomes unusable if I don't kill it before it eats whole swap space (the system has 2 GB of RAM + 2 GB of swap; probably need to switch on OOM killer so that it could be killed automatically). I've seen this before, maybe twice or 3 time, restarting whole system usually helped, but now I see it almost every time I try to start Umbrello. I've tried deleting/moving config files (umbrellorc, umbrelloui.rc), to see if the problem is in that, but that didn't help. That was Debian experimental version, then I've compiled fresh SVN version and seen the same thing. Then I've tried to catch the region of obvious endless loop present here: (gdb) bt #0 0x00007f4c4a16df03 in memcpy () from /lib/libc.so.6 #1 0x00007f4c4ac973c5 in QString::append (this=0x2a72678, str=@0x7fff56174a00) at tools/qstring.cpp:1277 #2 0x000000000054dabe in CodeGenerationPolicy::calculateIndentation (this=<value optimized out>) at /usr/include/qt4/QtCore/qstring.h:261 #3 0x000000000054dc26 in CodeGenerationPolicy::setIndentationType (this=0x2a72660, new_var=CodeGenerationPolicy::SPACE) at /home/rik/deb/umbrello/umbrello/codegenerators/codegenerationpolicy.cpp:252 #4 0x000000000054dcb9 in CodeGenerationPolicy::setDefaults (this=0x2a72660, emitUpdateSignal=false) at /home/rik/deb/umbrello/umbrello/codegenerators/codegenerationpolicy.cpp:415 #5 0x000000000054e21e in CodeGenerationPolicy (this=0x2a72660) at /home/rik/deb/umbrello/umbrello/codegenerators/codegenerationpolicy.cpp:48 #6 0x0000000000c1ca46 in UMLApp (this=0x2871ec0, parent=<value optimized out>) at /home/rik/deb/umbrello/umbrello/uml.cpp:161 #7 0x0000000000bd4582 in main (argc=1, argv=0x7fff56175078) at /home/rik/deb/umbrello/umbrello/main.cpp:95 Another one: (gdb) bt #0 0x000000000054dac9 in CodeGenerationPolicy::calculateIndentation (this=<value optimized out>) at /home/rik/deb/umbrello/umbrello/codegenerators/codegenerationpolicy.cpp:301 #1 0x000000000054dc26 in CodeGenerationPolicy::setIndentationType (this=0x1d38660, new_var=CodeGenerationPolicy::SPACE) at /home/rik/deb/umbrello/umbrello/codegenerators/codegenerationpolicy.cpp:252 #2 0x000000000054dcb9 in CodeGenerationPolicy::setDefaults (this=0x1d38660, emitUpdateSignal=false) at /home/rik/deb/umbrello/umbrello/codegenerators/codegenerationpolicy.cpp:415 #3 0x000000000054e21e in CodeGenerationPolicy (this=0x1d38660) at /home/rik/deb/umbrello/umbrello/codegenerators/codegenerationpolicy.cpp:48 #4 0x0000000000c1ca46 in UMLApp (this=0x1b37ec0, parent=<value optimized out>) at /home/rik/deb/umbrello/umbrello/uml.cpp:161 #5 0x0000000000bd4582 in main (argc=1, argv=0x7fff5d14ca18) at /home/rik/deb/umbrello/umbrello/main.cpp:95 Then some info from valgrind (the program was TERMinated by hand): ==26361== ERROR SUMMARY: 31074154 errors from 1 contexts (suppressed: 11 from 2) ==26361== ==26361== 31074154 errors in context 1 of 1: ==26361== Conditional jump or move depends on uninitialised value(s) ==26361== at 0x54DACF: CodeGenerationPolicy::calculateIndentation() (codegenerationpolicy.cpp:301) ==26361== by 0x54DC25: CodeGenerationPolicy::setIndentationType(CodeGenerationPolicy::IndentationType) (codegenerationpolicy.cpp:252) ==26361== by 0x54DCB8: CodeGenerationPolicy::setDefaults(bool) (codegenerationpolicy.cpp:415) ==26361== by 0x54E21D: CodeGenerationPolicy::CodeGenerationPolicy() (codegenerationpolicy.cpp:48) ==26361== by 0xC1CA45: UMLApp::UMLApp(QWidget*) (uml.cpp:161) ==26361== by 0xBD4581: main (main.cpp:95) --26361-- --26361-- supp: 3 X on SUSE11 writev uninit padding --26361-- supp: 8 dl-hack3-cond-1 ==26361== ==26361== IN SUMMARY: 31074154 errors from 1 contexts (suppressed: 11 from 2) ==26361== ==26361== malloc/free: in use at exit: 69,879,442 bytes in 24,598 blocks. ==26361== malloc/free: 101,285 allocs, 76,687 frees, 185,180,176 bytes allocated. ==26361== ==26361== searching for pointers to 24,598 not-freed blocks. ==26361== checked 86,618,848 bytes. The thing is, something like 1 from 10 starts sucseeds (the system is dual-core, BTW).
BTW, I'd ran valgrind with "--leak-check=yes" and now without it, it gives a bit more info while app is trying to start, lots of things like: ==17594== Invalid read of size 1 ==17594== at 0x7EB2AD0: QMetaObject::checkConnectArgs(char const*, char const*) (qmetaobject.cpp:720) ==17594== by 0x7EBD329: QObject::connect(QObject const*, char const*, QObject const*, char const*, Qt::ConnectionType) (qobject.cpp:2420) ==17594== by 0xC1D21F: UMLApp::setProgLangAction(Uml::Programming_Language, QString const&, QString const&) (uml.cpp:188) ==17594== by 0xC2092A: UMLApp::initActions() (uml.cpp:270) ==17594== by 0xC24F90: UMLApp::UMLApp(QWidget*) (uml.cpp:133) ==17594== by 0xBD4A01: main (main.cpp:95) ==17594== Address 0xf17b721 is 25 bytes inside a block of size 46 free'd ==17594== at 0x4C20B6E: free (vg_replace_malloc.c:323) ==17594== by 0xC1D244: UMLApp::setProgLangAction(Uml::Programming_Language, QString const&, QString const&) (qbytearray.h:370) ==17594== by 0xC2092A: UMLApp::initActions() (uml.cpp:270) ==17594== by 0xC24F90: UMLApp::UMLApp(QWidget*) (uml.cpp:133) ==17594== by 0xBD4A01: main (main.cpp:95) ==17594== ==17594== Invalid read of size 1 ==17594== at 0x7EB2AD9: QMetaObject::checkConnectArgs(char const*, char const*) (qmetaobject.cpp:720) ==17594== by 0x7EBD329: QObject::connect(QObject const*, char const*, QObject const*, char const*, Qt::ConnectionType) (qobject.cpp:2420) ==17594== by 0xC1D21F: UMLApp::setProgLangAction(Uml::Programming_Language, QString const&, QString const&) (uml.cpp:188) ==17594== by 0xC2092A: UMLApp::initActions() (uml.cpp:270) ==17594== by 0xC24F90: UMLApp::UMLApp(QWidget*) (uml.cpp:133) ==17594== by 0xBD4A01: main (main.cpp:95) ==17594== Address 0xf17b723 is 27 bytes inside a block of size 46 free'd ==17594== at 0x4C20B6E: free (vg_replace_malloc.c:323) ==17594== by 0xC1D244: UMLApp::setProgLangAction(Uml::Programming_Language, QString const&, QString const&) (qbytearray.h:370) ==17594== by 0xC2092A: UMLApp::initActions() (uml.cpp:270) ==17594== by 0xC24F90: UMLApp::UMLApp(QWidget*) (uml.cpp:133) ==17594== by 0xBD4A01: main (main.cpp:95) Maybe it is related to this bug.
Yay. Sorry for confusing, but last comment applies to 4.1.0 Debian experimental umbrello. The one I've built from SVN doesn't show any of those.
Quick fix by commit 846608 in file codegenerationpolicy.cpp:301 The variable Settings::getOptionState().codeGenerationState.indentationAmount seems not to be initialized properly and has sometimes a very high value. Will be investigated further.
Built rev. 846610 several days ago, no hangs from that time, it's something like 20 starts. But as a side-effect I also can't see any language in "Code -> Active Language" menu and autocompletition of types for new attributes doesn't work (I guess because of lack of the language).
> [...] > But as a side-effect I also can't see any language in "Code -> Active > Language" menu and autocompletition of types for new attributes doesn't > work (I guess because of lack of the language). Do you have a recent umbrelloui.rc in your $KDEDIR/share/apps/umbrello/ ?
> Do you have a recent umbrelloui.rc in your $KDEDIR/share/apps/umbrello/ ? What do you mean by 'recent'? Currently there is no such file there at all.
> > Do you have a recent umbrelloui.rc in your $KDEDIR/share/apps/umbrello/ ? > > What do you mean by 'recent'? Currently there is no such file there at all. ?? Well that's very strange. If you start umbrello from an xterm command line then you should see something like: umbrello(10436)/kdeui (kdelibs): No such XML file "umbrelloui.rc" Then try copying the umbrelloui.rc file from your umbrello trunk checkout to the install directory mentioned above.
OK, my error here, I've interpreted $KDEDIR as ~/.kde4, but looks like you've ment something like /usr/share/kde4/ (Debian case), where I do have /usr/share/kde4/apps/umbrello/umbrelloui.rc. So now I understand what you've ment by 'recent', as I've rewrited that with umbrelloui.rc from current SVN and voila, language selection works again.
Not observed any more since commit 846608.