GNOME.org
 

Gtkmm-forge Digest, Vol 23, Issue 8

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-owner 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. Do not try to unsubscribe gtkmm-forge from gtkmm-list.


Today's Topics:

   1. [Bug 512348] Glib::Thread::create() does not	appear to be
      thread safe (glibmm (bugzilla.gnome.org))
   2. [Bug 512348] Glib::Thread::create() does not	appear to be
      thread safe (glibmm (bugzilla.gnome.org))
   3. [Bug 512348] Glib::Thread::create() does not	appear to be
      thread safe (glibmm (bugzilla.gnome.org))
   4. [Bug 512348] Glib::Thread::create() does not	appear to be
      thread safe (glibmm (bugzilla.gnome.org))
   5. [Bug 529496] New: Compilation failure in	gnome-system-monitor
      because of HOST_NOT_FOUND (glibmm (bugzilla.gnome.org))
   6. [Bug 529496] Compilation failure in	gnome-system-monitor
      because of HOST_NOT_FOUND (glibmm (bugzilla.gnome.org))


----------------------------------------------------------------------

Message: 1
Date: Sun, 20 Apr 2008 17:53:16 +0000 (UTC)
From: "glibmm (bugzilla.gnome.org)"
	<bugzilla-daemon bugzilla gnome org>
Subject: [gtkmm bugzilla] [Bug 512348] Glib::Thread::create() does not
	appear to be thread safe
To: gtkmm-forge lists sourceforge net
Message-ID: <20080420175316 BAD5323F501 label gnome org>
Content-Type: text/plain; charset=utf-8

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=512348

  glibmm | threads | Ver: 2.14.x

Jonathon Jongsma (jonner) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jonathon quotidian org




------- Comment #3 from Jonathon Jongsma (jonner)  2008-04-20 17:53 UTC -------
Just to help me understand this bug report, have you ever actually seen this
issue manifest itself in a program, or is this mostly theoretical at the
moment?


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=512348.



------------------------------

Message: 2
Date: Sun, 20 Apr 2008 20:12:39 +0000 (UTC)
From: "glibmm (bugzilla.gnome.org)"
	<bugzilla-daemon bugzilla gnome org>
Subject: [gtkmm bugzilla] [Bug 512348] Glib::Thread::create() does not
	appear to be thread safe
To: gtkmm-forge lists sourceforge net
Message-ID: <20080420201239 D0A9923F510 label gnome org>
Content-Type: text/plain; charset=utf-8

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=512348

  glibmm | threads | Ver: 2.14.x




------- Comment #4 from Chris Vine  2008-04-20 20:12 UTC -------
Short explanation:

No, it's not theoretical.  It involves undefined behaviour (according to POSIX)
and like most thread unsafe code the occasions of failure will be infrequent,
random and difficult to attribute to any particular code path.

It arises because on slot construction the list object maintained by the
underlying sigc::trackable object is manipulated, and the same object is
manipulated in a different thread on slot destruction without memory
synchronisation.

