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 Redmond's
stuff, too, so I paid no "tax" on it :).
Drool...
PS. I'll upload amd64 instead of i386 binaries; wait for the buildds
to produce 32-bit binaries.
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.
Tracking down this issue is proving to be a real headache. The crashes
come in two forms: SIGSEGV when allocating or freeing memory (often
preceded by glibc throwing a notice of corrupt memory), and an unfielded
SIGABRT, often also preceded by the same glibc message. The unhandled
SIGABRT is particularly annoying, since it seems that all sorts of
signals get thrown around within the application, so I can't just set up
my debugger to stop on SIGABRT.
It's crashing prior to throwing up the file selector dialog box, or
sometimes while it's in the process of doing so. When it manages to get
the file selector on the screen, some of the text (e.g., the current
directory) is corrupt. So it's definitely a memory corruption issue.
I have a nasty suspicion that the problem is in the Ada GTK binding
libraries, but I can't at all be certain of that at this point.
Are there any unit tests of the Ada GTK binding library? Running them
under something like Valgrind or Electric Fence might reveal bugs that
would be difficult to find in something more complex like GNAT-GPS.
That said, valgrind against the new GNAT-GPS binary you released shows
something interesting:
==22897== Invalid write of size 8
==22897== at 0x60166AF:
system__finalization_implementation__detach_from_final_list (in
/usr/lib/libgnat-4.1.so.1)
==22897== by 0x601674D:
system__finalization_implementation__finalize_one (in
/usr/lib/libgnat-4.1.so.1)
There are 3 of those, as well as one of these:
==22897== Invalid read of size 8
==22897== at 0x601684E:
system__finalization_implementation__attach_to_final_list (in
/usr/lib/libgnat-4.1.so.1)
These sound to me like they are attempting to read/write pointers, but
what was allocated was an int.
And this is also interesting (there are 4 of these):
==22897== Address 0xA088160 is 120 bytes inside a block of size 968 free'd
Anyway, I'll keep working on it as I find the time, but it's tough going
at the moment...
--
Kevin Brown [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
