Problem in debugging GPS

Problem in debugging GPS

[Sandor Lengyel]

I modified GPS to work with gcc 4.1.1. using gcc 4.1.1

Now I try to debug it using gdb 6.3 (Ada enabled and ddd)

Something funny is happening.
In file projects-editor.adb I have the following code segment:


  function Create_Project
     (Registry : Projects.Registry.Project_Registry'Class;
      NameP, Path : String) return Project_Type
   is
      D       : constant String :=
        Path & To_File_Name (NameP) & Project_File_Extension;
      Project : Project_Node_Id;
      Project_Name : Name_Id;
      P : Project_Type;

   begin


--       Prj.Tree.Initialize (InTree);

      --  Adding the name of the project
      Project_Name := Get_String (NameP);
      Set_Name_Of (Project, InTree, Project_Name);

Now Entering Create_Projects and displaying NameP i see that NapmeP is:
(gnat.string.string_access) 0x91385cc.

Doing Stepi this value stayes even executing:

      D       : constant String :=
        Path & To_File_Name (NameP) & Project_File_Extension;

However doing one more Stepi the cursor jumps to 

      P : Project_Type;

and NameP value changes to:

(gnat.string.string_access) 0xfffffff.

The machine code executed is:
 <projects__editor__create_project+573>:      mov    0x8e42944,%ebx

This value stayes for the rest of the code.

Why?

Re: Problem in debugging GPS

[Ludovic Brenta]

Sandor Lengyel <slengyel@chello.hu> writes:
> I modified GPS to work with gcc 4.1.1. using gcc 4.1.1

Me too, and it crashes badly.  I compiled with -gstabs+ and at least I
get clean stack traces with the old gnat-gdb 5.3.  That hasn't helped
me find the cause, though.

-- 
Ludovic Brenta.

Re: Problem in debugging GPS

[Martin Krischik]

Sandor Lengyel schrieb:

> I modified GPS to work with gcc 4.1.1. using gcc 4.1.1

Great - I did not get that far. How about joining The GNU Ada Project 
[1] and share your patches with the rest of us? We alwas welcome new 
maintainers and if you got the GPS to compile you certainly are our man.

Martin

[1] http://gnuada.sf.net

Re: Problem in debugging GPS

[Ludovic Brenta]

Martin Krischik <krischik@users.sourceforge.net> writes:
>> I modified GPS to work with gcc 4.1.1. using gcc 4.1.1
>
> Great - I did not get that far. How about joining The GNU Ada
> Project [1] and share your patches with the rest of us? We alwas
> welcome new maintainers and if you got the GPS to compile you
> certainly are our man.
>
> Martin
>
> [1] http://gnuada.sf.net

If you like, I can send you my changes.  I've not only added a patch
to the GPS sources themselves, but I've also rewritten the build
machinery in a drastically simplistic way, consisting of *one*
Makefile (the famous debian/rules) and *one* GNAT project file.  This
comes at the expense of some flexibility; these scripts are designed
to work on Debian and only on Debian.

I also make heavy use of shared libraries.  My GPS uses not only
libgtkada.so.2.8.1, but also libtemplates_parser.so.10,
libgnatvsn.so.4.1, libgnatprj.so.4.1, and libpython2.4.so.1 (yes,
Python is enabled in the Debian build, even in GPS 2.1.0).  Thus, I
completely avoid the code duplication that AdaCore seem so fond of.
Even then, it takes 2h40 to compile GPS on my laptop, compared to 1
hour for GPS 2.1.0.  Part of the increase comes from GPS itself, and
part from the compiler, as GCC 4.1.1 is noticeably slower and more
memory-hungry than GNAT 3.15p.

The patches, on the other hand, are not specific to Debian, so you
could try them if you like.  They apply cleanly on the pristine
sources for GPS 4.0.0, and are managed with quilt.  It is also very
easy to apply them manually if you just read the short file,
patches/series.  The patch "gcc-4.1.patch" in which you are interested
is a mere 269 lines long.

The down side is that, as I said, GPS crashes when it opens a "file
open" dialog.  The problem looks like a stack overflow in GTK+, but
I'm not sure.  I recompiled with -O0 but got the same results.  -O0
-fstack-check fared no better.  I still don't know if it's a compiler
bug or a GPS bug.  Since testgtk works correctly, I don't think it is
a GtkAda or GTK+ bug.

