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]
Hi !
It looks like your wxWidgets release is too old.
You should search the forum for your assertion for a more details.
Dje
I have simillar beaviour, fresh svn checkout, fresh wx 2.6.7 build.
Call stack:
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:
#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
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:
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:
#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.
With this patch the segfault when closing codeblocks goes away:
--- 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
{
I have the same problem in my ThreadSearch plugin; the logger is deleted in the call to
CodeBlocksDockEvent evt(cbEVT_REMOVE_DOCK_WINDOW);
evt.pWindow = m_pListLog->GetWindow();
The debugger code makes a 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
Quote from: jens on December 01, 2007, 09:22:01 PM
With this patch the segfault when closing codeblocks goes away:
--- 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.
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
QuoteI 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:
QuoteSetLog() 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.
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.next.codeblocks.org/index.php/topic,7252.new.html)
Dje