GNOME.org
 

[gtkmm] Gtkmm-forge digest, Vol 1 #343 - 11 msgs

Send Gtkmm-forge mailing list submissions to
	gtkmm-forge lists sourceforge net

To subscribe or unsubscribe via the World Wide Web, visit
	https://lists.sourceforge.net/lists/listinfo/gtkmm-forge
or, via email, send a message with subject or body 'help' to
	gtkmm-forge-request lists sourceforge net

You can reach the person managing the list at
	gtkmm-forge-admin lists sourceforge net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Gtkmm-forge digest..."


gtkmm-forge is the mailing list that receives gtkmm bug reports from bugzilla.  A daily digest is sent to gtkmm-main, to encourage people to help fixing the bugs.


Today's Topics:

   1. [Bug 104181] Changed - Example segfaults after some time (bugzilla-daemon widget gnome org)
   2. [Bug 104181] Changed - Example segfaults after some time (bugzilla-daemon widget gnome org)
   3. [Bug 104181] Changed - Example segfaults after some time (bugzilla-daemon widget gnome org)
   4. [Bug 104332] Changed - Make RefPtr<> a general-purpose smart pointer (bugzilla-daemon widget gnome org)
   5. [Bug 104332] Changed - Make RefPtr<> a general-purpose smart pointer (bugzilla-daemon widget gnome org)
   6. [Bug 104332] Changed - Make RefPtr<> a general-purpose smart pointer (bugzilla-daemon widget gnome org)
   7. [Bug 104332] Changed - Make RefPtr<> a general-purpose smart pointer (bugzilla-daemon widget gnome org)
   8. [Bug 104332] Changed - Make RefPtr<> a general-purpose smart pointer (bugzilla-daemon widget gnome org)
   9. [Bug 101878] Changed - Glib::RefPtr<> should have operator*() (bugzilla-daemon widget gnome org)
  10. [Bug 86864] Changed - enums should be inside classes. (bugzilla-daemon widget gnome org)
  11. [Bug 85911] Changed - Gdk::Drawable::draw_*_image functions (bugzilla-daemon widget gnome org)

--__--__--

Message: 1
From: bugzilla-daemon widget gnome org
To: gtkmm-forge lists sourceforge net
Cc: 
Date: Mon, 27 Jan 2003 16:12:48 -0500 (EST)
Subject: [gtkmm bugzilla] [Bug 104181] Changed - Example segfaults after some time

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

http://bugzilla.gnome.org/show_bug.cgi?id=104181

Changed by olau hardworking dk 

--- shadow/104181	Wed Jan 22 15:46:19 2003
+++ shadow/104181.tmp.32707	Mon Jan 27 16:12:48 2003
@@ -41,6 +41,38 @@
 #12 0x40120924 in Gtk::Main::run_impl () from /usr/lib/libgtkmm-2.0.so.1
 #13 0x401207a5 in Gtk::Main::run () from /usr/lib/libgtkmm-2.0.so.1
 #14 0x0804dcbb in main (argc=1, argv=0xbffff9e4) at main.cc:33
 
 I'm experiencing the same problem in my own application with spinbuttons -
 random crashes after changing the values a few times.
