From: Jerry <lan...@qw...> - 2008-08-26 00:24:05
Attachments:
Temp_PLplot_Ada_Example 19
|
> > On 2008-08-23 18:54-0700 Jerry wrote: > > >> There have been some posts about Ada example 19 (both x19a.adb and >> xthick19a.adb) causing problems, possibly on 64-bit systems but not >> 32-bit systems. >> >> Fortunately, example 19 is short. >> >> Unfortunately, example 19 runs fine on my machine, OS X. >> >> Could someone send me detailed info about what happens? On 7/18/08, >> Alan indicated this runtime error: >> >> raised STORAGE_ERROR : stack overflow (or erroneous memory >> access) >> > > That is the only message that is given. > > >> >> This is an Ada exception being raised. Was there a line number >> associated with this output? >> > > Unfortunately, not. > > >> >> I would like to try to find, as exactly as possible, where this >> problem is arising. >> > > I surrounded the plmap and plmeridians calls with > > if 0 =/0 then > end if; > > then selectively tried > > if 0 =/1 then > > It turns out the first two plmap(null... calls generate no run-time > error, > but that both the plmap(mapform19'Unrestricted_Access... > and plmeridians(mapform19'Unrestricted_Access... calls individually > generate > the above run-time error. > > BTW, I notice the x16a.adb callbacks are specified with a different > access method that does not seem to generate a run-time error, i.e., > > plshades(... plfill'access, True, pltr1'access, cgrid1'Address); > > Is it possible to use that method instead for example 19? > > I simply tried plmap(mapform19'access... > > but that generated a build error of > x19a.adb:113:13: subprogram must not be deeper than access type > x19a.adb:118:19: subprogram must not be deeper than access type > make[2]: *** [examples/ada/CMakeFiles/x19a.dir/x19a.o] Error 1 > > I don't understand why this won't build (probably because my Ada > languague > skills are so limited) since pltr1, for example, is an Ada > procedure similar > to mapform19. > > If there is no easy way to mimic what example 16 does, then at > least I have > pinned down two separate instances of one line of code that > generates the > run-time error, and I hope you can use that to generate a self- > contained > test example that is completely independent of PLplot that I can try. > > Alan > > Attached is a zip file with three short Ada files in it. They have a similar structure to the problematic example 19 but do not call or link to any PLplot stuff (despite the names of some things looking PLplot-y). Alan (or someone else with a 64-bit Ada compiler), if you would, please unzip, cd to the directory, and type gnatmake ./x19a_temp.adb You should see two warnings but no errors. If it compiles, the executable will be called x19a_temp. Try to run it and see what happens. It should print out 10 lines of floats. I think there is a low probability that this will point to a compiler error but we need to try it anyway. This compiles and runs OK on my system. Jerry P.S. My e-mail service (Qwest in U.S.) apparently blocks attachments with the .zip appendage. |
From: Alan W. I. <ir...@be...> - 2008-08-26 03:18:06
Attachments:
simple_test_case.tar.gz
|
On 2008-08-25 17:24-0700 Jerry wrote: > Attached is a zip file with three short Ada files in it. They have a similar > structure to the problematic example 19 but do not call or link to any PLplot > stuff (despite the names of some things looking PLplot-y). > > Alan (or someone else with a 64-bit Ada compiler), if you would, please > unzip, cd to the directory, and type > > gnatmake ./x19a_temp.adb > > You should see two warnings but no errors. If it compiles... It does not compile on Linux. Here is the error message: irwin@raven> gnatmake ./x19a_temp.adb gcc-4.3 -c -I./ -I- ./x19a_temp.adb x19a_temp.adb:2:05: file "type_declaration.ads" not found gnatmake: "./x19a_temp.adb" compilation error There is something strange about how case is interpreted by gnatmake on Linux. Anyhow, I converted everything (file names and symbols inside the file) to lower-case type_declaration, and the result compiles. irwin@raven> gnatmake x19a_temp.adb gcc-4.3 -c x19a_temp.adb x19a_temp.adb:10:38: warning: type of argument "mapform19.x" is unconstrained array x19a_temp.adb:10:38: warning: foreign caller must pass bounds explicitly gcc-4.3 -c type_declaration.adb gnatbind -x x19a_temp.ali gnatlink x19a_temp.ali I have attached a compressed tarball with the corrected files for this test case that compiles on Linux (and hopefully MacOSX as well). We now have a working simple test case that generates the run-time error (at least on my 64-bit box with gnat version 4.3.1-2). irwin@raven> ./x19a_temp raised STORAGE_ERROR : stack overflow (or erroneous memory access) Jerry, did the compressed tarball attachment survive your ISP? If so does it compile and run properly for you? Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Jerry <lan...@qw...> - 2008-08-26 05:02:40
|
On Aug 25, 2008, at 8:18 PM, Alan W. Irwin wrote: > On 2008-08-25 17:24-0700 Jerry wrote: > >> Attached is a zip file with three short Ada files in it. They have >> a similar structure to the problematic example 19 but do not call >> or link to any PLplot stuff (despite the names of some things >> looking PLplot-y). >> >> Alan (or someone else with a 64-bit Ada compiler), if you would, >> please unzip, cd to the directory, and type >> >> gnatmake ./x19a_temp.adb >> >> You should see two warnings but no errors. If it compiles... > > It does not compile on Linux. Here is the error message: > > irwin@raven> gnatmake ./x19a_temp.adb > gcc-4.3 -c -I./ -I- ./x19a_temp.adb > x19a_temp.adb:2:05: file "type_declaration.ads" not found > gnatmake: "./x19a_temp.adb" compilation error > > There is something strange about how case is interpreted by > gnatmake on > Linux. Anyhow, I converted everything (file names and symbols > inside the > file) to lower-case type_declaration, and the result compiles. > > irwin@raven> gnatmake x19a_temp.adb > gcc-4.3 -c x19a_temp.adb > x19a_temp.adb:10:38: warning: type of argument "mapform19.x" is > unconstrained array > x19a_temp.adb:10:38: warning: foreign caller must pass bounds > explicitly > gcc-4.3 -c type_declaration.adb > gnatbind -x x19a_temp.ali > gnatlink x19a_temp.ali > > I have attached a compressed tarball with the corrected files for > this test > case that compiles on Linux (and hopefully MacOSX as well). > > We now have a working simple test case that generates the run-time > error (at > least on my 64-bit box with gnat version 4.3.1-2). > > irwin@raven> ./x19a_temp > > raised STORAGE_ERROR : stack overflow (or erroneous memory access) > > Jerry, did the compressed tarball attachment survive your ISP? If > so does it > compile and run properly for you? > > Alan > I got the tarball. It compiles and runs correctly on my machine. I'm running GNAT 4.3.0. So what do we do now? I'm inclined to post this example to comp.lang.ada but maybe I should just directly figure out how to file a bug report. Alan, remind me what OS and hardware you're running. There might be a way for me to change the 'Unrestricted_Access in example 19 to 'Access but it would involve moving the user-defined procedure mapform19 into the bindings, an ugly fix. I don't know if that would eliminate the run-time error but if it did it would at least allow example 19 to exist along with the others until another solution is found at the compiler level. Also, I wonder if the problem is related to the fact that C calling conventions are being enforced. Alan, if you want to, you could try commenting out those lines--when I do so, it still compiles and runs. Anything we learn from this won't help us PLplot-wise since we need the C calling convention but it might help the GNAT people if they look into this. That would be: In x19a_temp.adb, comment out, using --: procedure mapform19(n : Integer; x : in out Real_Vector); pragma Convention(C, mapform19); In type_declarations.ads, comment out: pragma Convention(Convention => C, Entity => Map_Form_Function_Pointer_Type); Jerry |
From: Alan W. I. <ir...@be...> - 2008-08-26 06:33:31
|
On 2008-08-25 22:02-0700 Jerry wrote: > > On Aug 25, 2008, at 8:18 PM, Alan W. Irwin wrote: > >> We now have a working simple test case that generates the run-time >> error (at >> least on my 64-bit box with gnat version 4.3.1-2). >> >> irwin@raven> ./x19a_temp >> >> raised STORAGE_ERROR : stack overflow (or erroneous memory access) To get a broader picture about this issue, I would appreciate it if everyone with access to gnat (it's a standard package on Debian and probably most other distros as well) try the simple example to make sure it always raises the above error at run-time on all 64-bit platforms and works fine (see output below) on all 32-bit platforms. Please include your distro, gnat version, and hardware with each report. >> >> Jerry, did the compressed tarball attachment survive your ISP? If >> so does it >> compile and run properly for you? >> >> Alan >> > I got the tarball. It compiles and runs correctly on my machine. > > I'm running GNAT 4.3.0. > > So what do we do now? I'm inclined to post this example to > comp.lang.ada but maybe I should just directly figure out how to file > a bug report. Alan, remind me what OS Debian lenny > and hardware you're running. 64-bit Intel duo processor. irwin@raven> uname -a Linux raven 2.6.25-2-amd64 #1 SMP Mon Jul 14 11:05:23 UTC 2008 x86_64 GNU/Linux > > [...]Also, I wonder if the problem is related to the fact that C calling > conventions are being enforced. Alan, if you want to, you could try > commenting out those lines--when I do so, it still compiles and runs. > Anything we learn from this won't help us PLplot-wise since we need > the C calling convention but it might help the GNAT people if they > look into this. That would be: > > In x19a_temp.adb, comment out, using --: > > procedure mapform19(n : Integer; x : in out Real_Vector); > pragma Convention(C, mapform19); > > In type_declarations.ads, comment out: > > pragma Convention(Convention => C, Entity => > Map_Form_Function_Pointer_Type); With those 3 lines commented out, the compiler warnings are gone and the programme works. irwin@raven> gnatmake x19a_temp.adb gcc-4.3 -c x19a_temp.adb gcc-4.3 -c type_declaration.adb gnatbind -x x19a_temp.ali gnatlink x19a_temp.ali irwin@raven> ./x19a_temp 0.00000000000000E+00 1.00000000000000E+00 2.00000000000000E+00 3.00000000000000E+00 4.00000000000000E+00 5.00000000000000E+00 6.00000000000000E+00 7.00000000000000E+00 8.00000000000000E+00 9.00000000000000E+00 I would try comp.ada.lang first with the simple example. If you don't get any quick help there (say within a few days) or if the response is the code should work fine on 64-bit platforms, then the next step would be to write a gnatmake bug report including the simple example and send it to Debian to start with. I would be willing to do that part of it since I write Debian bug reports quite often. If we don't get help from Debian, then the next step (or perhaps simultaneous step?) is to post the same bug report to the GCC gnat developers. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Andrew R. <and...@us...> - 2008-08-26 09:00:16
|
On Mon, Aug 25, 2008 at 11:33:40PM -0700, Alan Irwin wrote: > On 2008-08-25 22:02-0700 Jerry wrote: > > > > > On Aug 25, 2008, at 8:18 PM, Alan W. Irwin wrote: > > > >> We now have a working simple test case that generates the run-time > >> error (at > >> least on my 64-bit box with gnat version 4.3.1-2). > >> > >> irwin@raven> ./x19a_temp > >> > >> raised STORAGE_ERROR : stack overflow (or erroneous memory access) > > To get a broader picture about this issue, I would appreciate it if everyone > with access to gnat (it's a standard package on Debian and probably most > other distros as well) try the simple example to make sure it always raises > the above error at run-time on all 64-bit platforms and works fine (see > output below) on all 32-bit platforms. Please include your distro, gnat > version, and hardware with each report. > > >> > >> Jerry, did the compressed tarball attachment survive your ISP? If > >> so does it > >> compile and run properly for you? > >> > >> Alan > >> > > I got the tarball. It compiles and runs correctly on my machine. > > > > I'm running GNAT 4.3.0. > > > > So what do we do now? I'm inclined to post this example to > > comp.lang.ada but maybe I should just directly figure out how to file > > a bug report. Alan, remind me what OS Another report: both systems are Ubuntu Hardy with gnat 4.2.3, but one is 32-bit and the other 64-bit. 32-bit system - test case works fine 64-bit system - crashes with "raised STORAGE_ERROR : stack overflow (or erroneous memory access)" Andrew |
From: Jerry <lan...@qw...> - 2008-08-26 07:56:02
|
On Aug 25, 2008, at 11:33 PM, Alan W. Irwin wrote: > On 2008-08-25 22:02-0700 Jerry wrote: > >> >> On Aug 25, 2008, at 8:18 PM, Alan W. Irwin wrote: >> >>> We now have a working simple test case that generates the run-time >>> error (at >>> least on my 64-bit box with gnat version 4.3.1-2). >>> >>> irwin@raven> ./x19a_temp >>> >>> raised STORAGE_ERROR : stack overflow (or erroneous memory access) > > To get a broader picture about this issue, I would appreciate it if > everyone > with access to gnat (it's a standard package on Debian and probably > most > other distros as well) try the simple example to make sure it > always raises > the above error at run-time on all 64-bit platforms and works fine > (see > output below) on all 32-bit platforms. Please include your distro, > gnat > version, and hardware with each report. > >>> >>> Jerry, did the compressed tarball attachment survive your ISP? If >>> so does it >>> compile and run properly for you? >>> >>> Alan >>> >> I got the tarball. It compiles and runs correctly on my machine. >> >> I'm running GNAT 4.3.0. >> >> So what do we do now? I'm inclined to post this example to >> comp.lang.ada but maybe I should just directly figure out how to file >> a bug report. Alan, remind me what OS > > Debian lenny > >> and hardware you're running. > > 64-bit Intel duo processor. > > irwin@raven> uname -a > Linux raven 2.6.25-2-amd64 #1 SMP Mon Jul 14 11:05:23 UTC 2008 x86_64 > GNU/Linux > >> >> [...]Also, I wonder if the problem is related to the fact that C >> calling >> conventions are being enforced. Alan, if you want to, you could try >> commenting out those lines--when I do so, it still compiles and runs. >> Anything we learn from this won't help us PLplot-wise since we need >> the C calling convention but it might help the GNAT people if they >> look into this. That would be: >> >> In x19a_temp.adb, comment out, using --: >> >> procedure mapform19(n : Integer; x : in out Real_Vector); >> pragma Convention(C, mapform19); >> >> In type_declarations.ads, comment out: >> >> pragma Convention(Convention => C, Entity => >> Map_Form_Function_Pointer_Type); > > With those 3 lines commented out, the compiler warnings are gone > and the > programme works. > > irwin@raven> gnatmake x19a_temp.adb > gcc-4.3 -c x19a_temp.adb > gcc-4.3 -c type_declaration.adb > gnatbind -x x19a_temp.ali > gnatlink x19a_temp.ali > irwin@raven> ./x19a_temp > 0.00000000000000E+00 > 1.00000000000000E+00 > 2.00000000000000E+00 > 3.00000000000000E+00 > 4.00000000000000E+00 > 5.00000000000000E+00 > 6.00000000000000E+00 > 7.00000000000000E+00 > 8.00000000000000E+00 > 9.00000000000000E+00 > > I would try comp.ada.lang first with the simple example. If you > don't get > any quick help there (say within a few days) or if the response is > the code > should work fine on 64-bit platforms, then the next step would be > to write a > gnatmake bug report including the simple example and send it to > Debian to > start with. I would be willing to do that part of it since I write > Debian > bug reports quite often. If we don't get help from Debian, then the > next > step (or perhaps simultaneous step?) is to post the same bug report > to the > GCC gnat developers. > > Alan > FWIW, there is a second bug in this simple example code that appears on _my_ machine but there is an easy work-around that I've already implemented. But it should be mentioned in any bug reports that we file. In the procedure mapform19 there should be a line such as this, if normal Ada programming practice were followed: for i in x'range loop This begins a loop with the loop variable i which ranges over the extent of the indices of array x which in this case is 0 through 9. However, with the three "pragma Convention (C, foo)" lines _in_ (see earlier e-mail in this thread), the program spits out a bunch of bogus numbers (187 of them, it seems), then bombs with a segmentation fault. With the three lines _out_, it runs fine. The work-around is to replace the above line with for i in 0 .. n loop which runs OK with the three lines in or out. Finally, a dumb question. Is there any chance that floats, ints, doubles, etc. in C or Floats, Integers, Long_Floats, or Long_Integers in Ada have different sizes between languages on 64-bit boxes than on 32-bit boxes? Jerry |
From: Werner S. <sm...@ia...> - 2008-08-26 08:26:36
|
> Hi, > > Finally, a dumb question. Is there any chance that floats, ints, > doubles, etc. in C or Floats, Integers, Long_Floats, or Long_Integers > in Ada have different sizes between languages on 64-bit boxes than on > 32-bit boxes? float should always be 32bit, double always be 64bit in C. The type int is dependent on the machine you are using, so it can be 16bit, 32bit, 64bit. Very likely that on 64bit machines int is 64bit (but must not be). See e.g. http://en.wikipedia.org/wiki/C_variable_types_and_declarations . Regards, Werner -- Dr. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office), +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 |
From: Andrew R. <and...@us...> - 2008-08-26 08:46:43
|
On Tue, Aug 26, 2008 at 10:26:31AM +0200, Werner Smekal wrote: > > > Hi, > > > > > Finally, a dumb question. Is there any chance that floats, ints, > > doubles, etc. in C or Floats, Integers, Long_Floats, or Long_Integers > > in Ada have different sizes between languages on 64-bit boxes than on > > 32-bit boxes? > > float should always be 32bit, double always be 64bit in C. The type > int is dependent on the machine you are using, so it can be 16bit, > 32bit, 64bit. Very likely that on 64bit machines int is 64bit (but > must not be). See e.g. http://en.wikipedia.org/wiki/C_variable_types_and_declarations The C spec says that a long is at least as big as an int. Int must be at least 16 bits, and long at least 32 bits. long long (where implemented) must be at least 64 bits. 32 bit linux systems with gcc have int and long both as 32 bit. 64-bit linux gcc systems usually have int as 32 bit and long as 64 bit. The (usual) problem when porting C programs from 32 -> 64 bit is that the size of long differs. Andrew |
From: Alan W. I. <ir...@be...> - 2008-08-26 17:00:22
|
On 2008-08-26 00:56-0700 Jerry wrote: > Finally, a dumb question. Is there any chance that floats, ints, > doubles, etc. in C or Floats, Integers, Long_Floats, or Long_Integers > in Ada have different sizes between languages on 64-bit boxes than on > 32-bit boxes? I think there is a very good chance that the Ada language as implemented by gnat has different sizes for floats and especially integers than PLplot so maybe that is the source of the problem here. Recall that for the default PL_DOUBLE case, PLFLT is a double. Also, for platforms (32-bit or 64-bit) with access to stdint.h, PLINT is a 32-bit integer (int32_t, see include/plplot.h). My feeling is stdint.h (e.g., access to the C99 standard) is pretty common. Anyhow, it is available on my 64-bit computer. Thus, if Ada is assuming a 64-bit integers on 64-bit platforms, that would not be the same size as PLINT on my computer. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Jerry <lan...@qw...> - 2008-08-27 05:31:16
Attachments:
machine_precistion_tests
|
On Aug 26, 2008, at 10:00 AM, Alan W. Irwin wrote: > On 2008-08-26 00:56-0700 Jerry wrote: > >> Finally, a dumb question. Is there any chance that floats, ints, >> doubles, etc. in C or Floats, Integers, Long_Floats, or Long_Integers >> in Ada have different sizes between languages on 64-bit boxes than on >> 32-bit boxes? > > I think there is a very good chance that the Ada language as > implemented by > gnat has different sizes for floats and especially integers than > PLplot so > maybe that is the source of the problem here. Recall that for the > default > PL_DOUBLE case, PLFLT is a double. Also, for platforms (32-bit or > 64-bit) > with access to stdint.h, PLINT is a 32-bit integer (int32_t, see > include/plplot.h). My feeling is stdint.h (e.g., access to the C99 > standard) is pretty common. Anyhow, it is available on my 64-bit > computer. > Thus, if Ada is assuming a 64-bit integers on 64-bit platforms, > that would > not be the same size as PLINT on my computer. > > Alan > Attached is a zip file (sans ".zip") that contains two programs, one in Ada and one in C, which print out some machine integer and floating point attributes. (Actually, the C version doesn't to floats right now.) Also included are the results of running them on my machine, OS X 10.4.11. (The version of OS X being sold in stores right now is 10.5.4.) To compile the Ada program, type gnatmake ada_machine_attributes.adb. It would be interesting to see what results some of you get on your 64-bit machines. Jerry |
From: Alan W. I. <ir...@be...> - 2008-08-27 06:04:15
|
On 2008-08-26 22:31-0700 Jerry wrote: > Attached is a zip file (sans ".zip") that contains two programs, one in Ada > and one in C, which print out some machine integer and floating point > attributes. (Actually, the C version doesn't to floats right now.) Also > included are the results of running them on my machine, OS X 10.4.11. (The > version of OS X being sold in stores right now is 10.5.4.) > > To compile the Ada program, type gnatmake ada_machine_attributes.adb. > > It would be interesting to see what results some of you get on your 64-bit > machines. The results are attached as two separate files. I hope they help you sort out the problem. Note, however, that many of these C integer size results are irrelevant to the PLplot C library API since PLINT (the type used for integer arguments for the PLplot API) is defined with a size of 32 bits on all platforms that use the C99 standard for C. That includes my platform even though my hardware is 64 bits. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Jerry <lan...@qw...> - 2008-08-29 08:43:22
|
I've started a discussion of this problem on comp.lang.ada but so far it's a lot of arcane language but no solution. Is there at least one other machine besides Alan's Debian on Intel Duo that reports this runtime error on Ada example 19? Maybe I've missed it, but as far as I recall there have been no other reports. I don't want knock myself out with this if it happens on only one box. Jerry |
From: Andrew R. <and...@us...> - 2008-08-29 15:35:16
|
Jerry, I get exactly the same problem on my Ubuntu box (also Intel Duo). Ubuntu packages are based on the Debian ones, but in this case are not quite the same versions of ada I think. I have another Ubuntu box with identical versions of ada, but only 32-bit. I do not see the error with this, so it is definitely a 64-bit issue rather than a versions issue. Andrew On Fri, Aug 29, 2008 at 01:43:31AM -0700, Jerry wrote: > I've started a discussion of this problem on comp.lang.ada but so far > it's a lot of arcane language but no solution. > > Is there at least one other machine besides Alan's Debian on Intel > Duo that reports this runtime error on Ada example 19? Maybe I've > missed it, but as far as I recall there have been no other reports. I > don't want knock myself out with this if it happens on only one box. > > Jerry > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel > |
From: Alan W. I. <ir...@be...> - 2008-08-29 17:05:45
|
On 2008-08-29 01:43-0700 Jerry wrote: > I've started a discussion of this problem on comp.lang.ada but so far > it's a lot of arcane language but no solution. > > Is there at least one other machine besides Alan's Debian on Intel > Duo that reports this runtime error on Ada example 19? Maybe I've > missed it, but as far as I recall there have been no other reports. I > don't want knock myself out with this if it happens on only one box. It's been seen on every 64-bit machine that has been tested. See http://sourceforge.net/mailarchive/message.php?msg_name=489B8116.3070603%40cora.nwra.com (Orion's 64-bit result), and http://sourceforge.net/mailarchive/message.php?msg_name=20080811205031.GD1359%40gandalf.rivendell (Andrew's 64-bit result). Presumably, those platforms will also show the same error for the simple test case (my modification of Jerry's original simple test that I attached earlier in this thread) that is independent of PLplot. Meanwhile, Jerry, my advice is to focus on asking your contacts at comp.lang.ada to run the simple example on their various 32-bit and 64-bit platforms to attempt to confirm the issue. Hopefully the bulk of the discussion will occur after that evidence is in. I have tried to use that same "get the evidence" mindset for the Debian bug report on this issue I just put together, see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=497067 Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Jerry <lan...@qw...> - 2008-08-29 21:26:38
|
On Aug 29, 2008, at 10:05 AM, Alan W. Irwin wrote: > On 2008-08-29 01:43-0700 Jerry wrote: > >> I've started a discussion of this problem on comp.lang.ada but so far >> it's a lot of arcane language but no solution. >> >> Is there at least one other machine besides Alan's Debian on Intel >> Duo that reports this runtime error on Ada example 19? Maybe I've >> missed it, but as far as I recall there have been no other reports. I >> don't want knock myself out with this if it happens on only one box. > > It's been seen on every 64-bit machine that has been tested. > See > http://sourceforge.net/mailarchive/message.php? > msg_name=489B8116.3070603%40cora.nwra.com > (Orion's 64-bit result), and > http://sourceforge.net/mailarchive/message.php? > msg_name=20080811205031.GD1359%40gandalf.rivendell > (Andrew's 64-bit result). > > Presumably, those platforms will also show the same error for the > simple > test case (my modification of Jerry's original simple test that I > attached > earlier in this thread) that is independent of PLplot. > > Meanwhile, Jerry, my advice is to focus on asking your contacts at > comp.lang.ada to run the simple example on their various 32-bit and > 64-bit > platforms to attempt to confirm the issue. Hopefully the bulk of the > discussion will occur after that evidence is in. > > I have tried to use that same "get the evidence" mindset for the > Debian bug > report on this issue I just put together, see > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=497067 > > Alan > __________________________ > Alan, your bug report was noticed by a person at comp.lang.ada. I added a post there to try to get more people to test on 32- and 64- bit systems. There have been a few suggestions on things to try posted at comp.lang.ada but not having access to a 64-bit crasher makes it hard. I could code up a couple of things and let someone else try them if someone is inclined to play with it. FWIW, the comp.lang.ada thread is here: http://groups.google.com/group/comp.lang.ada/browse_thread/thread/ 0e5a3abec221df39?hl=en Jerry |
From: Alan W. I. <ir...@be...> - 2008-08-29 23:20:02
|
On 2008-08-29 14:26-0700 Jerry wrote: > Alan, your bug report was noticed by a person at comp.lang.ada. I > added a post there to try to get more people to test on 32- and 64- > bit systems. > > There have been a few suggestions on things to try posted at > comp.lang.ada but not having access to a 64-bit crasher makes it > hard. I could code up a couple of things and let someone else try > them if someone is inclined to play with it. I would be happy to try any variations of the simple test case that you would like tested. > > FWIW, the comp.lang.ada thread is here: > http://groups.google.com/group/comp.lang.ada/browse_thread/thread/ > 0e5a3abec221df39?hl=en The above URL didn't work for me, but http://groups.google.com/group/comp.lang.ada/browse_thread/thread/0e5a3abec221df39# does. It appears you got lots of interest and speculation which is good, but I am disappointed that nobody has actually tried the test case, yet. To add some additional motivation for potential testers, you might want to refer directly to http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=10;filename=simple_test_case.tar.gz;att=1;bug=497067 (the test tarball I attached to my bug report), and give the cookbook (tested by you) for downloading, unpacking, building, and running that test case. A tarball is a lot more convenient for potential testers than cutting and pasting the test source code from e-mails with concerns about completeness, line wrapping, etc. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Werner S. <sm...@ia...> - 2008-08-31 09:04:22
|
> Attached is a zip file with three short Ada files in it. They have a > similar structure to the problematic example 19 but do not call or link > to any PLplot stuff (despite the names of some things looking PLplot-y). > > Alan (or someone else with a 64-bit Ada compiler), if you would, please > unzip, cd to the directory, and type > > gnatmake ./x19a_temp.adb > > You should see two warnings but no errors. If it compiles, the > executable will be called x19a_temp. Try to run it and see what happens. > It should print out 10 lines of floats. > > I think there is a low probability that this will point to a compiler > error but we need to try it anyway. > > This compiles and runs OK on my system. FWIW, I also compiled it on my Windows XP SP3, 32bit system with gcc/gnat 4.3.1 and it worked ok: Z:\DevZone\Temp PLplot Ada Example 19>gnatmake x19a_temp.adb gcc -c x19a_temp.adb x19a_temp.adb:10:38: warning: type of argument "mapform19.x" is unconstrained array x19a_temp.adb:10:38: warning: foreign caller must pass bounds explicitly gcc -c type_declaration.adb gnatbind -x x19a_temp.ali gnatlink x19a_temp.ali Z:\DevZone\Temp PLplot Ada Example 19>ls Type_Declaration.adb type_declaration.ali x19a_temp.adb x19a_temp.exe Type_Declaration.ads type_declaration.o x19a_temp.ali x19a_temp.o Z:\DevZone\Temp PLplot Ada Example 19>x19a_temp.exe 0.00000000000000E+00 1.00000000000000E+00 2.00000000000000E+00 3.00000000000000E+00 4.00000000000000E+00 5.00000000000000E+00 6.00000000000000E+00 7.00000000000000E+00 8.00000000000000E+00 9.00000000000000E+00 If this is of any help :) Werner -- Dr. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office) +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 |