You can get the Debian scripts and patches from my Monotone server on
Ada-France, if you want.  The reasons why I did not join the GNU Ada
project on SourceForge are because (a) I dislike Subversion, (b) the
Debian patches are older and much more extensive than the ones you
have, and (c) the build machineries mandated by the package managers
(RPM vs. DPKG) are radically different; so, merging the Debian patches
and GNU Ada would be quite a lot of work.  I'm not against it, though.

-- 
Ludovic Brenta.

Re: Problem in debugging GPS

[Martin Krischik]

Ludovic Brenta wrote:

> Martin Krischik <krischik@users.sourceforge.net> writes:
>>> I modified GPS to work with gcc 4.1.1. using gcc 4.1.1
>>
>> Great - I did not get that far. How about joining The GNU Ada
>> Project [1] and share your patches with the rest of us? We alwas
>> welcome new maintainers and if you got the GPS to compile you
>> certainly are our man.
>>
>> Martin
>>
>> [1] http://gnuada.sf.net
> 
> If you like, I can send you my changes.  I've not only added a patch
> to the GPS sources themselves, but I've also rewritten the build
> machinery in a drastically simplistic way, consisting of *one*
> Makefile (the famous debian/rules) and *one* GNAT project file.  This
> comes at the expense of some flexibility; these scripts are designed
> to work on Debian and only on Debian.

But they are probably easier to read the en automake/autoconf stuff.

> I also make heavy use of shared libraries.  My GPS uses not only
> libgtkada.so.2.8.1, but also libtemplates_parser.so.10,
> libgnatvsn.so.4.1, libgnatprj.so.4.1, and libpython2.4.so.1 (yes,
> Python is enabled in the Debian build, even in GPS 2.1.0).  Thus, I
> completely avoid the code duplication that AdaCore seem so fond of.

I never understood that. And am always nagged AdaCore about it. But they
allways mandated that is has to be that way and it would not work any other
way...

Anyway: I would not mind adding similar libs to the R7 distribution (which
is currently not in planning ;-) ).

> The patches, on the other hand, are not specific to Debian, so you
> could try them if you like.  They apply cleanly on the pristine
> sources for GPS 4.0.0, and are managed with quilt.  It is also very
> easy to apply them manually if you just read the short file,
> patches/series.  The patch "gcc-4.1.patch" in which you are interested
> is a mere 269 lines long.

A mere 269 lines....

> The down side is that, as I said, GPS crashes when it opens a "file
> open" dialog.  The problem looks like a stack overflow in GTK+, but
> I'm not sure.  I recompiled with -O0 but got the same results.  -O0
> -fstack-check fared no better.  I still don't know if it's a compiler
> bug or a GPS bug.  Since testgtk works correctly, I don't think it is
> a GtkAda or GTK+ bug.

Up until I deleted my .gkt* and .gnome files any GTK+ application started by
root crashed. Before you ask: vim is gtk+.

For my main user user Gtk+ applications crash when opening a menu. But only
when they where started from an icon. They work fine when started from an
terminal window. ?!?!

And if I start gnome-control-center beforehand the applications look all
different as when I don't.

Mind you I use KDE as desktop. But then: KDE applications never make such a
fuss - even when started under a GNOME desktop. It is just that Gtk/GNOME
is such a "Mimose" as we would say in Germany (Mimose: a flower which dies
quickly when not treated to absolute perfection).

> You can get the Debian scripts and patches from my Monotone server on
> Ada-France, if you want.  The reasons why I did not join the GNU Ada
> project on SourceForge are because (a) I dislike Subversion, (b) the
> Debian patches are older and much more extensive than the ones you
> have, and (c) the build machineries mandated by the package managers
> (RPM vs. DPKG) are radically different; so, merging the Debian patches
> and GNU Ada would be quite a lot of work.  I'm not against it, though.

Ok for (a) and (b) - but for (c): RPM is just one option. The Solaris
maintainer create tar-balls. For MinGW I too have tried tar-balls and I
have created quite a well working RPM-Spec to Tarball-Bash converter. Only
MinGW on its own does not compile at all. Even Arno mentioned once that
AdaCore uses cygwin for automake/autoconf etc.pp. So my current hopes are
on an MinGW/Cygwin combo for MS-Windows.

Martin
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: Problem in debugging GPS

[Ludovic Brenta]