+
+------- Additional Comments From olau hardworking dk  2003-01-27 16:12 -------
+I've run the example with Electric Fence enabled. It seems to crash
+the program consistently when working with a hash table:
+
+#0  0x408aa254 in strcmp () from /lib/libc.so.6
+#1  0x40739cd1 in g_str_equal () from /usr/lib/libglib-2.0.so.0
+#2  0x4071ecc9 in g_hash_table_destroy () from /usr/lib/libglib-2.0.so.0
+#3  0x4071ed50 in g_hash_table_lookup () from /usr/lib/libglib-2.0.so.0
+#4  0x40627c75 in gconf_client_value_changed () from
+/usr/lib/libgconf-2.so.4
+#5  0x406283e5 in gconf_client_change_set_from_current ()
+   from /usr/lib/libgconf-2.so.4
+#6  0x40628242 in gconf_client_change_set_from_current ()
+   from /usr/lib/libgconf-2.so.4
+#7  0x40729756 in g_timeout_add () from /usr/lib/libglib-2.0.so.0
+#8  0x407270b9 in g_get_current_time () from /usr/lib/libglib-2.0.so.0
+#9  0x40727e5f in g_main_context_dispatch () from
+/usr/lib/libglib-2.0.so.0
+#10 0x40728233 in g_main_context_dispatch () from
+/usr/lib/libglib-2.0.so.0
+#11 0x4072890f in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
+#12 0x4036871f in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
+#13 0x4015314e in Gtk::Main::run_impl() () from /usr/lib/libgtkmm-2.0.so.1
+#14 0x40152fed in Gtk::Main::run(Gtk::Window&) ()
+   from /usr/lib/libgtkmm-2.0.so.1
+#15 0x0804e049 in main (argc=2, argv=0xbffff994) at main.cc:33
+
+I have no idea whether this really is related to the bug though. I
+also don't quite understand the stack trace since g_hash_table_lookup
+doesn't seem to be calling g_hash_table_destroy at all in
+glib/ghash.c. Perhaps it is just a really nasty memory bug.



--__--__--

Message: 2
From: bugzilla-daemon widget gnome org
To: gtkmm-forge lists sourceforge net
Cc: 
Date: Mon, 27 Jan 2003 17:21:10 -0500 (EST)
Subject: [gtkmm bugzilla] [Bug 104181] Changed - Example segfaults after some time

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

http://bugzilla.gnome.org/show_bug.cgi?id=104181

Changed by olau hardworking dk 

--- shadow/104181	Mon Jan 27 16:12:48 2003
+++ shadow/104181.tmp.4623	Mon Jan 27 17:21:10 2003
@@ -73,6 +73,56 @@
 #15 0x0804e049 in main (argc=2, argv=0xbffff994) at main.cc:33
 
 I have no idea whether this really is related to the bug though. I
 also don't quite understand the stack trace since g_hash_table_lookup
 doesn't seem to be calling g_hash_table_destroy at all in
 glib/ghash.c. Perhaps it is just a really nasty memory bug.
+
+------- Additional Comments From olau hardworking dk  2003-01-27 17:21 -------
+I've found the bug. In gconf/gconfmm/callback.cc there is the function:
+
+void CallbackHolder::call(GConfClient* client, guint i, GConfEntry*
+pEntry, void* data)
+{
+  if(data)
+    ((CallbackHolder*)data)->m_Slot (i, Entry (pEntry));
+}
+
+If the contents is #if'ed out, I can't reproduce the bug:
+
+void CallbackHolder::call(GConfClient* client, guint i, GConfEntry*
+pEntry, void* data)
+{
+#if 0
+  if(data)
+    ((CallbackHolder*)data)->m_Slot (i, Entry (pEntry));
+#endif
+}
+
+If, however, the entry is still created, I can reproduce it:
+
+void CallbackHolder::call(GConfClient* client, guint i, GConfEntry*
+pEntry, void* data)
+{
+  Entry e(pEntry);
+#if 0
+  if(data)
+    ((CallbackHolder*)data)->m_Slot (i, Entry (pEntry));
+#endif
+}
+
+I've looked at the definition of Entry. It seems Entry(pEntry) assumes
+ that the constructor is given a copy of the C object. But the
+reference on GConf says:
+
+  GConfClientNotifyFunc ()
+  ...  The value argument should not be modified, and should be
+  copied if you want to keep it around (the GConfClient will
+  destroy it sometime after your notify function is called).
+
+So Entry(pEntry) should be Entry(pEntry, true). Is it customary that
+values in gtkmm don't need to be copied? It seems unsafe to use a
+default argument here, when the risk is memory corruption.
+
+I'm attaching a patch. Since the bug renders gconfmm almost completely
+ unusable with spinbuttons, I think it might be a good idea to release
+a new version.



