Code::Blocks Forums

Developer forums (C::B DEVELOPMENT STRICTLY!) => Development => Topic started by: Der Meister on December 28, 2005, 06:20:21 pm

Title: Problem when closing Code::Blocks - 100% CPU Load
Post by: Der Meister on December 28, 2005, 06:20:21 pm
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 ()
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 ()
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.
Title: Re: Problem when closing Code::Blocks - 100% CPU Load
Post by: thomas on December 28, 2005, 06:53:12 pm
Quote
that is just a (wxWidgets?)-macro
IMPLEMENT_DYNAMIC_CLASS... the antichrist.

Quote
I didn't look at propgrid.cpp:2164 but the problem seems to be there.
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?
Title: Re: Problem when closing Code::Blocks - 100% CPU Load
Post by: Der Meister on December 28, 2005, 07:16:38 pm
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...
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).
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?
I could try this but don't expect it to happen right now.  :?
Title: Re: Problem when closing Code::Blocks - 100% CPU Load
Post by: thomas on December 28, 2005, 07:35:00 pm
Quote from: Der Meister on December 28, 2005, 07:16:38 pm
Are there any variables/objects at global scope or static in wxPropGrid?
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...
Title: Re: Problem when closing Code::Blocks - 100% CPU Load
Post by: Der Meister on December 28, 2005, 07:58:04 pm
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)
Title: Re: Problem when closing Code::Blocks - 100% CPU Load
Post by: Der Meister on December 29, 2005, 01:12:00 pm
OK, now it gets really weird. With revision 1611 wxPropertyGrid moved to the sdk and wxSmith uses this one and not its own version. First, there are a few patches necessary to build revision 1612 with the Linux build system:
Code
$ svn diff src/plugins/contrib/wxSmith/
Index: src/plugins/contrib/wxSmith/defwidgets/Makefile.am
===================================================================
--- src/plugins/contrib/wxSmith/defwidgets/Makefile.am  (revision 1612)
+++ src/plugins/contrib/wxSmith/defwidgets/Makefile.am  (working copy)
@@ -1,7 +1,7 @@
 INCLUDES = $(WX_CXXFLAGS) \
                -I$(top_srcdir)/src/sdk \
                -I$(top_srcdir)/src/sdk/wxscintilla/include \
-               -I$(top_srcdir)/src/plugins/contrib/wxSmith/propgrid/include
+               -I$(top_srcdir)/src/sdk/propgrid/include
 
 noinst_LTLIBRARIES = libwxsmith_defwidgets.la
 
Index: src/plugins/contrib/wxSmith/properties/Makefile.am
===================================================================
--- src/plugins/contrib/wxSmith/properties/Makefile.am  (revision 1612)
+++ src/plugins/contrib/wxSmith/properties/Makefile.am  (working copy)
@@ -1,7 +1,7 @@
 INCLUDES = $(WX_CXXFLAGS) \
                -I$(top_srcdir)/src/sdk \
                -I$(top_srcdir)/src/sdk/wxscintilla/include \
-               -I$(top_srcdir)/src/plugins/contrib/wxSmith/propgrid/include
+               -I$(top_srcdir)/src/sdk/propgrid/include
 
 noinst_LTLIBRARIES = libwxsmith_properties.la
 
Index: src/plugins/contrib/wxSmith/resources/Makefile.am
===================================================================
--- src/plugins/contrib/wxSmith/resources/Makefile.am   (revision 1612)
+++ src/plugins/contrib/wxSmith/resources/Makefile.am   (working copy)
@@ -1,7 +1,7 @@
 INCLUDES = $(WX_CXXFLAGS) \
                -I$(top_srcdir)/src/sdk \
                -I$(top_srcdir)/src/sdk/wxscintilla/include \
-               -I$(top_srcdir)/src/plugins/contrib/wxSmith/propgrid/include
+               -I$(top_srcdir)/src/sdk/propgrid/include
 
 noinst_LTLIBRARIES = libwxsmith_resources.la
With these patches everything compiles without problems. But the two problems I described in my first post came back again.  :?
Has anyone an idea what the reason for this is?

Edit:
OK, I have an explanation for this: Although the source-code is there only once now the wxPropGrid-lib is still linked twice. That is the real problem. I removed the library from the sdk (not the source but the commands for the linker to include it in libcodeblocks) and it works just perfect.
As long as wxPropertyGrid is only used by wxSmith this is no problem but as soon as the core-part uses it we have to link it to the sdk which will make this problems appear again. Thus it sould only be linked to the sdk and *not* to wxSmith - but is this possible? Maybe wxSmith should link to the sdk instead to wxPropertyGrid? Could this work?

Edit2: I just tested it and it seems to work. This patch makes wxSmith link against the sdk (which includes wxPropertyGrid) and not to wxPropertyGrid directly:
Code
$ svn diff src/plugins/contrib/wxSmith/Makefile.am 
Index: src/plugins/contrib/wxSmith/Makefile.am
===================================================================
--- src/plugins/contrib/wxSmith/Makefile.am     (revision 1612)
+++ src/plugins/contrib/wxSmith/Makefile.am     (working copy)
@@ -19,7 +19,7 @@
 
 libwxsmith_la_LIBADD = ../../../sdk/libcodeblocks.la \
                                ../../../sdk/wxscintilla/libwxscintilla.la \
-                               ../../../sdk/propgrid/libpropgrid.la \
+                               ../../../sdk/.libs/libcodeblocks.la \
                                defwidgets/libwxsmith_defwidgets.la \
                                properties/libwxsmith_properties.la \
                                resources/libwxsmith_resources.la
Title: Re: Problem when closing Code::Blocks - 100% CPU Load
Post by: grv575 on December 30, 2005, 02:27:55 am
Well if propgrid lib is in the sdk then:

../../../sdk/libcodeblocks.la \                       <-----------
../../../sdk/wxscintilla/libwxscintilla.la \
../../../sdk/propgrid/libpropgrid.la \              <----------

it already is linking against it twice...so just take out the libpropgrid.la link from wxsmith.
Title: Re: Problem when closing Code::Blocks - 100% CPU Load
Post by: Der Meister on December 30, 2005, 10:54:43 am
That is exactly what I recommended in my last post and mandrav applied this patch already in revision 1613.  8)