Bug#393636: gnat-gps appears to be completely unusable...
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 before... I have not seen this crash. In my experience, gnat-gps is now mostly usable and I think it should be allowed into testing. The crashes I reported in #393636 are gone, and so are those you reported that were due to elaboration problems. That's why I closed this bug. I suggest you file a new bug with the doubly-linked list problem, with steps to reproduce and severity Important. Also I think it is time to replace the all-catching, vague bug report with more precise ones which I can then forward upstream with some hope to see them fixed. BTW, I'm running Etch not sid; if the problem happens consistently on Sid and not on Etch, then this is evidence that the problem is in some other library. And yes I now run amd64, too :) -- Ludovic Brenta. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#393636: gnat-gps appears to be completely unusable...
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 the ones we're interested in. The patches from 4.0.0 applied cleanly, but I also had to add a small patch for GtkAda 2.8.1. With both 4.0.0 and 4.0.1, I get slightly different symptoms from you: (1) GPS hangs, but does not crash, when trying to open a file selector. I too suspect something wrong in GtkAda. Unfortunately there is no unit test for the file selector. Maybe it would be worthwhile to write one. (unless I missed something in testgtk? Look in /usr/share/doc/libgtkada2-doc/examples/testgtk.tar.gz) Hmm...it still crashes on me, consistently. I get the following message: *** glibc detected *** corrupted double-linked list: 0x01b39820 *** Aborted ==22897== Invalid read of size 8 ==22897==at 0x601684E: system__finalization_implementation__attach_to_final_list (in /usr/lib/libgnat-4.1.so.1) Mmm. I don't know what to make of that. I'd like to see a stack trace at that point, is that possible? I'm not sure how to get a stacktrace of a process that's being run underneath valgrind, or if it's even possible. That's something I'll have to investigate. It would be quite nice... By the way, why'd you close this bug? On amd64 the bug is just as valid now as it was before... -- Kevin Brown [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#393636: gnat-gps appears to be completely unusable...
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]
Bug#393636: gnat-gps appears to be completely unusable...
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. The patches from 4.0.0 applied cleanly, but I also had to add a small patch for GtkAda 2.8.1. With both 4.0.0 and 4.0.1, I get slightly different symptoms from you: (1) GPS hangs, but does not crash, when trying to open a file selector. I too suspect something wrong in GtkAda. Unfortunately there is no unit test for the file selector. Maybe it would be worthwhile to write one. (unless I missed something in testgtk? Look in /usr/share/doc/libgtkada2-doc/examples/testgtk.tar.gz) (2) GPS crashes when clicking on the Naming tab in the project properties. Before it crashes, it opens a message box saying: Unexpected fatal error, GPS is in an inconsistent state Please report with contents of /home/lbrenta/.gps/log.18230 You will be asked to save modified files before GPS exits (the number in the log file name is the PID; it will change at each run). The last 4 lines in the log file read: [UNEXPECTED_EXCEPTION] 1/55 Unexpected exception Exception name: CONSTRAINT_ERROR _UNEXPECTED_EXCEPTION_ Message: project_properties.adb:3635 access check failed (2006-11-28 01:15:22.526) [UNEXPECTED_EXCEPTION] 2/56 Unhandled exception: Exception name: CONSTRAINT_ERROR _UNEXPECTED_EXCEPTION_ Message: project_properties.adb:3635 access check failed (2006-11-28 01:15:24.102) which is the same bug as I had in 3.1.3. That's why I said that 4.0.0 or 4.0.1 are no worse than 3.1.3. ==22897== Invalid read of size 8 ==22897==at 0x601684E: system__finalization_implementation__attach_to_final_list (in /usr/lib/libgnat-4.1.so.1) Mmm. I don't know what to make of that. I'd like to see a stack trace at that point, is that possible? -- Ludovic Brenta. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#393636: gnat-gps appears to be completely unusable...
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 :). As a result, I've been able to update patches/elaboration.patch to the point where gnat-gps 4.0.0 survives gnatbind's pessimistic elaboration order. Now it crashes with a Constraint_Error (access check failed) when clicking on a tab in the project properties notebook. Since this situation is no worse than that in 3.1.3, I'm going to upload 4.0.0-1. This build was made with -01, dynamic elaboration checks (-gnatE), stack checking (which requires an additional patch), and pessimistic elaboration order. If I ever fix this bug, I'll revert to more classical -O2, static elaboration checks and optimised elaboration order. The build scripts etc. are, of course, in the Monotone database for those interested (see http://www.ada-france.org/article130.html for French instructions, and the archives of comp.lang.ada for an English translation). PS. I'll upload amd64 instead of i386 binaries; wait for the buildds to produce 32-bit binaries. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#393636: gnat-gps appears to be completely unusable...
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 === --- common/src/basic_mapper.ads.orig2006-10-23 09:18:37.0 +0200 +++ common/src/basic_mapper.ads 2006-10-23 09:18:56.0 +0200 @@ -24,6 +24,8 @@ with String_Hash; with GNAT.OS_Lib; use GNAT.OS_Lib; +pragma Elaborate_All (String_Hash); + package Basic_Mapper is type File_Mapper is limited private; -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#393636: gnat-gps appears to be completely unusable...
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. Nevertheless, the following patch (applied in Monotone in branch org.debian.gnat-gps.3.1.3) should take care of the Program_Error. Applied. Thanks! I applied the same fix to the other two files that use String_Hash. And the end result? It still crashes, but it doesn't smash the stack while doing so like it did before. And using the new file button actually works. Debugging under gdb doesn't work with the -gstabs+ option because the debugger isn't able to access any of the stack-allocated objects in the Ada code. See: http://www.mail-archive.com/osg-users@openscenegraph.net/msg04734.html I switched gps.gpr over to -ggdb and all is well on that front now. It's currently crashing in a free that's being called from glib.convert.locale_from_utf8(). I'm in the process of compiling up libgtkada2-2.8.1 with full debugging. -- Kevin Brown [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#393636: gnat-gps appears to be completely unusable...
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? That would be preferable, IMO. No, you get one or the other: static by default, dynamic with -gnatE. They are incompatible, since their purpose is to find an elaboration order, and two different elaboration orders don't make sense in the same program :) The static model is better anyway. If you would like to push GPS to its limits, maybe try: package Binder is for Default_Switches (Ada) use (-p); end Binder; This causes the binder to try and find the *worst* possible elaboration order, i.e. the one that *maximises* the chances to get a Program_Error during elaboration. If GPS survives that, then it's really good :) And the end result? It still crashes, but it doesn't smash the stack while doing so like it did before. And using the new file button actually works. Aha! Progress! Congratulations! Was that with 3.1.3 or with 4.0.0? If 4.0.0, I'll try to apply the patches too and see if they improve things. Could you send the full patch? Debugging under gdb doesn't work with the -gstabs+ option because the debugger isn't able to access any of the stack-allocated objects in the Ada code. See: http://www.mail-archive.com/osg-users@openscenegraph.net/msg04734.html I switched gps.gpr over to -ggdb and all is well on that front now. Great. -gstabs+ was only necessary when debugging with the old gnat-gdb 5.3; the new gdb 6.4 understands GCC's new format for debugging information, DWARF2 (see #274164). It's currently crashing in a free that's being called from glib.convert.locale_from_utf8(). I'm in the process of compiling up libgtkada2-2.8.1 with full debugging. Maybe you should consider linking statically with libgtkada2.a, it already contains debugging information. You don't have to recompile the world. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#393636: gnat-gps appears to be completely unusable...
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 better; please revert the 3 patches with Elaborate_All and apply this one instead. Committed to Monotone. -- Ludovic Brenta. Index: common/src/string_hash.ads === --- common/src/string_hash.ads.orig 2006-10-23 22:45:38.0 +0200 +++ common/src/string_hash.ads 2006-10-23 22:45:48.0 +0200 @@ -33,6 +33,7 @@ -- Whether keys are case-sensitive package String_Hash is + pragma Elaborate_Body; type Name_Htable_Num is new Natural range 0 .. 1000; -- ??? This limitation should be raised. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#393636: gnat-gps appears to be completely unusable...
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 That line is this: package Double_String_Table is new String_Hash (String_Access, False_Free, No_Element); I did the same thing with gnat-gps-4.0.0 and got exactly the same error at exactly the same place: basic_mapper.ads:76. Any ideas on how to address this, or at least how to figure out what exactly it thinks is being accessed before elaboration? -- Kevin Brown [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#393636: gnat-gps appears to be completely unusable...
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 PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#393636: gnat-gps appears to be completely unusable...
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 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 That line is this: package Double_String_Table is new String_Hash (String_Access, False_Free, No_Element); What do I have to do to fix this? -- Kevin Brown [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#393636: gnat-gps appears to be completely unusable...
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 than 4.0.0 does; it does not have that particular bug, it has other, less critical ones instead. If you would like to experiment with 4.0.0, you need to get my build scripts and patches from my Monotone database. The work is completed, i.e. the scripts and patches produce an executable that reproduces your bug even on i386. You can find full instructions for doing that in the archives of comp.lang.ada for Sept 25, 2006; look at the first message in the thread ANNOUNCE: Debian build scripts on a public Monotone server. The file gnat-gps_4.0.0.orig.tar.gz is in http://www.ada-france.org/debian/pool. You need to check out the branch org.debian.gnat-gps as opposed to org.debian.gnat-gps.3.1.3. If you manage to patch 4.0.0 to fix that nasty Storage_Error, I will consider switching to that in Debian. In the mean time, 3.1.3 on i386 is a little less buggy. I'm compiling with a bunch of additional switches now and getting a bunch of warnings, some of which are very definitely indicative of this application not being 64-bit clean, such as: [...] Wow, that's disturbing, and it suggests that maybe, switching to 4.0.0 might be worthwhile indeed. Could you try to compile it and see if it produces the same warnings? I seem to remember that AdaCore does have a 64-bit version of GPS somewhere. Maybe they introduced that feature only in 4.0.0. I made the exception for gvd-canvas.adb in order to get it past the compiler bug, and for codefix-text_manager.adb because with '-fstack-check' it would throw the following compiler error: codefix-text_manager.adb:2301:45: dynamically tagged expression not allowed I'd like to somehow fix the source so that the tagged expression error doesn't occur with -fstack-check but I don't know how to fix that type of error just yet. What exactly does it imply in this context? Easy. $ quilt pop -a # unapply all patches Then, edit the file patches/series. Uncomment the line that mentions patches/dynamically-tagged-expressions.patch. Then: $ quilt push -a # reapply all patches Then you can remove the special case for codefix-text_manager.adb and recompile. (in fact, I made patches/dynamically-tagged-expressions.patch for GPS 4.0.0, but I think it applies cleanly on 3.1.3 as well.) Finally, I get lots of warnings like this with '-fstack-check': /usr/src/Debian/Ada/GPS/3.1.3-3/gnat-gps-3.1.3/gps/src/gps-main.adb:1676: warning: frame size too large for reliable stack checking How can I increase whatever limit it's using to determine that the frame size is too large? I also saw these warnings but I have no idea how to make them go away. I suggest you run that question on [EMAIL PROTECTED] (family problems at home are sucking my time since Saturday; sorry that I can't help you more. I hope encouragements will help. I'm with you, Kevin :) ) -- Ludovic Brenta. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#393636: gnat-gps appears to be completely unusable...
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 just as in the other gdb run. Here's what it looks like just the same: [EMAIL PROTECTED]:~$ LD_LIBRARY_PATH=/usr/lib/debug gnatgdb /usr/src/Debian/Ada/GPS/3.1.3-3/gnat-gps-3.1.3/gnat-gps GNU gdb 6.4 for GNAT Pro 2006 (20060522) Copyright 2005 Free Software Foundation, Inc. Ada Core Technologies version of GDB for GNAT Professional GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. See your support agreement for details of warranty and support. If you do not have a current support agreement, then there is absolutely no warranty for this version of GDB. Type show warranty for details. This GDB was configured as x86_64-linux-gnu...Using host libthread_db library /usr/lib/debug/libthread_db.so.1. (gdb) run Starting program: /usr/src/Debian/Ada/GPS/3.1.3-3/gnat-gps-3.1.3/gnat-gps [Thread debugging using libthread_db enabled] [New Thread 47757512239440 (LWP 9045)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 47757512239440 (LWP 9045)] signal_key_cmp (node1=0x15731fd, node2=0xfda02b00) at gsignal.c:700 700 gsignal.c: No such file or directory. in gsignal.c Current language: auto; currently c (gdb) where #0 signal_key_cmp (node1=0x15731fd, node2=0xfda02b00) at gsignal.c:700 #1 0x2b6f67a98e85 in signal_parse_name (name=value optimized out, itype=value optimized out, detail_p=0x1, force_quark=9) at gbsearcharray.h:163 #2 0x01809650 in C.920.17735 () #3 0x7fb3d830 in ?? () #4 0x7fb40560 in ?? () (gdb) cont Continuing. raised STORAGE_ERROR : s-intman.adb:158 explicit raise Program exited with code 01. (gdb) -- Kevin Brown [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#393636: gnat-gps appears to be completely unusable...
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 file for that matter. If the exception is the same as what I'm getting here, then chances are it's generating a SIGSEGV. 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. :-) I'm compiling with a bunch of additional switches now and getting a bunch of warnings, some of which are very definitely indicative of this application not being 64-bit clean, such as: ada_module.adb:205:13: warning: types for unchecked conversion have different sizes ada_module.adb:205:13: warning: size of Gulong is 64, size of Discrete_Type is 32 ada_module.adb:205:13: warning: 32 high order bits of source will be ignored That might be bad, but this looks to be much worse: gps-kernel-modules.adb:1274:13: warning: types for unchecked conversion have different sizes gps-kernel-modules.adb:1274:13: warning: size of BASE_TYPE is 32, size of ADDRESS is 64 gps-kernel-modules.adb:1274:13: warning: source will be extended with 32 high order sign bits Such errors can be found in a number of places. Here are the Builder and Compiler package stanzas I'm using in gps.gpr: package Builder is for Default_Switches (Ada) use (-k, -a, -m); for Executable (gps-main) use gnat-gps; end Builder; package Compiler is for Default_Switches (Ada) use (-g, -O0, -gnatafno, -gnatVa, -fstack-check, -gnatE, -gnatD); for Switches (gvd-canvas.adb) use (-O0, -gnatafno, -gnatVa, -fstack-check, -gnatE, -gnatD); for Switches (codefix-text_manager.adb) use (-g, -O0, -gnatafno, -gnatVa, -gnatE, -gnatD); end Compiler; I also added -g to the Default_Switches list for the Linker package. I made the exception for gvd-canvas.adb in order to get it past the compiler bug, and for codefix-text_manager.adb because with '-fstack-check' it would throw the following compiler error: codefix-text_manager.adb:2301:45: dynamically tagged expression not allowed I'd like to somehow fix the source so that the tagged expression error doesn't occur with -fstack-check but I don't know how to fix that type of error just yet. What exactly does it imply in this context? Finally, I get lots of warnings like this with '-fstack-check': /usr/src/Debian/Ada/GPS/3.1.3-3/gnat-gps-3.1.3/gps/src/gps-main.adb:1676: warning: frame size too large for reliable stack checking How can I increase whatever limit it's using to determine that the frame size is too large? -- Kevin Brown [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#393636: gnat-gps appears to be completely unusable...
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 (hello.gpr), it acts as if it didn't open anything, and a second attempt to open the project (or, indeed, to open any file at all) throws this error: raised STORAGE_ERROR : s-intman.adb:158 explicit raise The above also occurs when I tell it to start with a default project in any directory and then attempt to open a file. If I attempt to create a new standalone project with the wizard, gnat-gps goes into an infinite loop and appears to never come out of it. The bottom line is that, at least on the amd64 platform, gnat-gps appears to be completely unusable. I'll be happy to help debug this however I can, but keep in mind that I'm rather new to Ada (it's been 15 years or so since I've done anything with it, and that was only a college course at that). -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-2-amd64-generic Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages gnat-gps depends on: ii libc62.3.6.ds1-4 GNU C Library: Shared libraries ii libgcc1 1:4.1.1-13 GCC support library ii libglib2.0-0 2.12.3-2The GLib library of C routines ii libgnat-4.1 4.1.1-15Runtime library for GNU Ada applic ii libgnatprj4.14.1.1-15GNU Ada Project Manager ii libgnatvsn4.14.1.1-15GNU Ada compiler version library ii libgtk2.0-0 2.8.20-1The GTK+ graphical user interface ii libgtkada-2.82.8.1-4 Ada binding for the GTK library ii libpango1.0-01.14.5-1Layout and rendering of internatio ii libtemplates-parser1010.0+20060522-4 Ada library to parse files and rep ii python2.42.4.3-8 An interactive high-level object-o ii tcl8.4 8.4.12-1.1 Tcl (the Tool Command Language) v8 Versions of packages gnat-gps recommends: ii ada-reference-m 20021112web-3The standard describing the Ada 95 ii gnat4.1.1-11 The GNU Ada compiler ii gnat-gdb5.3.gnat.0.0.20030225-12 Ada-aware version of GDB pn gnat-gps-docnone (no description available) -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#393636: gnat-gps appears to be completely unusable...
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]
Bug#393636: gnat-gps appears to be completely unusable...
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, ...); 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. I grabbed the 3.1.3-3 source and am building that. With the default build options (no -g) it builds fine but behaves the same way as 3.1.3-2. With the -g option added to Default_Switches, I get the following: gcc-4.1 -c -g -gnatafno -gnatVa -I- -gnatA /usr/src/Debian/Ada/GPS/3.1.3-3/gnat-gps-3.1.3/gvd/gvd/gvd-canvas.adb +===GNAT BUG DETECTED==+ | 4.1.2 20060928 (prerelease) (Debian 4.1.1-15) (x86_64-pc-linux-gnu) GCC error:| | in splice_child_die, at dwarf2out.c:5503 | | Error detected at histories.ads:191:15 | | Please submit a bug report; see http://gcc.gnu.org/bugs.html. | | Use a subject line meaningful to you and us to track the bug. | | Include the entire contents of this bug box in the report. | | Include the exact gcc-4.1 or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. with a nice long list of files. :-( 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 :/ Hmm...I'll experiment a bit with that. -- Kevin Brown [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#393636: gnat-gps appears to be completely unusable...
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 with the options specified. I don't know which options you should change or remove. Removing -g will definitely get the file to compile but without debugging information. PS. This is a bug in gnat-4.1. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#393636: gnat-gps appears to be completely unusable...
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 compilation error. (what I actually did was to retain the use of -g in package Builder and to change the -O2 in Compiler's Default_Switches to -O0, but that's equivalent for gvd-canvas.adb) -- Kevin Brown [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#393636: gnat-gps appears to be completely unusable...
Kevin Brown [EMAIL PROTECTED] writes: (what I actually did was to retain the use of -g in package Builder and to change the -O2 in Compiler's Default_Switches to -O0, but that's equivalent for gvd-canvas.adb) Have you tried removing -gnatafno and -gnatVa? If that fails too, then it'll be necessary to resort to removing -g for that one file. That was the quick approach I did, but I wasn't satisfied with it. You can keep -g in package Builder and add -g0 (force no debugging information) in Switches (gvd-canvas.adb). Take faith :) -- Ludovic Brenta. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#393636: gnat-gps appears to be completely unusable...
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 yields the same compilation error. That said, just to test things I disabled -g just for that one source file to get it past it. It turns out that (if I remember -- I'm away from that computer at the moment) it's the last file to be compiled prior to linking. I tried using gnatgdb against the resulting file but it seems unable to attach to the resulting LWP that gets created. 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. GDB puts me into C mode, which isn't going to help a whole lot for debugging this. Why can't I run gnatgdb against this? -- Kevin Brown [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#393636: gnat-gps appears to be completely unusable...
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 PROTECTED]:/usr/src/Debian/Ada/GPS/3.1.3-3/gnat-gps-3.1.3$ gdb gnat-gps GNU gdb 6.4.90-debian Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as x86_64-linux-gnu...Using host libthread_db library /lib/libthread_db.so.1. (gdb) run Starting program: /usr/src/Debian/Ada/GPS/3.1.3-3/gnat-gps-3.1.3/gnat-gps [Thread debugging using libthread_db enabled] [New Thread 46951004957008 (LWP 31813)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 46951004957008 (LWP 31813)] 0x2ab3a0150e3c in signal_parse_name (name=0x7ff029b8 Pp$\002, itype=value optimized out, detail_p=0x85a2e482322a, force_quark=-1281144710) at gsignal.c:281 281 gsignal.c: No such file or directory. in gsignal.c Current language: auto; currently c (gdb) where #0 0x2ab3a0150e3c in signal_parse_name (name=0x7ff029b8 Pp$\002, itype=value optimized out, detail_p=0x85a2e482322a, force_quark=-1281144710) at gsignal.c:281 #1 0x in ?? () (gdb) cont Continuing. raised STORAGE_ERROR : s-intman.adb:158 explicit raise Program exited with code 01. (gdb) quit The SIGSEGV occurred when I tried to open a file. This doesn't look very useful, especially given that I can't even get a traceback. :-( -- Kevin Brown [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#393636: gnat-gps appears to be completely unusable...
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]