--__--__--

Message: 3
From: bugzilla-daemon widget gnome org
To: gtkmm-forge lists sourceforge net
Cc: 
Date: Mon, 27 Jan 2003 17:22:05 -0500 (EST)
Subject: [gtkmm bugzilla] [Bug 104181] Changed - Example segfaults after some time

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

http://bugzilla.gnome.org/show_bug.cgi?id=104181

Changed by olau hardworking dk 

--- shadow/104181	Mon Jan 27 17:21:10 2003
+++ shadow/104181.tmp.5106	Mon Jan 27 17:22:05 2003
@@ -123,6 +123,11 @@
 values in gtkmm don't need to be copied? It seems unsafe to use a
 default argument here, when the risk is memory corruption.
 
 I'm attaching a patch. Since the bug renders gconfmm almost completely
  unusable with spinbuttons, I think it might be a good idea to release
 a new version.
+
+------- Additional Comments From olau hardworking dk  2003-01-27 17:22 -------
+Created an attachment (id=13862)
+Patch of gconfmm/ChangeLog and gconfmm/gconf/gconfmm/callback.cc
+



--__--__--

Message: 4
From: bugzilla-daemon widget gnome org
To: gtkmm-forge lists sourceforge net, michaelj maine rr com
Cc: 
Date: Mon, 27 Jan 2003 18:26:49 -0500 (EST)
Subject: [gtkmm bugzilla] [Bug 104332] Changed - Make RefPtr<> a general-purpose smart pointer

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

http://bugzilla.gnome.org/show_bug.cgi?id=104332

Changed by murrayc usa net 

--- shadow/104332	Mon Jan 27 14:56:14 2003
+++ shadow/104332.tmp.7874	Mon Jan 27 18:26:49 2003
@@ -93,6 +93,12 @@
 
 The reason why it seems complex, perhaps, is that the Glib::ObjectBase
 implementation is doing the necessary work to hide the complexity of
 the GTK+ reference counting implementation. To the end user, things
 are simpler and more consistent because they don't have to worry about
 the eccentric GTK+ behavior.
+
+------- Additional Comments From murrayc usa net  2003-01-27 18:26 -------
+Why did you remove the cpp_destruction_in_progress_ bool and checks?
+
+Have you tried all the tests and the gtk-demo? Do they run and quit
+without warnings or segfaults?



--__--__--

Message: 5
From: bugzilla-daemon widget gnome org
To: gtkmm-forge lists sourceforge net, michaelj maine rr com
Cc: 
Date: Mon, 27 Jan 2003 19:02:58 -0500 (EST)
Subject: [gtkmm bugzilla] [Bug 104332] Changed - Make RefPtr<> a general-purpose smart pointer

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

http://bugzilla.gnome.org/show_bug.cgi?id=104332

Changed by murrayc usa net 

--- shadow/104332	Mon Jan 27 18:26:49 2003
+++ shadow/104332.tmp.26006	Mon Jan 27 19:02:58 2003
@@ -99,6 +99,11 @@
 
 ------- Additional Comments From murrayc usa net  2003-01-27 18:26 -------
 Why did you remove the cpp_destruction_in_progress_ bool and checks?
 
 Have you tried all the tests and the gtk-demo? Do they run and quit
 without warnings or segfaults?
+
+------- Additional Comments From murrayc usa net  2003-01-27 19:02 -------
+Why did you also make Glib::MainContext inherit from GMainContext?
+Along with all the irrelevant or trivial documentation and other
+changes it is very hard to process this patch.



--__--__--

Message: 6
From: bugzilla-daemon widget gnome org
To: gtkmm-forge lists sourceforge net
Cc: 
Date: Mon, 27 Jan 2003 20:41:43 -0500 (EST)
Subject: [gtkmm bugzilla] [Bug 104332] Changed - Make RefPtr<> a general-purpose smart pointer

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

http://bugzilla.gnome.org/show_bug.cgi?id=104332

