Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
Problem when closing Code::Blocks - 100% CPU Load
Der Meister:
I got a strange problem with revisions after 1600 (Linux, Unicode). When I exit Code::Blocks it seems to shutdown just as usual but the process doesn't terminate and even produce 100% CPU load. After killing and restarting it there is no message about "Removing the stale lock" or whatever. Thus, it seems as Code::Blocks did a normal shutdown but just before the process terminates it gets caught in an endless loop.
When running Code::Blocks with gdb and then doing a backtrace when it locks up I get the following results:
--- Code: ---Program received signal SIGINT, Interrupt.
[Switching to Thread 16384 (LWP 21836)]
0xb7571fa3 in wxClassInfo::~wxClassInfo () from /usr/lib/libwx_baseu-2.6.so.0
(gdb) bt
#0 0xb7571fa3 in wxClassInfo::~wxClassInfo ()
from /usr/lib/libwx_baseu-2.6.so.0
#1 0xb7c73410 in __tcf_3 () at wxscintilla.cpp:130
#2 0xb73d2d3e in __cxa_finalize () from /lib/libc.so.6
#3 0xb7c5ca93 in __do_global_dtors_aux ()
from /opt/codeblocks-cvs/lib/libwxscintilla.so.0
#4 0xb7d22636 in _fini () from /opt/codeblocks-cvs/lib/libwxscintilla.so.0
#5 0xb7ff6c25 in _dl_fini () from /lib/ld-linux.so.2
#6 0xb73d2af5 in exit () from /lib/libc.so.6
#7 0xb73bd525 in __libc_start_main () from /lib/libc.so.6
#8 0x08060cf1 in _start ()
--- End code ---
Seems to be rather strange because there is no Code::Blocks code involved. Only one line in wxscintilla is mentioned and that is just a (wxWidgets?)-macro.
And I don't think that it is a problem with my wxWGTK-installation because the problem did not occur with revision 1599 or 1600 and I didn't change anything after that. I tried even a fresh checkout from the svn and a clean rebuild but it didn't make any difference.
Did anyone notice similar problems or has an idea what the reason for this problem is?
Edit:
I tried a bit more. When I disable all plugins in revision 1609 and then restart and close Code::Blocks again it doesn't consume all CPU power - because it crashes:
--- Code: ---(gdb) r
Starting program: /opt/codeblocks-cvs/bin/codeblocks
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 22698)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 22698)]
0xb75bc8e7 in wxEventHashTable::~wxEventHashTable ()
from /usr/lib/libwx_baseu-2.6.so.0
(gdb) bt
#0 0xb75bc8e7 in wxEventHashTable::~wxEventHashTable ()
from /usr/lib/libwx_baseu-2.6.so.0
#1 0xb7f59460 in __tcf_1 () at propgrid.cpp:2164
#2 0xb73d2d3e in __cxa_finalize () from /lib/libc.so.6
#3 0xb7dcc703 in __do_global_dtors_aux ()
from /opt/codeblocks-cvs/lib/libcodeblocks.so.0
#4 0xb7f5b136 in _fini () from /opt/codeblocks-cvs/lib/libcodeblocks.so.0
#5 0xb7ff6c25 in _dl_fini () from /lib/ld-linux.so.2
#6 0xb73d2af5 in exit () from /lib/libc.so.6
#7 0xb73bd525 in __libc_start_main () from /lib/libc.so.6
#8 0x08060cf1 in _start ()
--- End code ---
I didn't look at propgrid.cpp:2164 but the problem seems to be there. And I would expect that the problem with the endless loop is also a problem related to wxPropGrid, although I have no proof for this yet.
Edit2:
I started adding plugins again. The result is: Without the wxSmith plugin Code::Blocks crashes (as described here) and with this plugin it gets locked up (as described as first issue in this post). The other plugins don't seem to have any influence on this.
thomas:
--- Quote ---that is just a (wxWidgets?)-macro
--- End quote ---
IMPLEMENT_DYNAMIC_CLASS... the antichrist.
--- Quote ---I didn't look at propgrid.cpp:2164 but the problem seems to be there.
--- End quote ---
wxPropGrid:2164: BEGIN_EVENT_TABLE(wxArrayEditorDialog, wxDialog).
Without this typical wxWidgets macro abuse, one would be able to tell what code is really executed... :(
Funny, you know.... wxPropGrid is not used in Code::Blocks at all. Even though the SDK links against it, there is not one single call to any of wxPropGrid's functions in the SVN version.
Plus, the sources are a 1:1 copy of wxSmith's wxPropGrid which has been working fine for many months.
EDIT:
One possible problem which I could think of is due to wxSmith having its own wxPropGrid... but then why would it crash without wxSmith? And if there was a conflict, it should give a link-time error, not run-time freezes...
EDIT 2:
Tried Windows XP / ANSI, works fine either way (with or without wxSmith).
Would you mind trying what happens if you recompile wxSmith, but remove libpropgrid.la from its project?
Der Meister:
--- Quote from: thomas on December 28, 2005, 06:53:12 pm ---One possible problem which I could think of is due to wxSmith having its own wxPropGrid... but then why would it crash without wxSmith? And if there was a conflict, it should give a link-time error, not run-time freezes...
--- End quote ---
Are there any variables/objects at global scope or static in wxPropGrid? This would at least explain the calls although wxProgGrid isn't used explicitly.
--- Quote from: thomas on December 28, 2005, 06:53:12 pm ---Tried Windows XP / ANSI, works fine either way (with or without wxSmith).
--- End quote ---
Well, then it seems to be a Linux/Unicode related problem only. Doesn't make it really better.
--- Quote from: thomas on December 28, 2005, 06:53:12 pm ---Would you mind trying what happens if you recompile wxSmith, but remove libpropgrid.la from its project?
--- End quote ---
I could try this but don't expect it to happen right now. :?
thomas:
--- Quote from: Der Meister on December 28, 2005, 07:16:38 pm ---Are there any variables/objects at global scope or static in wxPropGrid?
--- End quote ---
How would I know :P
Found some static const wxStrings and a couple of static global functions after some looking, as well as some evil preprocessor stuff involving static const wxChar*s and #ifdefed ##s which apparently do some obscure RTTI emulation or whatever...
I also downloaded a fresh copy of wxPropGrid (supposedly the exact same version), and it
a) is significantly different from our version
b) does not compile at all (many many errors about double definitions, static locals being dllimported, etc.)
Darn, wxPropertyGrid seems less attractive from moment to moment now...
Der Meister:
OK, new information:
It definitely is a conflict from the two wxPropGrids. I didn't manage to remove the libpropgrid.la from wxSmith because if it is missing the install script builds it again just before it is linked into the wxSmith plugin. But I took a fresh copy of revision 1609 and removed the wxPropGrig from the sdk (i. e. I removed the directory and the entries in the makefiles/configure-script for this). And guess what: It works just perfect. The crash and the lock-up are both gone. Seems as we discovered another portion of evil praeprocessor macros (this time from wxWidgtes, not our own). 8)
Navigation
[0] Message Index
[#] Next page
Go to full version