Martin Krischik <krischik@users.sourceforge.net> writes:
>> If you like, I can send you my changes.  I've not only added a patch
>> to the GPS sources themselves, but I've also rewritten the build
>> machinery in a drastically simplistic way, consisting of *one*
>> Makefile (the famous debian/rules) and *one* GNAT project file.  This
>> comes at the expense of some flexibility; these scripts are designed
>> to work on Debian and only on Debian.
>
> But they are probably easier to read the en automake/autoconf stuff.

Oh yes, by a wide margin.  They're also much less brittle and
sensitive to the installed versions of the autotools.  In fact, they
are not sentitive at all to the autotools, since they don't use them.

In GPS, I haven't been able to avoid building some parts of
SourceNavigator and Berkeley DB, which are both bundled in the
upstream tarball.  For these I still have to call configure and a
recursive make.

>> I also make heavy use of shared libraries.  My GPS uses not only
>> libgtkada.so.2.8.1, but also libtemplates_parser.so.10,
>> libgnatvsn.so.4.1, libgnatprj.so.4.1, and libpython2.4.so.1 (yes,
>> Python is enabled in the Debian build, even in GPS 2.1.0).  Thus, I
>> completely avoid the code duplication that AdaCore seem so fond of.
>
> I never understood that. And am always nagged AdaCore about it. But they
> allways mandated that is has to be that way and it would not work any other
> way...

Unfortunately, they seem to be correct as far as 4.0.0 is concerned.
2.1.0 works fine with my simple build scripts and no code duplication,
though.  Currently, I'm trying to port GPS 3.1.3 forward to using
GtkAda 2.8.1.  You can already see my unfinished work in the Monotone
database, under the branch org.debian.gnat-gps.3.1.3.  The branch
org.debian.gnat-gps contains the completedstuff for 4.0.0; maybe you
or someone else could try and replicate the crash I experience?

> Up until I deleted my .gkt* and .gnome files any GTK+ application started by
> root crashed. Before you ask: vim is gtk+.

I never start applications as root.  Except for apt-get and aptitude :)

> For my main user user Gtk+ applications crash when opening a menu. But only
> when they where started from an icon. They work fine when started from an
> terminal window. ?!?!
>
> And if I start gnome-control-center beforehand the applications look all
> different as when I don't.
>
> Mind you I use KDE as desktop. But then: KDE applications never make such a
> fuss - even when started under a GNOME desktop. It is just that Gtk/GNOME
> is such a "Mimose" as we would say in Germany (Mimose: a flower which dies
> quickly when not treated to absolute perfection).

I use IceWM as my window manager.  No gnome, no KDE.  I occasionally
use GTK+ applications (Galeon, GPS, The GIMP) but most often, just
emacs and xterm.  At one point, for weeks on end I even ran with no X
at all; just emacs in full-screen text mode.  I stopped doing that
when I had to test GPS :)

>> You can get the Debian scripts and patches from my Monotone server on
>> Ada-France, if you want.  The reasons why I did not join the GNU Ada
>> project on SourceForge are because (a) I dislike Subversion, (b) the
>> Debian patches are older and much more extensive than the ones you
>> have, and (c) the build machineries mandated by the package managers
>> (RPM vs. DPKG) are radically different; so, merging the Debian patches
>> and GNU Ada would be quite a lot of work.  I'm not against it, though.
>
> Ok for (a) and (b) - but for (c): RPM is just one option. The Solaris
> maintainer create tar-balls. For MinGW I too have tried tar-balls and I
> have created quite a well working RPM-Spec to Tarball-Bash converter. Only
> MinGW on its own does not compile at all. Even Arno mentioned once that
> AdaCore uses cygwin for automake/autoconf etc.pp. So my current hopes are
> on an MinGW/Cygwin combo for MS-Windows.

I've standardised the way I make my Debian packages, especially GPS,
into two directories: debian/ and patches/.  It would be quite easy
for you to use patches/; but less easy to use debian/.  If you would
like to replicate all of that into your Subversion repo, be my guest
:)

-- 
Ludovic Brenta.

Re: Problem in debugging GPS

[Simon Wright]

Ludovic Brenta <ludovic@ludovic-brenta.org> writes:

> Thus, I completely avoid the code duplication that AdaCore seem so
> fond of.

Just for interest -- do you mean object code duplication (ie, place
the package's source code on the compiler's search path and recompile
it for each project)?

