Heap corruption and other problems

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

Heap corruption and other problems

Dmitry A. Kazakov
1. It seems that Gtk3 up to version 3.8 (Glib 2.36) has serious problem
which corrupts Ada's memory pool sooner or later. The bug is sporadic and I
cannot track it down, especially without building Glib from sources, which
is a problem itself.

2. Another serious problem is in GDK which shows itself as:

   Gdk-CRITICAL **: gdk_device_get_source: assertion `GDK_IS_DEVICE
(device)' failed

on many occasions. E.g. in combo boxes after resizing them.

So far Gtk3 looks barely usable for any serious application. Sorry for all
efforts AdaCore spent on GtkAda.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
_______________________________________________
gtkada mailing list
[hidden email]
http://lists.adacore.com/mailman/listinfo/gtkada
Reply | Threaded
Open this post in threaded view
|

Re: Heap corruption and other problems

Chris Sparks-3
I have been using GtkAda more to see if I can get something of what I
had before running.  It seems that
my dependence on main_loops and a task router is not working, along with
setting an Event_Handler.  So it
seems that I have make my own infinite loop and check for pending
events.  Calling my event handler as
appropriate.  Cairo seems to be taking care of all the draw events but I
have notice that my handler is
being called way too much and I think using Ada delays (I know it is not
a desired approach) drops drawing
events.  More exploring to see if I can get past my sample program and
to my real software.

chris

> 1. It seems that Gtk3 up to version 3.8 (Glib 2.36) has serious problem
> which corrupts Ada's memory pool sooner or later. The bug is sporadic and I
> cannot track it down, especially without building Glib from sources, which
> is a problem itself.
>
> 2. Another serious problem is in GDK which shows itself as:
>
>     Gdk-CRITICAL **: gdk_device_get_source: assertion `GDK_IS_DEVICE
> (device)' failed
>
> on many occasions. E.g. in combo boxes after resizing them.
>
> So far Gtk3 looks barely usable for any serious application. Sorry for all
> efforts AdaCore spent on GtkAda.
>

_______________________________________________
gtkada mailing list
[hidden email]
http://lists.adacore.com/mailman/listinfo/gtkada
Reply | Threaded
Open this post in threaded view
|

Re: Heap corruption and other problems

Emmanuel Briot
In reply to this post by Dmitry A. Kazakov
> 1. It seems that Gtk3 up to version 3.8 (Glib 2.36) has serious problem
> which corrupts Ada's memory pool sooner or later. The bug is sporadic and I
> cannot track it down, especially without building Glib from sources, which
> is a problem itself.

I don't think we have seen that one ourselves. What is the symptom, a Storage_Error
or something that could help recognize it better ?
Are you able to run your application in valgrind, maybe there is a bug that can be found
much earlier than waiting for the memory corruption...

> 2. Another serious problem is in GDK which shows itself as:
>
>   Gdk-CRITICAL **: gdk_device_get_source: assertion `GDK_IS_DEVICE
> (device)' failed
>
> on many occasions. E.g. in combo boxes after resizing them.

We have seen that one at some point, but it is gone in the development
versions now. I think it is part of our own patches to gtk+, did you apply these ?
They are in the contrib/ directory (of course, that's in case you recompile your
own gtk+, I don't remember what system you are working on).

> So far Gtk3 looks barely usable for any serious application. Sorry for all
> efforts AdaCore spent on GtkAda.

We do use it very successfully for the upcoming version of GPS in fact. The
transition is indeed somewhat painful, but then things seem to work as expected
for us. Of course, we may have made progress or fixes since the last GPL release.

Emmanuel
_______________________________________________
gtkada mailing list
[hidden email]
http://lists.adacore.com/mailman/listinfo/gtkada
Reply | Threaded
Open this post in threaded view
|

Re: Heap corruption and other problems

Dmitry A. Kazakov
On Mon, 12 Aug 2013 09:37:45 +0200, you wrote:

>> 1. It seems that Gtk3 up to version 3.8 (Glib 2.36) has serious problem
>> which corrupts Ada's memory pool sooner or later. The bug is sporadic and I
>> cannot track it down, especially without building Glib from sources, which
>> is a problem itself.
>
> I don't think we have seen that one ourselves. What is the symptom, a Storage_Error
> or something that could help recognize it better ?

Sometimes Storage_Error, even when GNAT debug pool is used and has 0 bytes
allocated in it. Sometimes application crashes silently (access violation).
I cannot track it down.

I discovered the problem first with text buffer. GtkAda implementation of
Insert is this:

   procedure Insert
      (Buffer : not null access Gtk_Text_Buffer_Record;
       Iter   : in out Gtk.Text_Iter.Gtk_Text_Iter;
       Text   : UTF8_String)
   is
      procedure Internal
         (Buffer : System.Address;
          Iter   : in out Gtk.Text_Iter.Gtk_Text_Iter;
          Text   : Interfaces.C.Strings.chars_ptr;
          Len    : Gint);
      pragma Import (C, Internal, "gtk_text_buffer_insert");
      Tmp_Iter : aliased Gtk.Text_Iter.Gtk_Text_Iter := Iter;
      Tmp_Text : Interfaces.C.Strings.chars_ptr := New_String (Text);
   begin
      Internal (Get_Object (Buffer), Tmp_Iter, Tmp_Text, -1);
      Free (Tmp_Text);
      Iter := Tmp_Iter;
   end Insert;

It allocates and frees each time when called and that causes the problem
relatively soon. When I replaced it with:

   procedure Insert
      (Buffer : not null access Gtk_Text_Buffer_Record'Class;
       Iter   : in out Gtk.Text_Iter.Gtk_Text_Iter;
       Text   : UTF8_String)
   is
      procedure Internal
         (Buffer : System.Address;
          Iter   : in out Gtk.Text_Iter.Gtk_Text_Iter;
          Text   : Interfaces.C.char_array;
          Len    : Gint);
      pragma Import (C, Internal, "gtk_text_buffer_insert");
   begin
      Internal (Get_Object (Buffer), Iter, Interfaces.C.To_C (Text),
Text'Length);
   end Insert;

The issue was gone. Now it keep on crashing but elsewhere, usually in some
random Gtk_New.

> Are you able to run your application in valgrind, maybe there is a bug that can be found
> much earlier than waiting for the memory corruption...

I didn't test it under Linux yet. Maybe it is a Win32 problem.

>> 2. Another serious problem is in GDK which shows itself as:
>>
>>   Gdk-CRITICAL **: gdk_device_get_source: assertion `GDK_IS_DEVICE
>> (device)' failed
>>
>> on many occasions. E.g. in combo boxes after resizing them.
>
> We have seen that one at some point, but it is gone in the development
> versions now.

