GNOME.org
 

Gtkmm-forge Digest, Vol 20, Issue 11

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 512403] libgnomeuimm (gentoo package) doesn't	compile
      with gcc-4.3 (gnomemm (bugzilla.gnome.org))
   2. [Bug 511972] glibmm doesn't have an AsyncQueue	class
      (glibmm (bugzilla.gnome.org))
   3. [Bug 511972] glibmm doesn't have an AsyncQueue	class
      (glibmm (bugzilla.gnome.org))
   4. [Bug 396958] Glib::signal_idle().connect() not	thread-safe
      (glibmm (bugzilla.gnome.org))
   5. [Bug 512441] New: Gdk::GC::create() - segmentation	fault
      (gtkmm (bugzilla.gnome.org))
   6. [Bug 512348] Glib::Thread::create() does not	appear to be
      thread safe (glibmm (bugzilla.gnome.org))
   7. [Bug 512441] Gdk::GC::create() - segmentation fault
      (gtkmm (bugzilla.gnome.org))


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

Message: 1
Date: Sun, 27 Jan 2008 18:07:23 +0000 (UTC)
From: "gnomemm (bugzilla.gnome.org)"
	<bugzilla-daemon bugzilla gnome org>
Subject: [gtkmm bugzilla] [Bug 512403] libgnomeuimm (gentoo package)
	doesn't	compile with gcc-4.3
To: gtkmm-forge lists sourceforge net
Message-ID: <20080127180723 EC2E123F590 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=512403

  gnomemm | libgnomeuimm | Ver: unspecified

Christian Persch (IRC: chpe) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|libgnomeui-maint gnome bugs |gtkmm-
                   |                            |forge lists sourceforge net
          Component|general                     |libgnomeuimm
            Product|libgnomeui                  |gnomemm
          QAContact|libgnomeui-maint gnome bugs |gtkmm-
                   |                            |forge lists sourceforge net
   Target Milestone|future                      |---
            Version|2.20.x                      |unspecified




------- Comment #2 from Christian Persch (IRC: chpe)  2008-01-27 18:07 UTC -------
Reassigning to the correct product.


-- 
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=512403.



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

Message: 2
Date: Sun, 27 Jan 2008 19:16:00 +0000 (UTC)
From: "glibmm (bugzilla.gnome.org)"
	<bugzilla-daemon bugzilla gnome org>
Subject: [gtkmm bugzilla] [Bug 511972] glibmm doesn't have an
	AsyncQueue	class
To: gtkmm-forge lists sourceforge net
Message-ID: <20080127191600 2E24723EF89 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=511972

  glibmm | threads | Ver: 2.15.x




------- Comment #7 from ecyrbe gmail com  2008-01-27 19:15 UTC -------
chris, i understand your point about stong exception safety, and the ones about
this class not being a wrapper but a try to map the interface of GAsyncAqueue
into a new c++ class.
I'let you decide whether this is usefull or not... i can make this
implementation exception safe, as far as i know, splitting pop into a front()
and a  pop() method without return value (as in the std::queue) would do the
job.
I can also translate and improve the documentation and make it formatted like
the one of glibmm.
Let me know what you decide...


-- 
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=511972.



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

Message: 3
Date: Sun, 27 Jan 2008 20:02:00 +0000 (UTC)
From: "glibmm (bugzilla.gnome.org)"
	<bugzilla-daemon bugzilla gnome org>
Subject: [gtkmm bugzilla] [Bug 511972] glibmm doesn't have an
	AsyncQueue	class
To: gtkmm-forge lists sourceforge net
Message-ID: <20080127200200 B84E723F541 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=511972

  glibmm | threads | Ver: 2.15.x




------- Comment #8 from chris cvine freeserve co uk  2008-01-27 20:01 UTC -------
No you can't do it as in std::queue because the call to front() and pop() have
to be done under a single lock atomically.  As I say, the best thing is to pass
the object to be extracted to a reference argument of the pop() method, not as
a return value.  That retains strong exception safety (the extraction either
succeeds, or the queue remains in its former condition) and thread safety.

I do not take any decisions on what goes into glibmm, that is for others. 
Glib::Dispatcher provides for event passing, so its main uses would be in
constructing event queues that a worker thread can wait on (which is one of the
main intended uses of GAsyncQueue), or for passing arguments to a method
invoked by Glib::Dispatcher.  For those purposes I think it would be quite
useful.  Blocking queues of this kind can also be used to make thread pools,
but glibmm already has those.  Few people writing threaded programs can do
without a thread safe queue, and most people will have something like yours in
their own library, so the question is whether it should go into glibmm.

