Version: 0.5.3 (using KDE KDE 3.1.4) Installed from: FreeBSD Ports OS: FreeBSD My Atlantik crashes or closes when I---or my opponent---try to start a new game. I tried deinstalling and compiling it again, and it gives me the same problem. Is there anything else I could do to remedy this?
Subject: Re: [atlantik-devel] New: Atlantik closes when game starts On Fri, Oct 24, 2003 at 12:14:23PM -0000, puffdaddy@uh-huh-yeah.org wrote: > My Atlantik crashes or closes when I---or my opponent---try to start a new game. I tried deinstalling and compiling it again, and it gives me the same problem. Is there anything else I could do to remedy this? When it crashes, could you send a backtrace? (--enable-debug in the compilation should enable that) Rob
I'm not sure how much of it I should paste. addToken jumpToken to Go processing msg: <monopd><display estateid="-1" text="" cleartext="0" clearbutton s="0"/></monopd> AtlantikBoard::slotResizeAftermath jumpToken to Go jumpToken to Go processing msg: <monopd><gameupdate gameid="147" status="run"/></monopd> Alarm clock
I asked on #kde-freebsd: <lauri> Capzilla: tell him to recompile with less optimizations <lauri> it's a gcc bug <lauri> yup, it happens in some apps with -Otoomuch, and there's more info in the kde-freebsd list archives somewhere Let me know if that helps..
<lauri> Capzilla: it's -funroll-loops I think, rather than -Otoomuch
It worked fine when I had it in KDE 3.1.2 The portbuild for 3.1.4 installed this new one [I think]. I then downloaded it and had it installed [locally] and it still gives me the same problem. I'm not sure how to reoptimize this.
I've been able to reproduce this actually, with a Qt 3.1 / kdelibs 3_1_BRANCH and Atlantik HEAD combo.. added some debug info but the recompile might take some time..
Do you happen to use gcc 2.95.x? (it's the only build platform I've been able to get similar problems with)
For some reason this error (can) occur when Atlantik::m_selectConfiguration is deleted to be replaced by either the board in Atlantik::showBoard() or the select game widget in Atlantik::showSelectGame(). Removing the "delete m_selectConfiguration" statement(s) should be a work-around. Perhaps this should be deleteLater, although the alarm clock seems to occur in the middle of the delete (the destructor is called succesfully) and not at a later reference of the object. I can reproduce this with a gcc-2.95.3 compiled Atlantik against HEAD KDE (both with and without -O2), but not with gcc-3.2 which I use at home.
bash-2.05b$ gcc -v Using builtin specs. gcc version 2.95.4 20020320 [FreeBSD] I also have gcc33 installed bash-2.05b$ gcc33 -v Reading specs from /usr/local/lib/gcc-lib/i386-portbld-freebsd4.9/3.3.3/specs Configured with: ./..//gcc-3.3-20031103/configure --disable-nls --with-gxx-include-dir=/usr/local/lib/gcc-lib/i386-portbld-freebsd4.9/3.3.3/include/c++/ --with-system-zlib --disable-shared --prefix=/usr/local i386-portbld-freebsd4.9 Thread model: posix gcc version 3.3.3 20031103 (prerelease) [FreeBSD] I'm not sure why I have two of them. If 2.95.4 is the reason why it craps out on me, do I have to make 3.3.3 my primary build platform? [If I do, how would I go about that?]
Subject: Re: [atlantik-devel] Atlantik closes when game starts On Mon, Nov 10, 2003 at 05:48:41PM -0000, Jeremy wrote: > I'm not sure why I have two of them. If 2.95.4 is the reason why it craps > out on me, do I have to make 3.3.3 my primary build platform? [If I do, > how would I go about that?] Oh, I was just writing down differences in builds at home (where I can't reproduce) and work (where I can, but I did have a somewhat broken kdebase build). Despite valgrinding I haven't figured out what exactly goes wrong.. I get the same valgrind error but can't yet point it to something I did wrong.. ;-) ==4785== ==4785== Invalid read of size 4 ==4785== at 0x40F19BE8: QBoxLayoutItem::~QBoxLayoutItem() (kernel/qlayout.cpp:1519) ==4785== by 0x40F19DBC: QPtrList<QBoxLayoutItem>::deleteItem(void*) (../include/qptrlist.h:150) ==4785== by 0x411EFF4E: QGList::clear() (tools/qglist.cpp:701) ==4785== by 0x40F19D81: QPtrList<QBoxLayoutItem>::clear() (../include/qptrlist.h:93) ==4785== Address 0x45B03390 is 40 bytes inside a block of size 92 free'd ==4785== at 0x400289FA: __builtin_delete (vg_replace_malloc.c:244) ==4785== by 0x40028A18: operator delete(void*) (vg_replace_malloc.c:253) ==4785== by 0x40F179E9: QHBoxLayout::~QHBoxLayout() (kernel/qlayout.cpp:2509) ==4785== by 0x40F19BF5: QBoxLayoutItem::~QBoxLayoutItem() (kernel/qlayout.cpp:1519) ==4785== ==4785== Invalid write of size 4 ==4785== at 0x40EC4373: QLayoutItem::~QLayoutItem() (kernel/qabstractlayout.cpp:207) ==4785== by 0x40F19BF5: QBoxLayoutItem::~QBoxLayoutItem() (kernel/qlayout.cpp:1519) ==4785== by 0x40F19DBC: QPtrList<QBoxLayoutItem>::deleteItem(void*) (../include/qptrlist.h:150) ==4785== by 0x411EFF4E: QGList::clear() (tools/qglist.cpp:701) ==4785== Address 0x45B03390 is 40 bytes inside a block of size 92 free'd ==4785== at 0x400289FA: __builtin_delete (vg_replace_malloc.c:244) ==4785== by 0x40028A18: operator delete(void*) (vg_replace_malloc.c:253) ==4785== by 0x40F179E9: QHBoxLayout::~QHBoxLayout() (kernel/qlayout.cpp:2509) ==4785== by 0x40F19BF5: QBoxLayoutItem::~QBoxLayoutItem() (kernel/qlayout.cpp:1519) ==4785== ==4785== Invalid free() / delete / delete[] ==4785== at 0x400289FA: __builtin_delete (vg_replace_malloc.c:244) ==4785== by 0x40028A18: operator delete(void*) (vg_replace_malloc.c:253) ==4785== by 0x40EC438B: QLayoutItem::~QLayoutItem() (kernel/qabstractlayout.cpp:208) ==4785== by 0x40F19BF5: QBoxLayoutItem::~QBoxLayoutItem() (kernel/qlayout.cpp:1519) ==4785== Address 0x45B03390 is 40 bytes inside a block of size 92 free'd ==4785== at 0x400289FA: __builtin_delete (vg_replace_malloc.c:244) ==4785== by 0x40028A18: operator delete(void*) (vg_replace_malloc.c:253) ==4785== by 0x40F179E9: QHBoxLayout::~QHBoxLayout() (kernel/qlayout.cpp:2509) ==4785== by 0x40F19BF5: QBoxLayoutItem::~QBoxLayoutItem() (kernel/qlayout.cpp:1519) Rob
Created attachment 3131 [details] Patch against HEAD Please try this patch, it does remove the Valgrind warning for me so I'm hopeful it does some good. I set a parent layout for some boxes and then explicitely added them to the parent again, not sure why I ever thought that'd make sense.
Patch fixes the problem on the only machine where I've been able to reproduce, closing. Committed to HEAD (KDE 3.2 / A 0.6.0) and backported to branch (KDE 3.1.x / A 0.5.x).