Code::Blocks Forums

Developer forums (C::B DEVELOPMENT STRICTLY!) => Development => Topic started by: nothing on November 30, 2007, 10:32:47 pm

Title: codeblocks configuration not saved
Post by: nothing on November 30, 2007, 10:32:47 pm
first of all: sorry for my english
second: thanks for this piece of software, great work!

i try to compile codeblocks (for the first time) from svn, precisely on 29.11.07 and 30.11.07
it compile fine, and codeblocks start and work without problem. but when i close it segfault
looking at the console output, right after the start:

########
(codeblocks:32339): Gtk-CRITICAL **: gtk_window_realize_icon: assertion `info->icon_pixmap == NULL' failed
########

and closing it:

########
Deinitializing plugins...
sh: -c: line 0: syntax error near unexpected token `('
sh: -c: line 0: `addr2line -C -f -e "/usr/bin/codeblocks" 0xb6cab223 0xffffe420 0xb72b046a (nil)'
Segmentation fault
########

im using gtk-2.10.13, and if can help i've attached the entire log

note: i've tried to look at the "svn know issues" page, but it seems that i can't read it

[attachment deleted by admin]
Title: Re: codeblocks configuration not saved
Post by: dje on November 30, 2007, 11:49:37 pm
Hi !

It looks like your wxWidgets release is too old.
You should search the forum for your assertion for a more details.

Dje
Title: Re: codeblocks configuration not saved
Post by: byo on December 01, 2007, 12:00:12 am
I have simillar beaviour, fresh svn checkout, fresh wx 2.6.7 build.

Call stack:

Code
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1233844544 (LWP 3259)]
0xb6ab453c in vtable for std::bad_typeid () from /usr/lib/libstdc++.so.6
(gdb) bt
#0  0xb6ab453c in vtable for std::bad_typeid () from /usr/lib/libstdc++.so.6
#1  0xb6e42b3c in wxAppBase::SendIdleEvents () from /usr/local/lib/libwx_gtk2u_core-2.8.so.0
#2  0xb6e42b0f in wxAppBase::SendIdleEvents () from /usr/local/lib/libwx_gtk2u_core-2.8.so.0
#3  0xb6e42b0f in wxAppBase::SendIdleEvents () from /usr/local/lib/libwx_gtk2u_core-2.8.so.0
#4  0xb6e42e3b in wxAppBase::ProcessIdle () from /usr/local/lib/libwx_gtk2u_core-2.8.so.0
#5  0xb6d960ff in wxapp_idle_callback () from /usr/local/lib/libwx_gtk2u_core-2.8.so.0
#6  0xb77e9551 in ?? () from /usr/lib/libglib-2.0.so.0
#7  0x00000000 in ?? ()
(gdb)

After running few times the trace always goes through wxAppBase::SendIdleEvents, the topmost frame can be also:
Code
#0  0xb6a1550d in vtable for __cxxabiv1::__class_type_info () from /usr/lib/libstdc++.so.6

Also it looks like there's no difference between closing C::B right after opening it or closing C::B with some project opened.

BYO
Title: Re: codeblocks configuration not saved
Post by: Jenna on December 01, 2007, 10:29:13 am
Quote from: byo on December 01, 2007, 12:00:12 am
I have simillar beaviour, fresh svn checkout, fresh wx 2.6.7 build.

Call stack:

Code
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1233844544 (LWP 3259)]
0xb6ab453c in vtable for std::bad_typeid () from /usr/lib/libstdc++.so.6
(gdb) bt
#0  0xb6ab453c in vtable for std::bad_typeid () from /usr/lib/libstdc++.so.6
#1  0xb6e42b3c in wxAppBase::SendIdleEvents () from /usr/local/lib/libwx_gtk2u_core-2.8.so.0
#2  0xb6e42b0f in wxAppBase::SendIdleEvents () from /usr/local/lib/libwx_gtk2u_core-2.8.so.0
#3  0xb6e42b0f in wxAppBase::SendIdleEvents () from /usr/local/lib/libwx_gtk2u_core-2.8.so.0
#4  0xb6e42e3b in wxAppBase::ProcessIdle () from /usr/local/lib/libwx_gtk2u_core-2.8.so.0
#5  0xb6d960ff in wxapp_idle_callback () from /usr/local/lib/libwx_gtk2u_core-2.8.so.0
#6  0xb77e9551 in ?? () from /usr/lib/libglib-2.0.so.0
#7  0x00000000 in ?? ()
(gdb)

After running few times the trace always goes through wxAppBase::SendIdleEvents, the topmost frame can be also:
Code
#0  0xb6a1550d in vtable for __cxxabiv1::__class_type_info () from /usr/lib/libstdc++.so.6

Also it looks like there's no difference between closing C::B right after opening it or closing C::B with some project opened.

BYO

I think you mean 2.8.7 .

Seems to be a problem with the ToDo-List plugin.

I disabled all plugins and then reenabled them.
Everyone works fine, except for the ToDo-List plugin.
If I enable it and the close C::B, it causes a segfault, and the ToDo-List plugin stays disabled.
Title: Re: codeblocks configuration not saved
Post by: Jenna on December 01, 2007, 09:22:01 pm
With this patch the segfault when closing codeblocks goes away:

Code
--- codeblocks-1.0svn.orig/src/plugins/todo/todolist.cpp        2007-11-28 06:16:23.000000000 +0100
+++ codeblocks-1.0svn.work/src/plugins/todo/todolist.cpp        2007-12-01 21:17:28.000000000 +0100
@@ -142,7 +142,7 @@
         CodeBlocksDockEvent evt(cbEVT_REMOVE_DOCK_WINDOW);
         evt.pWindow = m_pListLog->GetWindow();
         Manager::Get()->ProcessEvent(evt);
-        delete m_pListLog;
+//        delete m_pListLog;
     }
     else
     {
Title: Re: codeblocks configuration not saved
Post by: dje on December 01, 2007, 09:29:31 pm
I have the same problem in my ThreadSearch plugin; the logger is deleted in the call to
Code
CodeBlocksDockEvent evt(cbEVT_REMOVE_DOCK_WINDOW);
 evt.pWindow = m_pListLog->GetWindow();

The debugger code makes a
Code
m_pLog = 0;
just after.
I am working on a workaround that should work tonight if you need to keep your graphical widget when removing the logger.

Dje
Title: Re: codeblocks configuration not saved
Post by: killerbot on December 02, 2007, 02:53:02 pm
Quote from: jens on December 01, 2007, 09:22:01 pm
With this patch the segfault when closing codeblocks goes away:

Code
--- codeblocks-1.0svn.orig/src/plugins/todo/todolist.cpp        2007-11-28 06:16:23.000000000 +0100
+++ codeblocks-1.0svn.work/src/plugins/todo/todolist.cpp        2007-12-01 21:17:28.000000000 +0100
@@ -142,7 +142,7 @@
         CodeBlocksDockEvent evt(cbEVT_REMOVE_DOCK_WINDOW);
         evt.pWindow = m_pListLog->GetWindow();
         Manager::Get()->ProcessEvent(evt);
-        delete m_pListLog;
+//        delete m_pListLog;
     }
     else
     {

Yes, I can confirm this. That ugly crash is gone now. Confirmed on 2 windows CB equipped machines.
Title: Re: codeblocks configuration not saved
Post by: nothing on December 02, 2007, 03:52:08 pm
Quote from: killerbot on December 02, 2007, 02:53:02 pm

Quote from: jens on December 01, 2007, 09:22:01 pm

With this patch the segfault when closing codeblocks goes away:

Yes, I can confirm this. That ugly crash is gone now. Confirmed on 2 windows CB equipped machines.

me too, it work! thanks a lot, im falling in love for CB
Title: Re: codeblocks configuration not saved
Post by: thomas on December 02, 2007, 04:09:06 pm
Quote
I am working on a workaround that should work tonight if you need to keep your graphical widget when removing the logger.
That shouldn't be needed. When you unload a plugin, there is no reason to keep a GUI widget around.

When the plugin is loaded again, you can create a new object. Yiannis added a message which allows you to do just that.
Personally, I don't like it, because I think that this whole loading/unloading on the fly makes everything needlessly complicated and error-prone, and there is in my opinion nothing wrong if plugins (and their loggers) are only loaded at application startup. However, the functionality is there, and the message to add logs during runtime is there too and it works, so well... there's no real reason not to use it.

Besides,  a workaround to keep the graphical widget would only work accidentially because PluginManager to time does not work properly. When PluginManager "loads" a plugin, the plugin really has been loaded ages ago, and when it "unloads" a plugin, nothing is unloaded at all. Loading and unloading is about setting up a few functors properly, and unsetting them. It's quite complicated alltogether, for example the plugin object is created via a static global variable which you could call kind of a "factory template" (which is initialised at DLL load time). This is to make sure that there is a function that "knows" the proper type of the object to be created so it can be created/destroyed correctly (the application only knows the base class). The downside of this is, of course, that we have no real control about when something is created/destroyed, but a better implementation is a lot more complicated.
Anyway, if the load/unload functionality is ever implemented correctly, your "keep the GUI" workaround would mean to keep (and reference) an object that is inside a library which is no longer mapped to memory. I am quite sure this would crash and burn.

The problem of the above crash lies in improper API use (albeit in good intention), which could have been avoided by reading the comments in logmanager.h:
Quote
SetLog() transfers ownership of the Logger object to the LogManager.
Why does it have to be like this? Simple: You can replace one Logger with another Logger at any time. In this case, output will be redirected to the new Logger, and the old one will be deleted by the LogManager.
For example, if you wanted to write an add-on which redirects the debug log to a file, you would only need a single line of code which adds a FileLogger into the debug log's slot. The application (and the plugins) using the debug log would never know that anything has changed.
Title: Re: codeblocks configuration not saved
Post by: dje on December 02, 2007, 05:12:06 pm
There won't be any workaround.
In fact, all the changes are made on the fly and don't depend on loading/unloading of the plugin.
All is detailed in the other thread (http://forums.codeblocks.org/index.php/topic,7252.new.html)

Dje