If the thread function is to continue to be passed as a sigc::slot object, the
best course is to document that the slot shouldn't represent a non-static
method of a class object derived from sigc::trackable.  In the long term, the
solution is to pass the callback by something like boost::function (or the
callback object referred to in bug #396958).

Long explanation:

Libsigc++ advertises that if a slot created via sigc::mem_fun represents a
non-static method of a class object derived from sigc::trackable, the slot will
automatically be invalidated and disconnected if that object is destroyed.

I have verified empirically that that is the case.  It would be achieved on
slot creation by a call to sigc::trackable::add_destroy_notify_callback() to
register the slot with the relevant sigc::trackable target object belonging to
the object whose method is bound to the slot.  That function manipulates the
std::list<sigc::trackable_callback> object held by the sigc::trackable object's
sigc::trackable_callback_list member (it adds the relevant trackable_callback
to the list using std::list<sigc::trackable_callback>::push_back()).  On slot
destruction the reverse would happen - a call would be made to
sigc::trackable::remove_destroy_notify_callback(), which removes the relevant
trackable_callback from the list by calling
std::list<sigc::trackable_callback>::erase().

The "may" in the title arises from the fact that I have not been able to
penetrate the sigc++ code to identify the code path through which the calls to
sigc::trackable::add_destroy_notify_callback()/remove_destroy_notify_callback()
are made.  However, as I say, I have established empirically that automatic
slot disconnection does occur.  According to POSIX (and also Windows for those
using that OS), modifying a memory location in two different threads, or
modifying it in one and reading it in another, without synchronisation gives
rise to undefined behaviour.

Chris


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=512348.



------------------------------

Message: 3
Date: Tue, 22 Apr 2008 03:07:52 +0000 (UTC)
From: "glibmm (bugzilla.gnome.org)"
	<bugzilla-daemon bugzilla gnome org>
Subject: [gtkmm bugzilla] [Bug 512348] Glib::Thread::create() does not
	appear to be thread safe
To: gtkmm-forge lists sourceforge net
Message-ID: <20080422030752 D9D7823F829 label gnome org>
Content-Type: text/plain; charset=utf-8

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=512348

  glibmm | threads | Ver: 2.14.x




------- Comment #5 from Jonathon Jongsma (jonner)  2008-04-22 03:07 UTC -------
My use of the word 'theoretical' was not intended to be pejorative.  I was just
curious about whether you started this analysis because you noticed a program
behaving strangely, or whether you discovered this issue just by examining
code.  

I understand most of what you've said here fairly well.  The thing that's not
completely clear to me yet is what situations are vulnerable and what
situations are not vulnerable.  

I had originally understood the problem to only affect classes who have a bound
member used as a thread creation slot and then also have other members bound to
other slots.  But your comment #2 above suggests that this may actually be a
problem for any thread creation slot that is bound to a member function of a
sigc::trackable object regardless of whether additional slots are bound to
other member functions or not.  And if I understand your analysis, it seems
correct to me, though it seems unlikely to affect anything other than *very*
short thread functions.

So it appears that the 'safe' situations are the following:
- using static and standalone functions
- member functions of objects that do not derive from sigc::trackable
- member functions of sigc::trackable objects that are relatively long-running
and you never bind another member to a slot

Does this sound correct to you?


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=512348.



------------------------------

Message: 4
Date: Tue, 22 Apr 2008 20:46:33 +0000 (UTC)
From: "glibmm (bugzilla.gnome.org)"
	<bugzilla-daemon bugzilla gnome org>
Subject: [gtkmm bugzilla] [Bug 512348] Glib::Thread::create() does not
	appear to be thread safe
To: gtkmm-forge lists sourceforge net
Message-ID: <20080422204633 7AA0A23F01F label gnome org>
Content-Type: text/plain; charset=utf-8

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=512348

  glibmm | threads | Ver: 2.14.x




------- Comment #6 from Chris Vine  2008-04-22 20:46 UTC -------
Yes, I think that is a fair summary, although the third point hides a little
complexity.

For a fair non-summary on your third point, we both accept that if a std::list
object can be manipulated (pushed onto, popped from or examined by eg a call to
std::list<>::front()) by more than one thread without synchronisation then in
due course it will reach an invalid state (empirical evidence suggests that the
first time it seriously blows up will be when you are demonstrating your
program to a prospective client).  Each std::trackable object contains a
std::list object containing destroy notify callbacks.  New destroy notify
callbacks appear to be pushed, and old ones popped, whenever a new slot
referencing a non-static method of the object deriving from sigc::trackable is
created or deleted.

Therefore, we would be OK in the case of a non-static thread method of an
object deriving from sigc::trackable if:

(a) when Glib::Thread::create() is called and until the temporary bound to the
Glib::Thread::create() function by the call to sigc::mem_fun has been
destroyed, no other thread could create a new slot referencing a non-static
method (any non-static method, not just the thread function) of that object
until memory has re-synchronised, the object containing the std::list object
remains in existence until that time, and no other slot previously bound to a
non-static method of that object is destroyed in another thread until that
time[1], which is an unknown time in the absence of specific synchronisation to
deal with the point, but your "relatively long-running" addresses this; and

(b) there is no unsynchronised memory affecting the std::list object (by the
creation or deletion of any other slot objects or the going out of existence of
the object containing the std::list object) when the slot copied in
Glib::Thread::create() is later deleted in a different thread in
call_thread_entry_slot().

What this really shows is that because libsigc++ is not thread safe (nor in my
opinion should it be), it is not the right tool for this particular job.  It is
however the right tool for many other jobs.

[1] Including the slot object deleted in call_thread_entry_slot() in the new
thread.


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=512348.



------------------------------

Message: 5
Date: Wed, 23 Apr 2008 08:13:45 +0000 (UTC)
From: "glibmm (bugzilla.gnome.org)"
	<bugzilla-daemon bugzilla gnome org>
Subject: [gtkmm bugzilla] [Bug 529496] New: Compilation failure in
	gnome-system-monitor because of HOST_NOT_FOUND
To: gtkmm-forge lists sourceforge net
Message-ID: <bug-529496-5595 http bugzilla gnome org/>
Content-Type: text/plain; charset=utf-8

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=529496

  glibmm | io | Ver: 2.16.x
           Summary: Compilation failure in gnome-system-monitor because of
                    HOST_NOT_FOUND
           Product: glibmm
           Version: 2.16.x
          Platform: Other
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: critical
          Priority: Normal
         Component: io
        AssignedTo: gtkmm-forge lists sourceforge net
        ReportedBy: vuntz gnome org
         QAContact: gtkmm-forge lists sourceforge net
     GNOME version: Unspecified
   GNOME milestone: Unspecified


Smoketesting GNOME 2.23.1.

Compiling gnome-system-monitor 2.22.1 with gtkmm 2.13.0 (and glibmm 2.16.2), I
get this compilation failure:

if g++ -DHAVE_CONFIG_H -I. -I. -I..
-DPROCMAN_DATADIR=\""/gnome/releases/usr/share/procman/"\"
-DGNOMELOCALEDIR=\""/gnome/releases/usr/share/locale"\"
-DDATADIR=\""/gnome/releases/usr/share"\" -DORBIT2=1 -pthread
-I/gnome/releases/usr/include/glib-2.0
-I/gnome/releases/usr/lib/glib-2.0/include
-I/gnome/releases/usr/include/gconf/2 -I/gnome/releases/usr/include/orbit-2.0
-I/gnome/releases/usr/include/libgtop-2.0
-I/gnome/releases/usr/include/libwnck-1.0
-I/gnome/releases/usr/include/pango-1.0 -I/gnome/releases/usr/include/cairo
-I/gnome/releases/usr/include/startup-notification-1.0
-I/gnome/releases/usr/include/gtk-2.0 -I/gnome/releases/usr/include
-I/gnome/releases/usr/include/pixman-1
-I/gnome/releases/usr/lib/gtk-2.0/include -I/gnome/releases/usr/include/atk-1.0
-I/gnome/releases/usr/include/gnome-vfs-2.0
-I/gnome/releases/usr/lib/gnome-vfs-2.0/include
-I/gnome/releases/usr/include/gtkmm-2.4
-I/gnome/releases/usr/lib/gtkmm-2.4/include
-I/gnome/releases/usr/include/glibmm-2.4
-I/gnome/releases/usr/lib/glibmm-2.4/include
-I/gnome/releases/usr/include/giomm-2.4
-I/gnome/releases/usr/lib/giomm-2.4/include
-I/gnome/releases/usr/include/gdkmm-2.4
-I/gnome/releases/usr/lib/gdkmm-2.4/include
-I/gnome/releases/usr/include/pangomm-1.4
-I/gnome/releases/usr/include/atkmm-1.6
-I/gnome/releases/usr/include/sigc++-2.0
-I/gnome/releases/usr/lib/sigc++-2.0/include
-I/gnome/releases/usr/include/cairomm-1.0 -I/gnome/releases/usr/include/libxml2
-I/gnome/releases/usr/include/librsvg-2 -I/usr/include/freetype2
-I/usr/include/libpng12      -Wall -std=c++98 -g -O2 -MT callbacks.o -MD -MP
-MF ".deps/callbacks.Tpo" -c -o callbacks.o callbacks.cpp; \
        then mv -f ".deps/callbacks.Tpo" ".deps/callbacks.Po"; else rm -f
".deps/callbacks.Tpo"; exit 1; fi
In file included from /gnome/releases/usr/include/giomm-2.4/giomm/file.h:39,
                 from /gnome/releases/usr/include/giomm-2.4/giomm/mount.h:29,
                 from /gnome/releases/usr/include/giomm-2.4/giomm/drive.h:28,
                 from /gnome/releases/usr/include/giomm-2.4/giomm.h:30,
                 from /gnome/releases/usr/include/gtkmm-2.4/gtkmm.h:30,
                 from procman.h:23,
                 from callbacks.h:25,
                 from callbacks.cpp:27:
/gnome/releases/usr/include/giomm-2.4/giomm/error.h:72: error: expected
identifier before numeric constant
/gnome/releases/usr/include/giomm-2.4/giomm/error.h:72: error: expected `}'
before numeric constant
/gnome/releases/usr/include/giomm-2.4/giomm/error.h:72: error: expected
unqualified-id before numeric constant
/gnome/releases/usr/include/giomm-2.4/giomm/error.h:77: error: expected `)'
before ?error_code?
/gnome/releases/usr/include/giomm-2.4/giomm/error.h:78: error: expected `)'
before ?*? token
/gnome/releases/usr/include/giomm-2.4/giomm/error.h:79: error: ?Code? does
not name a type
/gnome/releases/usr/include/giomm-2.4/giomm/error.h:82: error: expected
unqualified-id before ?private?
/gnome/releases/usr/include/giomm-2.4/giomm/error.h:85: error: ?friend?
used outside of class
/gnome/releases/usr/include/giomm-2.4/giomm/error.h:96: error: expected
declaration before ?}? token
make: *** [callbacks.o] Erreur 1


The problem seems to be that HOST_NOT_FOUND in giomm/error.h is defined to 1 in
netdb.h.


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=529496.



------------------------------

Message: 6
Date: Wed, 23 Apr 2008 08:15:23 +0000 (UTC)
From: "glibmm (bugzilla.gnome.org)"
	<bugzilla-daemon bugzilla gnome org>
Subject: [gtkmm bugzilla] [Bug 529496] Compilation failure in
	gnome-system-monitor because of HOST_NOT_FOUND
To: gtkmm-forge lists sourceforge net
Message-ID: <20080423081523 4B23323F544 label gnome org>
Content-Type: text/plain; charset=utf-8

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=529496

  glibmm | io | Ver: 2.16.x




------- Comment #1 from Vincent Untz  2008-04-23 08:15 UTC -------
The workaround for GNOME 2.23.1 might simply be to release with gtkmm 2.12.x,
since it won't bring the giomm headers in during the compilation. But that's
still an issue for the future.


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=529496.



------------------------------

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

------------------------------

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


End of Gtkmm-forge Digest, Vol 23, Issue 8
******************************************
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]