Kevin Brown [EMAIL PROTECTED] writes:
Hmm...it still crashes on me, consistently. I get the following
message:
*** glibc detected *** corrupted double-linked list: 0x01b39820 ***
Aborted
[...]
By the way, why'd you close this bug? On amd64 the bug is just as
valid now as it was
Ludovic Brenta wrote:
Kevin Brown [EMAIL PROTECTED] writes:
Sounds like I'll wanna grab the current source, but it also sounds
like the changes you made and the changes I made are quite similar.
Yes, and I just uploaded 4.0.1 which, according to its change log,
fixes a few bugs, but not
Ludovic Brenta wrote:
I've just received a new laptop to replace my old IBM ThinkPad T22.
The build time for gnat-gps went down from 220 minutes to 17 minutes.
It's an HP Compaq nx6325 with dual-core AMD Turion 64x2 TL-60 @2GHz,
and 2 GB of RAM. Got it with FreeDOS preloaded instead of
Kevin Brown [EMAIL PROTECTED] writes:
Sounds like I'll wanna grab the current source, but it also sounds
like the changes you made and the changes I made are quite similar.
Yes, and I just uploaded 4.0.1 which, according to its change log,
fixes a few bugs, but not the ones we're interested in.
I've just received a new laptop to replace my old IBM ThinkPad T22.
The build time for gnat-gps went down from 220 minutes to 17 minutes.
It's an HP Compaq nx6325 with dual-core AMD Turion 64x2 TL-60 @2GHz,
and 2 GB of RAM. Got it with FreeDOS preloaded instead of Redmond's
stuff, too, so I paid
I don't think -gnatE buys you anything, as GNAT's default, static
elaboration model is more strict. Nevertheless, the following patch
(applied in Monotone in branch org.debian.gnat-gps.3.1.3) should take
care of the Program_Error.
--
Ludovic Brenta.
Index: common/src/basic_mapper.ads
Ludovic Brenta wrote:
I don't think -gnatE buys you anything, as GNAT's default, static
elaboration model is more strict.
Is the static elaboration model always in force? That is, if I use
-gnatE, do I get both static *and* dynamic elaboration checks? That
would be preferable, IMO.
Kevin Brown [EMAIL PROTECTED] writes:
Ludovic Brenta wrote:
I don't think -gnatE buys you anything, as GNAT's default, static
elaboration model is more strict.
Is the static elaboration model always in force? That is, if I use
-gnatE, do I get both static *and* dynamic elaboration checks?
Kevin Brown [EMAIL PROTECTED] writes:
Applied. Thanks! I applied the same fix to the other two files that
use String_Hash.
I hadn't noticed that String_Hash was part of GPS (I thought it was
part of GNAT), and that it was being used in several places. In that
case, the following patch is
I wrote:
Family comes first. Take your time. This is not by any means urgent
at all.
By the way, I compiled with -gnatE so that it would do runtime
elaboration checks. Now when I run the program I get this:
raised PROGRAM_ERROR : basic_mapper.ads:76 access before elaboration
Yes, now the fun begins. You can say break exception and look at the
backtrace at the point where the exception was raised.
Sorry I can't be of any more help right now, my wife and baby son are
both ill and I need to take care of them.
--
Ludovic Brenta.
--
To UNSUBSCRIBE, email to [EMAIL
Ludovic Brenta wrote:
Yes, now the fun begins. You can say break exception and look at the
backtrace at the point where the exception was raised.
Sorry I can't be of any more help right now, my wife and baby son are
both ill and I need to take care of them.
Family comes first. Take your
Given the problems that 3.1.3 seems to be having, it sounds like it
might be worth our while to concentrate on 4.0.0 instead. But since
you're the primary maintainer, that's your call. :-)
Mmh, you're right, they do look like they're the same bug. As I said,
3.1.3 works much better on i386
I wrote:
Why can't I run gnatgdb against this?
Turns out that the version of gnat-gdb in -testing is rather old: from
2003! Upgrading to the version in -unstable fixed this problem, and
it's now able to attach to the LWP.
Not that it helped a whole lot. The stack trace looks like it's
smashed
Ludovic Brenta wrote:
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
Package: gnat-gps
Version: 3.1.3-2
Severity: grave
Justification: renders package unusable
Note that I am using the amd64 version, so that may be relevant here. I
haven't tried using the i386 version.
Basically, it seems that gnat-gps is completely unusable. If I open an
existing project
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
Ludovic Brenta wrote:
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, ...);
Hi Kevin,
Thanks for trying to help. Try this in gps.gpr:
package Compiler is
for Default_Switches (Ada) use ... (do not change)
for Switches (gvd-canvas.adb) use (-g, -O0);
end Compiler;
and do debian/rules gnat-gps again. This should not recompile
everything, just the offending file
Ludovic Brenta wrote:
Hi Kevin,
Thanks for trying to help. Try this in gps.gpr:
package Compiler is
for Default_Switches (Ada) use ... (do not change)
for Switches (gvd-canvas.adb) use (-g, -O0);
end Compiler;
and do debian/rules gnat-gps again.
This yields the same
I wrote:
Ludovic Brenta wrote:
Hi Kevin,
Thanks for trying to help. Try this in gps.gpr:
package Compiler is
for Default_Switches (Ada) use ... (do not change)
for Switches (gvd-canvas.adb) use (-g, -O0);
end Compiler;
and do debian/rules gnat-gps again.
This
I wrote:
GDB gives better results. When running the program, the program winds
up getting a SIGSEGV. It looks to me like the storage manager catches
that and raises its own exception.
Here's the results of a gdb run against the binary:
[EMAIL
Why can't I run gnatgdb against this?
You need gnatgdb from unstable. It works for me. gnatgdb 5.3 won't work.
--
Ludovic Brenta.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
23 matches
Mail list logo