Changed by michaelj maine rr com 

--- shadow/104332	Mon Jan 27 19:02:58 2003
+++ shadow/104332.tmp.3169	Mon Jan 27 20:41:43 2003
@@ -104,6 +104,26 @@
 without warnings or segfaults?
 
 ------- Additional Comments From murrayc usa net  2003-01-27 19:02 -------
 Why did you also make Glib::MainContext inherit from GMainContext?
 Along with all the irrelevant or trivial documentation and other
 changes it is very hard to process this patch.
+
+------- Additional Comments From michaelj maine rr com  2003-01-27 20:41 -------
+I've tried all the examples and the gtk-demo. Yes, they run with no
+warnings or segfaults.
+
+The cpp_destruction_in_progress got moved (and shortened to
+in_destructor) into Gtk::Object since that is the only place it is
+actually set. I provided an accessor function (is_in_destructor) for
+testing the value. It is tested in widget.ccg, as it was before.
+
+As for the comments and documentation, the idea was to fully document
+all of what I was doing for future reference, rather than going for a
+smaller patch and making things harder for someone to figure out later.
+
+As to the Glib::MainContext inheriting from GMainContext, it neatly
+avoids using reinterpret_cast, a construct which Stroustrup considers
+highly undesirable. It also, in my opinion, makes it clearer that
+Glib::MainContext is pretending to be a GMainContext. The same is true
+of Glib::MainLoop. Neither of these is actually wrapping the GLib
+objects, they are extending them.



--__--__--

Message: 7
From: bugzilla-daemon widget gnome org
To: gtkmm-forge lists sourceforge net, michaelj maine rr com
Cc: 
Date: Tue, 28 Jan 2003 04:47:36 -0500 (EST)
Subject: [gtkmm bugzilla] [Bug 104332] Changed - Make RefPtr<> a general-purpose smart pointer

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

http://bugzilla.gnome.org/show_bug.cgi?id=104332

Changed by murrayc usa net 

--- shadow/104332	Mon Jan 27 20:41:43 2003
+++ shadow/104332.tmp.24890	Tue Jan 28 04:47:36 2003
@@ -124,6 +124,11 @@
 As to the Glib::MainContext inheriting from GMainContext, it neatly
 avoids using reinterpret_cast, a construct which Stroustrup considers
 highly undesirable. It also, in my opinion, makes it clearer that
 Glib::MainContext is pretending to be a GMainContext. The same is true
 of Glib::MainLoop. Neither of these is actually wrapping the GLib
 objects, they are extending them.
+
+------- Additional Comments From murrayc usa net  2003-01-28 04:47 -------
+Created an attachment (id=13875)
+glibmm_object.patch
+



--__--__--

Message: 8
From: bugzilla-daemon widget gnome org
To: gtkmm-forge lists sourceforge net, michaelj maine rr com
Cc: 
Date: Tue, 28 Jan 2003 04:48:58 -0500 (EST)
Subject: [gtkmm bugzilla] [Bug 104332] Changed - Make RefPtr<> a general-purpose smart pointer

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

http://bugzilla.gnome.org/show_bug.cgi?id=104332

Changed by murrayc usa net 

--- shadow/104332	Tue Jan 28 04:47:36 2003
+++ shadow/104332.tmp.25393	Tue Jan 28 04:48:58 2003
@@ -129,6 +129,11 @@
 objects, they are extending them.
 
 ------- Additional Comments From murrayc usa net  2003-01-28 04:47 -------
 Created an attachment (id=13875)
 glibmm_object.patch
 
+
+------- Additional Comments From murrayc usa net  2003-01-28 04:48 -------
+This patch, glibmm_object.patch, simplifies things a bit and shows
+just the lifecycle changes, though it also moves some methods around
+without changing them.



--__--__--

Message: 9
From: bugzilla-daemon widget gnome org
To: gtkmm-forge lists sourceforge net
Cc: 
Date: Tue, 28 Jan 2003 08:05:39 -0500 (EST)
Subject: [gtkmm bugzilla] [Bug 101878] Changed - Glib::RefPtr<> should have operator*()

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