If it were included there are a few suggestions of taste I would make - for
example I think it sensible to pass the container type as a second template
parameter with a default value, as in the case of std::queue (on what should be
the default value, there might be an argument in this use for std::list rather
than std::deque which std::queue uses by default).  In addition, I am not
certain I would cause try_pop() to give rise to an exception if the queue is
empty (it is not really an unexpected condition if try_pop() is being called). 
One approach is to have try_pop() return with a success/fail argument, and to
have two pop() methods, one which blocks on a condition variable if the queue
is empty (the present behaviour of your pop() method), and one which throws an
exception if it is empty as per std::queue.  I can see however where
GAsyncQueue took you, but perhaps we do not have to follow it.

You also don't need to count waiting threads to know whether to call
Glib::Cond::signal() - if nothing is waiting on the condition variable the call
to signal() will do nothing; however, perhaps you were doing it for some other
purpose.

Anyway, well done.


-- 
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=511972.



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

Message: 4
Date: Sun, 27 Jan 2008 20:11:53 +0000 (UTC)
From: "glibmm (bugzilla.gnome.org)"
	<bugzilla-daemon bugzilla gnome org>
Subject: [gtkmm bugzilla] [Bug 396958] Glib::signal_idle().connect()
	not	thread-safe
To: gtkmm-forge lists sourceforge net
Message-ID: <20080127201153 83F5723F591 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=396958

  glibmm | main loop | Ver: 2.13.x




------- Comment #6 from chris cvine freeserve co uk  2008-01-27 20:11 UTC -------
See also bug #512348

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=396958.



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

Message: 5
Date: Sun, 27 Jan 2008 20:21:44 +0000 (UTC)
From: "gtkmm (bugzilla.gnome.org)"
	<bugzilla-daemon bugzilla gnome org>
Subject: [gtkmm bugzilla] [Bug 512441] New: Gdk::GC::create() -
	segmentation	fault
To: gtkmm-forge lists sourceforge net
Message-ID: <bug-512441-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=512441

  gtkmm | general | Ver: 2.12.x
           Summary: Gdk::GC::create() - segmentation fault
           Product: gtkmm
           Version: 2.12.x
          Platform: Other
        OS/Version: All
            Status: UNCONFIRMED
          Severity: major
          Priority: Normal
         Component: general
        AssignedTo: gtkmm-forge lists sourceforge net
        ReportedBy: ghost99 mail ru
         QAContact: gtkmm-forge lists sourceforge net
     GNOME version: 2.19/2.20
   GNOME milestone: Unspecified


Please describe the problem:
Programs, that use Gdk::GC, are compiling well, but they are not work.

Steps to reproduce:
1. Copy code from below
2. g++ code.cc -o test `pkg-config gtkmm-2.4 --libs --cflags`
3. ./test
4. segmentation fault


Actual results:
gdb> r

Program received signal SIGSEGV, Segmentation fault.
_______________________________________________________________________________
     eax:BFAFF884 ebx:B7C67FF4  ecx:B7894FF4  edx:00000000     eflags:00210282
     esi:080A2698 edi:B7C66FB0  esp:BFAFF810  ebp:080A269C     eip:B7C4D7C9
     cs:0073  ds:007B  es:007B  fs:0000  gs:0033  ss:007B    o d I t S z a p c 