Create a window with combo box in it:

with Gtk.Box;             use Gtk.Box;
with Gtk.Main;
with Gtk.Window;          use Gtk.Window;
with Gtk.Combo_Box_Text;  use Gtk.Combo_Box_Text;

procedure Simple is
   Window : Gtk_Window;
   Combo  : Gtk_Combo_Box_Text;
   Box    : Gtk_VBox;

begin
   Gtk.Main.Init;
   Gtk_New (Window);

   Gtk_New_VBox (Box);
   Window.Add (Box);
   Window.Set_Title ("Test");
   Gtk_New (Combo);
   Box.Pack_Start (Combo, False, False);
   Combo.Append_Text ("A");
   Combo.Append_Text ("B");
   Combo.Append_Text ("C");

   Window.Show_All;

   Gtk.Main.Main;
end Simple;

Start program. Resize window so that combo box resizes. Select something in
the box. Done.

> I think it is part of our own patches to gtk+, did you apply these ?
> They are in the contrib/ directory (of course, that's in case you recompile your
> own gtk+, I don't remember what system you are working on).

I don't know how to do it under MinGW. The Gtk I am using I took from
mingw32 Fedora packages (Gtk 3.8.2). I simply copied /bin /lib etc and
changed Path environment variable. That resolved some issues, e.g.
GtkColorButton crash.

>> So far Gtk3 looks barely usable for any serious application. Sorry for all
>> efforts AdaCore spent on GtkAda.
>
> We do use it very successfully for the upcoming version of GPS in fact. The
> transition is indeed somewhat painful, but then things seem to work as expected
> for us. Of course, we may have made progress or fixes since the last GPL release.

I hope you are right. The problem is difficult is reproduce. In my
application I need a lot of clicking (creating and removing widgets) for
the problem to show. Which suggests a race condition somewhere.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
_______________________________________________
gtkada mailing list
[hidden email]
http://lists.adacore.com/mailman/listinfo/gtkada
Reply | Threaded
Open this post in threaded view
|

Re: Heap corruption and other problems

Dmitry A. Kazakov
In reply to this post by Chris Sparks-3
On Mon, 12 Aug 2013 06:27:37 -0700, you wrote:

>> On Sun, 11 Aug 2013 23:20:49 -0700, you wrote:
>>
>>> I have been using GtkAda more to see if I can get something of what I
>>> had before running.  It seems that
>>> my dependence on main_loops and a task router is not working, along with
>>> setting an Event_Handler.  So it
>>> seems that I have make my own infinite loop and check for pending
>>> events.
>> I don't understand why are you doing it in this way. It is relatively
>> simple to have a custom drawn widgets (or cell renderers). I did it both
>> based on GDK and lately in Cairo. I also successfully ported GDK based
>> widgets to Cairo, which is not very difficult, just tedious.
>>
>> It seems to me that you rather have a design problem relying on events you
>> don't need to catch.
> I was doing it that way because a few years back someone changed Gdk and
> it wasn't working and was in a
> tight loop all the time and not getting updates.  Actually it was you
> who gave me the code to make it
> work.

If so, then it must be no different to what I already successfully ported
to cairo. So let me insist that there is no need to catch these events.

The major problem I faced was resizing. The "configure-event" cannot be
caught and allocated size never goes down for my base widget, which was
Gtk_Fixed_Record. I needed Gtk_Fixed_Record because it had sliders
superimposed on it and standard background. For Gtk_Fixed_Record allocation
sizes grows when you enlarge the widget's container, but remains same
otherwise.

That problem was solved by overriding get preferred width/height "virtual"
operations. They are no events in Gtk3, as they were in Gtk2. I found a way
to override them (it is in the bindings actually) and made preferred
width/height returning 1 pixel and it works now.

> I took a working example with GDK/Cairo and have been building it up.  
> My only issue now is that it get
> this weird redrawing effect.  It is like I am drawing a bitmap over and
> over and over.

Is your widget a descendant of Gtk_Drawing_Area_Record?

Gtk uses double buffering, so you should never experience visual
distortions like partial drawing and re-drawing.

> Can see it easily
> as my graphics card is not the fastest but still fast enough to draw.

As I said, there is something wrong with the way you handle it. You should
simply catch "draw" and use the cairo context it comes with. You may also
draw on other events, e.g. doing mouse tracking, by getting the context
from the widget's window. Of course you should keep track of that
internally and be prepared to repeat exactly same drawing from "draw".

>>> Cairo seems to be taking care of all the draw events but I
>>> have notice that my handler is
>>> being called way too much and I think using Ada delays (I know it is not
>>> a desired approach) drops drawing
>>> events.
>> In fact, new Cairo works pretty well. I successfully ported this library
> So you upgraded away from what the GTKAda folks have provided for
> cairo?

No, I used cairo from GtkAda 3.4. Prior to GtkAda 3.4 it was Damien's cairo
bindings, which were higher level than ones from GtkAda. I ported AICWL to
the GtkAda 3.4 Cairo.

>> to GtkAda 3.4. Everything worked smoothly, after fixing some subtle issues
>> with Pango (which is a bit broken, but nothing one could not work around).
>> I cannot release AICWL though, because of the problems with GTK. They do
>> not affect this library because it practically does not use dynamic memory
>> upon rendering.

> I found a few Pango problems.  Especially bindings that were missing
> that I had to add in.

Yes, I remember some operation, but they weren't actually needed in the
end. What I did is a controlled Ada font type with cairo toy font and pango
font back-ends. Because toy and pango font interfaces have nothing in
common.

> The method
> was there but not in the binding.

One of my problems was that Pango extents is calculated wrong (Get_Extents
is broken). I used Get_Pixel_Extents instead. Another problem was that the
logical rectangle of the extents seems to use capital letters. It is the
ink rectangle one should use (ignoring the documentation stating
otherwise).

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
_______________________________________________
gtkada mailing list
[hidden email]
http://lists.adacore.com/mailman/listinfo/gtkada
Reply | Threaded
Open this post in threaded view
|

Re: Heap corruption and other problems

Chris Sparks-3
In reply to this post by Chris Sparks-3
Dmitry A. Kazakov wrote:

> If so, then it must be no different to what I already successfully
> ported to cairo. So let me insist that there is no need to catch these
> events. The major problem I faced was resizing. The "configure-event"
> cannot be caught and allocated size never goes down for my base
> widget, which was Gtk_Fixed_Record. I needed Gtk_Fixed_Record because
> it had sliders superimposed on it and standard background. For
> Gtk_Fixed_Record allocation sizes grows when you enlarge the widget's
> container, but remains same otherwise. That problem was solved by
> overriding get preferred width/height "virtual" operations. They are
> no events in Gtk3, as they were in Gtk2. I found a way to override
> them (it is in the bindings actually) and made preferred width/height
> returning 1 pixel and it works now.
Yes. I know now that. I don't have to catch Expose Events as Cairo takes
care of all of the drawing and I am ok with that.  I still have to
figure out how to get that tasking part working again as I liked how I
could do an Update call every so many milliseconds.
>> Is your widget a descendant of Gtk_Drawing_Area_Record?
No.  I still have not chosen to use Gtk in any form and all of my code,
and now my sample GTk3 code, still is GTK free.
> Gtk uses double buffering, so you should never experience visual
> distortions like partial drawing and re-drawing.
So if Gtk is doing double buffering that would certain explain why I am
seeing the visual glitches I am seeing as I am not using
double buffering (as far as I know).
> As I said, there is something wrong with the way you handle it. You
> should simply catch "draw" and use the cairo context it comes with.
> You may also draw on other events, e.g. doing mouse tracking, by
> getting the context from the widget's window. Of course you should
> keep track of that internally and be prepared to repeat exactly same
> drawing from "draw".
Yes. I have in my example program changed the contents of window back
and forth between the circular text example and a box example that I
found on the net.  It is the box drawing that seems to have issues.
> No, I used cairo from GtkAda 3.4. Prior to GtkAda 3.4 it was Damien's
> cairo bindings, which were higher level than ones from GtkAda. I
> ported AICWL to the GtkAda 3.4 Cairo.
I'll be glad to see you next version of AICWL as you may already found
issues that I am not aware of in the conversion process.
> Yes, I remember some operation, but they weren't actually needed in
> the end. What I did is a controlled Ada font type with cairo toy font
> and pango font back-ends. Because toy and pango font interfaces have
> nothing in common.
I had to add in bindings for:

   function Get_Default_Root_Window return Gdk_Window;
   procedure Update_Layout (Cr : Cairo.Cairo_Context; Layout :
Pango.Layout.Pango_Layout);
   function Create_Layout (Cr : Cairo.Cairo_Context) return
Pango.Layout.Pango_Layout;

without the last two, I was not able to get the rotated "text" example
to work.


Chris

_______________________________________________
gtkada mailing list
[hidden email]
http://lists.adacore.com/mailman/listinfo/gtkada
Reply | Threaded
Open this post in threaded view
|

Re: Heap corruption and other problems

Dmitry A. Kazakov
On Mon, 12 Aug 2013 08:05:59 -0700, you wrote:

> I still have to
> figure out how to get that tasking part working again as I liked how I
> could do an Update call every so many milliseconds.

Glib.Main.Timeout_Add + Gtk.Widget.Queue_Draw from there. It should not be
tighter than 20ms, human eye cannot see any difference anyway. This is
exactly how the refresh engine from AICWL works. It is used for animated
widgets like the oscilloscope, clocks etc.

>>> Is your widget a descendant of Gtk_Drawing_Area_Record?
> No.  I still have not chosen to use Gtk in any form and all of my code,
> and now my sample GTk3 code, still is GTK free.

I don't understand this. Your widget must be a descendant of at least
Gtk_Widget_Record.

>> As I said, there is something wrong with the way you handle it. You
>> should simply catch "draw" and use the cairo context it comes with.
>> You may also draw on other events, e.g. doing mouse tracking, by
>> getting the context from the widget's window. Of course you should
>> keep track of that internally and be prepared to repeat exactly same
>> drawing from "draw".
> Yes. I have in my example program changed the contents of window back
> and forth between the circular text example and a box example that I
> found on the net.  It is the box drawing that seems to have issues.

The oscilloscope works pretty smoothly and it does a lot more drawing than
filled rectangles. Filled rectangles are relatively efficient in Cairo. It
is lines which are rather slow.

It is also possible to prepare a memory-mapped image and transfer it as a
whole (as a pixbuf) into the Cairo context. The coming version of GtkAda
contributions will a package for this.

>> No, I used cairo from GtkAda 3.4. Prior to GtkAda 3.4 it was Damien's
>> cairo bindings, which were higher level than ones from GtkAda. I
>> ported AICWL to the GtkAda 3.4 Cairo.
> I'll be glad to see you next version of AICWL as you may already found
> issues that I am not aware of in the conversion process.

I am waiting for other problems resolved and GtkAda packaged for Linux. I
can post code snippets from AICWL if you are interested.

>> Yes, I remember some operation, but they weren't actually needed in
>> the end. What I did is a controlled Ada font type with cairo toy font
>> and pango font back-ends. Because toy and pango font interfaces have
>> nothing in common.
> I had to add in bindings for:
>
>    function Get_Default_Root_Window return Gdk_Window;

Gdk_Window is unusable, IMO.

>    procedure Update_Layout (Cr : Cairo.Cairo_Context; Layout :
> Pango.Layout.Pango_Layout);
>    function Create_Layout (Cr : Cairo.Cairo_Context) return
> Pango.Layout.Pango_Layout;
>
> without the last two, I was not able to get the rotated "text" example
> to work.

You should *first* do all transformations and only *then* use Show_Layout.
I know it sounds crazy, but this is how Cairo works. Keep in mind doing
Translate to the point around which you rotate the text and Move_To to the
point where you start drawing the text origin. If you stretch and skew the
text you should use Get_Extents before that and take into account gains
afterwards, which may become a linear combination of cosine and sine. This
is the way AICWL draws its texts.

I didn't use Update_Layout because I didn't figure from the documentation
what it did exactly and because I am using Cairo toy fonts in the same
code. The common denominator for both is get extents + show.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
_______________________________________________
gtkada mailing list
[hidden email]
http://lists.adacore.com/mailman/listinfo/gtkada
Reply | Threaded
Open this post in threaded view
|

Re: Heap corruption and other problems

Chris Sparks-3
In reply to this post by Chris Sparks-3
Dmitry A. Kazakov wrote:
> Glib.Main.Timeout_Add + Gtk.Widget.Queue_Draw from there. It should
> not be tighter than 20ms, human eye cannot see any difference anyway.
> This is exactly how the refresh engine from AICWL works. It is used
> for animated widgets like the oscilloscope, clocks etc.
I'd like to see an example of this.  This new way of dealing with main
loops is a bit daunting without an example.

I found the error in my small demo!  I was drawing my box demo every
cycle, because of a variable I used to get the Event_Type which didn't
change so it called my routine over and over.
> I don't understand this. Your widget must be a descendant of at least
> Gtk_Widget_Record.
No.  I create my own Widgets using Gdk.Window as a base and my own class
hierarchy.
> I am waiting for other problems resolved and GtkAda packaged for
> Linux. I can post code snippets from AICWL if you are interested.
I would appreciate all the help I can get.
> Gdk_Window is unusable, IMO.
That is all I use.  It has become less useful because of Cairo but I
wouldn't say it is unusable! :-)
> You should *first* do all transformations and only *then* use
> Show_Layout.
The way the example was done I'd have to redo it to try as you suggest,
but what you say does make sense.

> I know it sounds crazy, but this is how Cairo works. Keep in mind
> doing Translate to the point around which you rotate the text and
> Move_To to the point where you start drawing the text origin. If you
> stretch and skew the text you should use Get_Extents before that and
> take into account gains afterwards, which may become a linear
> combination of cosine and sine. This is the way AICWL draws its texts.
> I didn't use Update_Layout because I didn't figure from the
> documentation what it did exactly and because I am using Cairo toy
> fonts in the same code. The common denominator for both is get extents
> + show.
I just commented out Update_Layout and it had zero effect!  Good catch.

Chris
_______________________________________________
gtkada mailing list
[hidden email]
http://lists.adacore.com/mailman/listinfo/gtkada
Reply | Threaded
Open this post in threaded view
|

Re: Heap corruption and other problems

Dmitry A. Kazakov
On Mon, 12 Aug 2013 20:46:29 -0700, you wrote:

> Dmitry A. Kazakov wrote:
>> Glib.Main.Timeout_Add + Gtk.Widget.Queue_Draw from there. It should
>> not be tighter than 20ms, human eye cannot see any difference anyway.
>> This is exactly how the refresh engine from AICWL works. It is used
>> for animated widgets like the oscilloscope, clocks etc.
> I'd like to see an example of this.  This new way of dealing with main
> loops is a bit daunting without an example.

It does not have to deal with that. Here is what it does:

   procedure Set_Period
             (  Engine : in out Layered_Refresh_Engine;
                Period : Duration
             )  is
   begin
      if Period /= Engine.Period then
         declare
            Interval : GUInt := GUInt (GDouble (Period) * 1_000.0);
         begin
            if Engine.Timer /= 0 then
               if 0 = Remove (Engine.Timer) then
                  null;
               end if;
               Engine.Timer := 0;
            end if;
            Engine.Timer :=
               Timeout_Add
               (  Interval,
                  Timer'Access,
                  Engine'Address
               );
            Engine.Period := Period;
         end;
      end if;
   end Set_Period;

The timer goes through the list of widgets serviced by the engine and does
Queue_Draw for each. The list elements are weak references which are
automatically invalidated when the referenced widget disappears. Such
elements are removed from the list.

   function Timer (Data : System.Address) return GBoolean is
      Engine : Layered_Refresh_Engine renames
                  Conversions.To_Pointer (Data).all;
   begin
      if Engine.List /= null then
         Engine.Active := True;
         declare
            This : not null access List_Element := Engine.List;
            Next : not null access List_Element := This;
         begin
            loop
               Next := This.Next;
               if Is_Valid (This.Widget) then
                  Queue_Draw (Get (This.Widget));
               else
                  Delete (Engine, This.all'Unchecked_Access);
                  exit when Engine.List = null;
               end if;
               exit when Next = Engine.List;
               This := Next;
            end loop;
         end;
         Engine.Active := False;
      end if;
      return 1;
   end Timer;

Note that this is fully compatible with the event-controlled path of
updating widget. E.g. if you change the widget by some other means (resize
for example) it will get a draw notification independently on the timer.

>> I don't understand this. Your widget must be a descendant of at least
>> Gtk_Widget_Record.
> No.  I create my own Widgets using Gdk.Window as a base and my own class
> hierarchy.

Which is the source of your problems. You are throwing overboard almost
everything Gtk has to offer.

>> I am waiting for other problems resolved and GtkAda packaged for
>> Linux. I can post code snippets from AICWL if you are interested.
> I would appreciate all the help I can get.

Let me know then.

>> Gdk_Window is unusable, IMO.
> That is all I use.  It has become less useful because of Cairo but I
> wouldn't say it is unusable! :-)

So can see that from its declaration:

   type Gdk_Window is new Glib.C_Proxy;

And from the design POV it does not make any sense to have your stuff as a
window rather than a widget. A widget can be put into a container and used
in thousand useful ways in which a window cannot (be themed, have
properties, styles and so on). You gain nothing by doing it window. A
widget can always be made a window by putting it into one. Since Gtk3
widgets can be transparent because Cairo uses alpha channel.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
_______________________________________________
gtkada mailing list
[hidden email]
http://lists.adacore.com/mailman/listinfo/gtkada
Reply | Threaded
Open this post in threaded view
|

Build from source code

Chris Sparks-3
In reply to this post by Chris Sparks-3
Hi everyone,

I see that one could build gtkada and all of the necessary C source
files (i.e zlib, pixman, glib, etc) from scratch, but there are no
instructions on which to do first, how to setup configure properly, etc.

I managed to get zlib compiled and installed (make install) but the
other packages which use this library can't see it.

I am beginning to wonder how anyone can build any of this.

What i am trying to do is to get cairo compiled for debugging so I can
access the internal methods with GDB.

chris


_______________________________________________
gtkada mailing list
[hidden email]
http://lists.adacore.com/mailman/listinfo/gtkada
Reply | Threaded
Open this post in threaded view
|

Re: Build from source code

Emmanuel Briot
> I see that one could build gtkada and all of the necessary C source files (i.e zlib, pixman, glib, etc) from scratch, but there are no instructions on which to do first, how to setup configure properly, etc.
>
> I managed to get zlib compiled and installed (make install) but the other packages which use this library can't see it.
>
> I am beginning to wonder how anyone can build any of this.


Seems like this question would be better asked on a gtk+ mailing list, where you are more
likely to have people who routinely do these kind of builds. GtkAda users are mostly
expected to use the binaries, so I doubt many of them recompile the C libraries, only
the Ada part.

Emmanuel
_______________________________________________
gtkada mailing list
[hidden email]
http://lists.adacore.com/mailman/listinfo/gtkada
Reply | Threaded
Open this post in threaded view
|

Re: Build from source code

Chris Sparks-3
In reply to this post by Chris Sparks-3
Yes maybe so.  I was more curious why Adacore would provide the source
files without a clue as to how they are compiled.

I just needed a little direction in recreating the gtkada toolset from
scratch so that I can get debugging info into the compiles. I have found
so many compilation issues that I cannot resolve that is disheartening.

I did find that my version of Msys/Mingw was old and I upgraded it.  It
only helped in rebuilding zlib! LOL

>> I see that one could build gtkada and all of the necessary C source files (i.e zlib, pixman, glib, etc) from scratch, but there are no instructions on which to do first, how to setup configure properly, etc.
>>
>> I managed to get zlib compiled and installed (make install) but the other packages which use this library can't see it.
>>
>> I am beginning to wonder how anyone can build any of this.
>
> Seems like this question would be better asked on a gtk+ mailing list, where you are more
> likely to have people who routinely do these kind of builds. GtkAda users are mostly
> expected to use the binaries, so I doubt many of them recompile the C libraries, only
> the Ada part.
>
> Emmanuel

_______________________________________________
gtkada mailing list
[hidden email]
http://lists.adacore.com/mailman/listinfo/gtkada
Reply | Threaded
Open this post in threaded view
|

Re: Build from source code

John Marino-5
On 8/18/2013 20:58, Chris Sparks wrote:
> Yes maybe so.  I was more curious why Adacore would provide the source
> files without a clue as to how they are compiled.

In my experience, the Adacore source tarballs come with "build/install"
instructions to cover building from source.  They are generally complete
although the configure and .gpr files sometimes have additional information.

They don't provide instructions on how to build dependencies, nor would
I expect them to provide them.

> I just needed a little direction in recreating the gtkada toolset from
> scratch so that I can get debugging info into the compiles. I have found
> so many compilation issues that I cannot resolve that is disheartening.

This is why Ludovic's work in Debian and my work in *BSD is so important
[1].  We've already done all this and wrote down the recipe in the form
of make/build files.  Yes, there are tricks and undocumented things
sometimes, but these package systems capture that knowledge.  To
recreate all of that on your own is reinventing the wheel.

[1] There are similar efforts by Slack and Arch users.

> I did find that my version of Msys/Mingw was old and I upgraded it.  It
> only helped in rebuilding zlib! LOL

Okay, I can see where Windows would make you reinvent the wheel.  Pkgsrc
might work on windows but other than that, I don't know of previous
efforts.  That might also explain why you feel that the install
instructions are lacking.

Okay, disregard everything I just said.  I can't help much with windows.  :)

John

>>> I see that one could build gtkada and all of the necessary C source
>>> files (i.e zlib, pixman, glib, etc) from scratch, but there are no
>>> instructions on which to do first, how to setup configure properly, etc.
>>>
>>> I managed to get zlib compiled and installed (make install) but the
>>> other packages which use this library can't see it.
>>>
>>> I am beginning to wonder how anyone can build any of this.
>>
>> Seems like this question would be better asked on a gtk+ mailing list,
>> where you are more
>> likely to have people who routinely do these kind of builds. GtkAda
>> users are mostly
>> expected to use the binaries, so I doubt many of them recompile the C
>> libraries, only
>> the Ada part.
>>
>> Emmanuel
>
> _______________________________________________
> gtkada mailing list
> [hidden email]
> http://lists.adacore.com/mailman/listinfo/gtkada
_______________________________________________
gtkada mailing list
[hidden email]
http://lists.adacore.com/mailman/listinfo/gtkada
Reply | Threaded
Open this post in threaded view
|

Re: Build from source code

Chris Sparks-3
In reply to this post by Chris Sparks-3
John Marino wrote:
> In my experience, the Adacore source tarballs come with
> "build/install" instructions to cover building from source. They are
> generally complete although the configure and .gpr files sometimes
> have additional information. They don't provide instructions on how to
> build dependencies, nor would I expect them to provide them.
True there are build/install for all of it but I cannot make it compile
out of the box.
> This is why Ludovic's work in Debian and my work in *BSD is so
> important [1]. We've already done all this and wrote down the recipe
> in the form of make/build files. Yes, there are tricks and
> undocumented things sometimes, but these package systems capture that
> knowledge. To recreate all of that on your own is reinventing the
> wheel. [1] There are similar efforts by Slack and Arch users.
Hmmm.  Well I'd be interested in learning more about this.
> Okay, I can see where Windows would make you reinvent the wheel.
> Pkgsrc might work on windows but other than that, I don't know of
> previous efforts. That might also explain why you feel that the
> install instructions are lacking. Okay, disregard everything I just
> said. I can't help much with windows. :) John
LOL!

chris
_______________________________________________
gtkada mailing list
[hidden email]
http://lists.adacore.com/mailman/listinfo/gtkada
Reply | Threaded
Open this post in threaded view
|

Re: Build from source code

Ludovic Brenta-2
In reply to this post by Chris Sparks-3
>> This is why Ludovic's work in Debian and my work in *BSD is so
>> important [1]. We've already done all this and wrote down the recipe
>> in the form of make/build files. Yes, there are tricks and
>> undocumented things sometimes, but these package systems capture that
>> knowledge. To recreate all of that on your own is reinventing the
>> wheel. [1] There are similar efforts by Slack and Arch users.
>
> Hmmm.  Well I'd be interested in learning more about this.

Installing Debian or a BSD in a virtual machine, with the complete GTK+
and Ada development environment, is probably much easier than
recompiling the world on Windows.  Debian, at least, provides debugging
symbols for most libraries (and definitely all Ada libraries) in
separate packages, i.e. you type

aptitude install libgtkada-dbg

and you get everything you need.

There might be two problems with these distributions though: (a) they
don't help if your target platform is Windows and (b) they use versions
of GTK+ and GtkAda that might not be the ones you're interested in.  For
example, Debian still has only GtkAda 2.24.1, not 3.x.  (it does have
GTK+ 3.x and debugging symbols).

If you're still interested, start here for Debian: http://www.debian.org
and http://people.debian.org/~lbrenta/debian-ada-policy.html

I'm not sure which BSD John has worked the most on and thus would
recommend for an Ada programmer.

--
Ludovic Brenta.
_______________________________________________
gtkada mailing list
[hidden email]
http://lists.adacore.com/mailman/listinfo/gtkada
Reply | Threaded
Open this post in threaded view
|

Re: Build from source code

John Marino-5
On 8/19/2013 01:48, Ludovic Brenta wrote:
> If you're still interested, start here for Debian: http://www.debian.org
> and http://people.debian.org/~lbrenta/debian-ada-policy.html
>
> I'm not sure which BSD John has worked the most on and thus would
> recommend for an Ada programmer.

Lately I'm concentrating on FreeBSD ports, which is shared by both
FreeBSD and DragonFly BSD.  Both of these are in great shape with
basically the latest versions available to GNAT FSF 4.7 compilers.

The NetBSD pkgsrc system is also in good shape but contains far few Ada
packages.  There was very little interest by the OpenBSD community for
Ada so I never carried it further than porting the compiler.

Therefore I recommend either FreeBSD or DragonFly for Ada on BSD.

Regards,
John

_______________________________________________
gtkada mailing list
[hidden email]
http://lists.adacore.com/mailman/listinfo/gtkada
Reply | Threaded
Open this post in threaded view
|

Re: Build from source code

Dmitry A. Kazakov
In reply to this post by Chris Sparks-3
On Sun, 18 Aug 2013 11:58:26 -0700, you wrote:

> Yes maybe so.  I was more curious why Adacore would provide the source
> files without a clue as to how they are compiled.
>
> I just needed a little direction in recreating the gtkada toolset from
> scratch so that I can get debugging info into the compiles. I have found
> so many compilation issues that I cannot resolve that is disheartening.
>
> I did find that my version of Msys/Mingw was old and I upgraded it.  It
> only helped in rebuilding zlib! LOL

Your starting point could be:

http://www.mingw.org/wiki/Bootstrapping_GLIB_with_MinGW

There also exist precompiled MinGW packages for Fedora and OpenSUSE. E.g.

https://fedoraproject.org/wiki/Packaging:MinGW?rd=Packaging/MinGW

These packages include the latest builds of the Gtk stuff (version 3.8) for
Windows. I successfully used these binaries with GtkAda 3.4 on Windows.
All you have to do is

yum install mingw32-gtk3

Maybe, some themes.

Then you copy the tree

/usr/i686-w64-mingw32/sys-root/mingw

to your Windows machine and put the folder name in the path before
AdaCore's GTK.

Everything worked except for some bugs, which I presume are of Gtk itself,
e.g. memory corruption and GDK device bug (and are present in Gtk 3.4
anyway).

P.S. I understand your frustration. You are not alone. MinGW guys seem very
angry too. Gtk is a quintessence of C programming culture.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
_______________________________________________
gtkada mailing list
[hidden email]
http://lists.adacore.com/mailman/listinfo/gtkada
Reply | Threaded
Open this post in threaded view
|

Re: Heap corruption and other problems

Pascal-68
In reply to this post by Dmitry A. Kazakov
Hello Dmitry,

I’ve just tried your simple example with GTKAda GPL 2013 (GTK Ada 3.4.2 with GTK+ 3.4.1) on MacOS 10.9 with no errors :
$ ./simple 


Have you still issues?


Le 12 août 2013 à 10:36, Dmitry A. Kazakov <[hidden email]> a écrit :

On Mon, 12 Aug 2013 09:37:45 +0200, you wrote:

8<…>8
2. Another serious problem is in GDK which shows itself as:

 Gdk-CRITICAL **: gdk_device_get_source: assertion `GDK_IS_DEVICE
(device)' failed

on many occasions. E.g. in combo boxes after resizing them.

We have seen that one at some point, but it is gone in the development
versions now.

Create a window with combo box in it:

with Gtk.Box;             use Gtk.Box;
with Gtk.Main;
with Gtk.Window;          use Gtk.Window;
with Gtk.Combo_Box_Text;  use Gtk.Combo_Box_Text;

procedure Simple is
  Window : Gtk_Window;
  Combo  : Gtk_Combo_Box_Text;
  Box    : Gtk_VBox;

begin
  Gtk.Main.Init;
  Gtk_New (Window);

  Gtk_New_VBox (Box);
  Window.Add (Box);
  Window.Set_Title ("Test");
  Gtk_New (Combo);
  Box.Pack_Start (Combo, False, False);
  Combo.Append_Text ("A");
  Combo.Append_Text ("B");
  Combo.Append_Text ("C");

  Window.Show_All;

  Gtk.Main.Main;
end Simple;

Start program. Resize window so that combo box resizes. Select something in
the box. Done.

I think it is part of our own patches to gtk+, did you apply these ?
They are in the contrib/ directory (of course, that's in case you recompile your
own gtk+, I don't remember what system you are working on).

I don't know how to do it under MinGW. The Gtk I am using I took from
mingw32 Fedora packages (Gtk 3.8.2). I simply copied /bin /lib etc and
changed Path environment variable. That resolved some issues, e.g.
GtkColorButton crash.

So far Gtk3 looks barely usable for any serious application. Sorry for all
efforts AdaCore spent on GtkAda.

We do use it very successfully for the upcoming version of GPS in fact. The
transition is indeed somewhat painful, but then things seem to work as expected
for us. Of course, we may have made progress or fixes since the last GPL release.

I hope you are right. The problem is difficult is reproduce. In my
application I need a lot of clicking (creating and removing widgets) for
the problem to show. Which suggests a race condition somewhere.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
_______________________________________________
gtkada mailing list
[hidden email]
http://lists.adacore.com/mailman/listinfo/gtkada


_______________________________________________
gtkada mailing list
[hidden email]
http://lists.adacore.com/mailman/listinfo/gtkada