Hi Kevin,
Your help will be definitely appreciated.
At first, I wanted to replace GPS 2.1.0 with the newest version, 4.0.0.
I had some trouble compiling it but finally succeeded and found that it
would crash with a Storage_Error whenever opening a project, or any file
for that matter. I was unable to fix that, but I did make sure the
problem was neither in GtkAda 2.8.1 nor in the compiler (tried -O0). So
I reverted to GPS 3.1.3, and I had to patch it so it would compile with
GtkAda 2.8.1. That's what is now in unstable. It starts and it can
read files and the options dialogue boxes work, but I too have had some
crashes. I tried to debug but family problems at home made that
impossible. So, your help will be appreciated, definitely.
The crashes I experienced were due to explicit raises, not
Storage_Error. And I did not see the infinite loop you report, either.
As I said, many parts of GPS do work, but if you can't edit project
properties (as in my experience), the thing is pretty much useless, so I
agree that the bug is grave.
GPS consists of ~280.000 lines of code, not counting blank or comment
lines, and not counting GtkAda which is itself another 90.000 lines.
Luckily, the source is very clear and well commented.
If you would like to help debug GPS, please start by downloading the
source package and editing the top-level "gps.gpr" file. Look for
package Builder, and add "-g" to the Default_Switches ("Ada") line, e.g.
package Builder is
for Default_Switches ("Ada") use ("-g", ...);
end Builder;
then do "debian/rules gnat-gps". After a long time (3h40 on my old
laptop but only 48 minutes on an AMD64 buildd) you will end up with a
large file called gnat-gps, containing debugging information. You can
run that under gdb or (better) gnatgdb from the package gnat-gdb. The
latter allows you to break on exceptions ("break exception"), so you can
see where the Storage_Error is being raised.
You may also want to try removing all compiler options; maybe the
compiler is emitting wrong code or something. In particular, I usually
compile with -gnato (full range checks, so we could get a
Constraint_Error) and -gnatVa (full optional run-time checks, which can
raise various exceptions). If you remove these options, you'll stand a
lesser chance of getting exceptions and a higher chance of getting
random memory corruption and segfaults :/
I keep my compiler scripts and patches in a Monotone database which is
available for anonymous access; please tell me if you're interested.
--
Ludovic Brenta.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