http://bugzilla.gnome.org/show_bug.cgi?id=101878

Changed by murrayc usa net 

--- shadow/101878	Thu Jan 23 14:24:11 2003
+++ shadow/101878.tmp.23459	Tue Jan 28 08:05:39 2003
@@ -1,19 +1,19 @@
 Bug#: 101878
-Product: gtkmm
-Version: 2.4
+Product: glibmm
+Version: 2.4.x
 OS: All
 OS Details: 
 Status: NEW   
 Resolution: 
 Severity: enhancement
 Priority: Normal
-Component: general
+Component: object
 AssignedTo: gtkmm-forge lists sourceforge net                            
 ReportedBy: daniel elstner gmx net               
-TargetMilestone: 3
+TargetMilestone: ---
 URL: 
 Summary: Glib::RefPtr<> should have operator*()
 
 I think we should reconsider the decision to omit operator*() at the next
 API/ABI break.  Not being able to use Glib::RefPtr<> with
 Gtk::Object-derived classes is an awkward inconsistency.
@@ -24,6 +24,12 @@
 
 2. You still need to give an example of when it would be necessary or
 useful. I wouldn't want to add the confusion without gaining anything.
 
 ------- Additional Comments From murrayc usa net  2003-01-22 18:29 -------
 I still have no answers to these questions.
+
+------- Additional Comments From murrayc usa net  2003-01-28 08:05 -------
+I don't see any use for this until we can use RefPtr with
+Gtk::Object-derived classes. Apparently the problem with that is that
+the Gtk::Object can be destroyed even when there are outstanding
+references.



--__--__--

Message: 10
From: bugzilla-daemon widget gnome org
To: gtkmm-forge lists sourceforge net
Cc: 
Date: Tue, 28 Jan 2003 08:06:45 -0500 (EST)
Subject: [gtkmm bugzilla] [Bug 86864] Changed - enums should be inside classes.

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

http://bugzilla.gnome.org/show_bug.cgi?id=86864

Changed by murrayc usa net 

--- shadow/86864	Thu Jan 23 14:22:36 2003
+++ shadow/86864.tmp.23877	Tue Jan 28 08:06:45 2003
@@ -41,6 +41,10 @@
 Partially fixed, by using different variable names in enums.m4, but we
 still need some way to place the enum's operator overloads outside of
 the class, while having the enums inside the class.
 
 ------- Additional Comments From murrayc usa net  2002-07-26 11:29 -------
 Punting, because it's difficult to implement.
+
+------- Additional Comments From murrayc usa net  2003-01-28 08:06 -------
+If someone can provide some example C++ code (maybe a patch of 
+generated .h/.cc files) then we might be able to implement this.



--__--__--

Message: 11
From: bugzilla-daemon widget gnome org
To: gtkmm-forge lists sourceforge net, osamyn ulb ac be
Cc: 
Date: Tue, 28 Jan 2003 08:13:17 -0500 (EST)
Subject: [gtkmm bugzilla] [Bug 85911] Changed - Gdk::Drawable::draw_*_image functions

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

http://bugzilla.gnome.org/show_bug.cgi?id=85911

Changed by murrayc usa net 

--- shadow/85911	Thu Jan 23 14:22:16 2003
+++ shadow/85911.tmp.27385	Tue Jan 28 08:13:17 2003
@@ -157,6 +157,9 @@
  That's only inconvenient in most cases.  You can always do:
 
   &vector.front()
 
 to get a builtin array.
 
+
+------- Additional Comments From murrayc usa net  2003-01-28 08:13 -------
+Does anyone still care about this?




--__--__--

_______________________________________________
Gtkmm-forge mailing list
Gtkmm-forge lists sourceforge net
https://lists.sourceforge.net/lists/listinfo/gtkmm-forge


End of Gtkmm-forge Digest
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]