[007B:BFAFF810]---------------------------------------------------------[stack]
BFAFF840 : 98 26 0A 08  84 F8 AF BF - 80 F8 AF BF  5C BC 06 08 .&..........\...
BFAFF830 : 80 F8 AF BF  98 26 0A 08 - B8 F8 AF BF  73 D8 C4 B7 .....&......s...
BFAFF820 : B8 F8 AF BF  00 B0 F8 B7 - AC 26 0A 08  F4 7F C6 B7 .........&......
BFAFF810 : 9C 26 0A 08  C0 6F C6 B7 - 80 F8 AF BF  98 26 0A 08 .&...o.......&..
[007B:080A2698]---------------------------------------------------------[ data]
080A2698 : 50 91 4C B7  60 70 C6 B7 - 00 00 00 00  80 46 88 B7 P.L.`p.......F..
080A26A8 : 00 00 00 00  00 00 00 00 - 00 00 00 00  51 1F 00 00 ............Q...
[0073:B7C4D7C9]---------------------------------------------------------[ code]
0xb7c4d7c9 <_ZN3Gdk2GCC1ERKN4Glib6RefPtrINS_8DrawableEEE+67>:   mov   
(%edx),%eax
0xb7c4d7cb <_ZN3Gdk2GCC1ERKN4Glib6RefPtrINS_8DrawableEEE+69>:   mov   
-0xc(%eax),%eax
0xb7c4d7ce <_ZN3Gdk2GCC1ERKN4Glib6RefPtrINS_8DrawableEEE+72>:   mov   
0x4(%edx,%eax,1),%eax
0xb7c4d7d2 <_ZN3Gdk2GCC1ERKN4Glib6RefPtrINS_8DrawableEEE+76>:   mov   
%eax,(%esp)
0xb7c4d7d5 <_ZN3Gdk2GCC1ERKN4Glib6RefPtrINS_8DrawableEEE+79>:   call  
0xb7c42c30 <gdk_gc_new plt>
0xb7c4d7da <_ZN3Gdk2GCC1ERKN4Glib6RefPtrINS_8DrawableEEE+84>:   movl  
$0x50,0x4(%esp)
------------------------------------------------------------------------------
0xb7c4d7c9 in Gdk::GC::GC () from /usr/lib/libgdkmm-2.4.so.1
gdb> backtrace 
#0  0xb7c4d7c9 in Gdk::GC::GC () from /usr/lib/libgdkmm-2.4.so.1
#1  0xb7c4d873 in Gdk::GC::create () from /usr/lib/libgdkmm-2.4.so.1
#2  0x08048c31 in main (argc=0x4fd08, argv=0xb7f5ed70) at test.cc:10


Expected results:
Must return EXIT_SUCCESS;

Does this happen every time?
Happens every time

Other information:
#include <gtkmm.h>

int main(int argc, char *argv[])
{
  Gtk::Main kit(argc, argv);

  Gtk::DrawingArea drar;
  Glib::RefPtr<Gdk::Drawable> dr = drar.get_window();

  Glib::RefPtr<Gdk::GC> gc = Gdk::GC::create(dr); // segfaulting here

  return EXIT_SUCCESS;
}


-- 
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=512441.



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

Message: 6
Date: Sun, 27 Jan 2008 22:00:43 +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: <20080127220043 6A39123F536 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 #2 from chris cvine freeserve co uk  2008-01-27 22:00 UTC -------
"That is not of itself problematic ...".

Actually, quite apart from what further slots the original thread may create,
the temporary slot bound to the const reference argument of
Glib::Thread::create() in that thread has to die at some stage, and thus
apparently through its destructor invoke sigc::trackable functions if bound to
a method of an object deriving from trackable.

The standard says the bound temporary must last until the call to that function
has returned, but does not specify when after that the destruction of the
object is to occur.  Even if on a particular compiler it occurs immediately
after that return, it is at least possible that it might occur around the time
that function call_thread_entry_slot() deletes the slot it has received if the
thread call is short; and in particular on multi-processor machines before
caches have synchronised to enable memory visibility.


-- 
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: 7
Date: Sun, 27 Jan 2008 22:15:44 +0000 (UTC)
From: "gtkmm (bugzilla.gnome.org)"
	<bugzilla-daemon bugzilla gnome org>
Subject: [gtkmm bugzilla] [Bug 512441] Gdk::GC::create() -
	segmentation fault
To: gtkmm-forge lists sourceforge net
Message-ID: <20080127221544 1F4BB23F4FF 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=512441

  gtkmm | general | Ver: 2.12.x

Jonathon Jongsma (jonner) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jonathon quotidian org
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |NOTABUG




------- Comment #1 from Jonathon Jongsma (jonner)  2008-01-27 22:15 UTC -------
Believe it or not, this is expected behavior.  Before a widget is 'realized',
the drawable that you get back from get_window() is always NULL.  In your
example code, the drawing area is not realized yet, so dr is NULL, so it
segfaults when you pass it to GC::create().  The following example code should
not crash:

#include <iostream>
#include <gtkmm.h>

void on_drawing_area_realize(Gtk::DrawingArea* drar)
{
    std::cout << "drawing area realized" << std::endl;
    Glib::RefPtr<Gdk::Drawable> dr = drar->get_window();
    if (dr) {
        std::cout << "drawable not null" << std::endl;
        Glib::RefPtr<Gdk::GC> gc = Gdk::GC::create(dr);
    }
}

int main(int argc, char *argv[])
{
    Gtk::Main kit(argc, argv);

    Gtk::DrawingArea drar;
    drar.signal_realize ().connect (sigc::bind
            (sigc::ptr_fun(on_drawing_area_realize), &drar));
    Gtk::Window win;
    win.add (drar);
    drar.show ();
    win.show ();

    Gtk::Main::run (win);
    return EXIT_SUCCESS;
}


-- 
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=512441.



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

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

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

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


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