As a provider of components who doesn't care what OS the users have to
cope with I find this a very natural way to deal!

Re: Problem in debugging GPS

[Martin Krischik]

Ludovic Brenta schrieb:


>> Up until I deleted my .gkt* and .gnome files any GTK+ application started by
>> root crashed. Before you ask: vim is gtk+.
> 
> I never start applications as root.  Except for apt-get and aptitude :)

Interesting - how do you edit your configuration files then? Do you 
"setfacl -m user:xxx:rwX" on /etc? ;-)

Martin

Code duplication and component-based distributions (was: Problem in debugging GPS)

[Ludovic Brenta]

Simon Wright wrote:
> Ludovic Brenta <ludovic@ludovic-brenta.org> writes:
>
> > Thus, I completely avoid the code duplication that AdaCore seem so
> > fond of.
>
> Just for interest -- do you mean object code duplication (ie, place
> the package's source code on the compiler's search path and recompile
> it for each project)?

No, I meant that I avoid both source and object code duplication. I
myself benefit by not having to recompile e.g. GtkAda when I compile
GPS. That alone shaves one hour off of a full build on my laptop
(thanks to my lean-and-mean build scripts, I hardly ever need a full
rebuild anyway).

Since the -dev packages for libraries provide the source files, I've
removed the duplicated sources from all of my .orig.tar.gz files. For
example, I've removed the templates_parser sources from AWS and GPS,
and I've removed the bundled parts of GNAT from ASIS and GPS.

As for the object code, the read-only ALI files in the -dev package
ensure that any package that build-depends on the -dev package will not
rebuild the library from source. Then, the run-time library package
provides a shared library; all packages that depend on that object code
just link with the shared library. For example, both gnat-gps and
libaws.so.2.2 link with libtemplates_parser.so.10, and libasis.so.2005
and gnat-gps link against libgnatvsn.so.4.1.

I took that approach to such extremes that I even created new libraries
that AdaCore thought impossible, or at least very difficult, to make;
namely libgnatvsn and libgnatprj. The GNAT tools (gnatmake and friends)
and ASIS have been using these libraries for a year now without any
problems, thank you very much. And the size of the GNAT tools went down
by 90%.

Similarly, since the duplicated templates_parsers in AWS and GPS were
different and incompatible at the source level, I created a separate
package that is compatible with both, by doing a checkout from CVS and
then patching further. That package is now in Etch, by the way.

All of that is dangerous; don't do it at home if you want a stable
system :) the danger is that I may break programs. Right now I'm stuck
on GPS because it crashes. I'm starting to get worried by the looming
freeze in Etch, and the transition to GCC 4.1 is not yet finished. I
think I've been too reliant on the "if it compiles, it will probably
work" attitude. This does not hold with GPS, unfortunately, since it
compiles but does not work.

> As a provider of components who doesn't care what OS the users have to
> cope with I find this a very natural way to deal!

In theory, yes, but this means you've got to be very good at
configuration management (i.e. the use-relationships between the
components), and at package management (i.e. installing and upgrading
all packages on the platform in a way that is consistent with the
desired configuration).

On OSs that do not provide good package management, like the one from
the Redmond, you're in for trouble. I think that that's why AdaCore
prefer code duplication to proper configuration and package management.
In those that do provide good package management, you've got to think
in terms of the whole system, and how each single component fits in.
That also requires good advance planning, and may require lock-step
development (i.e. while developing program P, you must wait for library
L to be formally released before you can use the new features in it;
that precludes truly parallel development of P and L).

So, good configuration management and good package management require
dedicated work and manpower.

I think it is interesting to contrast Gentoo or FreeBSD with Debian.
Gentoo and FreeBSD avoid binary compatibility issues by only
distributing source packages, and doing automatic builds as part of the
installation process. Debian takes the opposite and difficult route: it
provides prebuilt binary packages, and so the maintainers have to take
binary compatibility into account.

Also, Gentoo seems to favour completeness over consistency; they
provide several versions of GNAT (both GPL Edition and from the FSF)
and let the user decide which one they would prefer. They don't seem to
have a very strong policy as regards configuration management; they let
their users do that for themselves, with help from the package manager.
The GNU Ada Project seems to take the same route. In Debian, again I
take the opposite and difficult route favouring consistency over
completeness: I provide only one version of GNAT (namely GCC 4.1) but
make sure everything works together.

-- 
Ludovic Brenta.