I'm using gpc version 20051116, based on gcc-3.4.5. Impressive update!
It is very nice to have the runtime error detection. But of course it means some new errors have to be dealt with, one way or another. An old program of mine is now getting...
out of range (error #300 at 2c57)
Trace/BPT trap
Trying to get a less cryptic error report, maybe one with the procedure stack at point of error, I compile as:
gp -mtraceback=full progname
But this does not add anything to the information in the out of range error. Also, it would be nice to have a list of error messages, so that error #300 could be looked up.
Any thought on how to access more information for runtime errors? (like a simple traceback of procedure calls)..
Thanks, Willett Kempton
willett wrote:
I'm using gpc version 20051116, based on gcc-3.4.5. Impressive update!
It is very nice to have the runtime error detection. But of course it means some new errors have to be dealt with, one way or another. An old program of mine is now getting...
out of range (error #300 at 2c57)
Trace/BPT trap
Assuming Mac OS X. Don't you get a crash report dialog ?
Trying to get a less cryptic error report, maybe one with the procedure stack at point of error, I compile as:
gp -mtraceback=full progname
But this does not add anything to the information in the out of range error. Also, it would be nice to have a list of error messages, so that error #300 could be looked up.
Any thought on how to access more information for runtime errors? (like a simple traceback of procedure calls)..
Try the following:
* add debug information to your program (by adding -g to the compilation options) * have a look at the crash logs with /Applications/Utilities/Console
I am not sure if -mtraceback does anything for gpc (or gcc) on darwin.
Regards,
Adriaan van Os
willett wrote:
I'm using gpc version 20051116, based on gcc-3.4.5. Impressive update!
It is very nice to have the runtime error detection. But of course it means some new errors have to be dealt with, one way or another. An old program of mine is now getting...
out of range (error #300 at 2c57)
Trace/BPT trapTrying to get a less cryptic error report, maybe one with the procedure stack at point of error, I compile as:
gp -mtraceback=full prognameBut this does not add anything to the information in the out of range error. Also, it would be nice to have a list of error messages, so that error #300 could be looked up.
The list is only hidden in rts/error.pas, but the above message says it already: It's a range-check error.
Any thought on how to access more information for runtime errors? (like a simple traceback of procedure calls)..
For errors that GPC catches (such as this one, as oppose to real crashes, segmentation faults, bus errors, etc.), you can use the command line option:
--gpc-rts=-Efoo
to write such a traceback to file foo, or
--gpc-rts=-F42
to write it to FD #42 (for any value of 42, such as 2 for standard error).
You can then use addr2line to translate the numeric positions into line numbers. (Also to the one in the error message, here 2c57; this might already tell you what you need to know.)
The gpc-run script that comes with GPC automates this, but AFAIK it's not well tested, mainly by myself, and only on Unix compatible systems):
gpc-run your-program your-arguments
Frank
Frank Heckenbach wrote:
willett wrote:
I'm using gpc version 20051116, based on gcc-3.4.5. Impressive update!
It is very nice to have the runtime error detection. But of course it means some new errors have to be dealt with, one way or another. An old program of mine is now getting...
out of range (error #300 at 2c57)
Trace/BPT trapTrying to get a less cryptic error report, maybe one with the procedure stack at point of error, I compile as:
gp -mtraceback=full prognameBut this does not add anything to the information in the out of range error. Also, it would be nice to have a list of error messages, so that error #300 could be looked up.
The list is only hidden in rts/error.pas, but the above message says it already: It's a range-check error.
Any thought on how to access more information for runtime errors? (like a simple traceback of procedure calls)..
For errors that GPC catches (such as this one, as oppose to real crashes, segmentation faults, bus errors, etc.), you can use the command line option:
--gpc-rts=-Efoo
to write such a traceback to file foo, or
--gpc-rts=-F42
to write it to FD #42 (for any value of 42, such as 2 for standard error).
You can then use addr2line to translate the numeric positions into line numbers. (Also to the one in the error message, here 2c57; this might already tell you what you need to know.)
The gpc-run script that comes with GPC automates this, but AFAIK it's not well tested, mainly by myself, and only on Unix compatible systems):
gpc-run your-program your-arguments
But also see http://www.gnu-pascal.de/crystal/gpc/en/mail13038.html, it's now the default on Mac OS X.
Regards,
Adriaan van Os
Thanks to Frank and Adriaan.
I was not able to use the general method Frank described; I seem to have no addr2line program. The OSX-specific method works very well. To help others using OSX, below is a more spelled-out description of how to use this. Anyone can feel free to cut and paste into their documentation:
------------------------------------------------------------------------ ------------------------------ FINDING LOCATION OF GPC RUNTIME ERRORS ON MAC OSX:
For programs that get errors, not crash such as "segmentation fault", use the following, E.G., for program myprog.pas:
compile with debug information gp -g myprog
open console, find the appropriate CrashReporter log open ...Applications/Utilities/Console locate under "Logs", e.g. open triangle for: ~Library/Logs/CrashReporter then click on: myprog.crash.log
Leave the log open, and run the program normally, e.g. ./myprog
The traceback shows in the crash.log, e.g. Thread 0 crashed: 0 myprog ... 1 myprog ... 2 myprog 0x00072800 _p_IORangeCheckError + 0 (error.pas:626) 3 myprog 0x00072c58 _p_M0_main_program + 1296 (myprog.pas:82) 4 myprog ... 5 myprog ...
Interpretation: the problem was a range check error, in the main program of myprog, on line 82 of file myprog.pas
------------------------------------------------------------------------ ------------------------------
willett wrote:
Thanks to Frank and Adriaan.
I was not able to use the general method Frank described; I seem to have no addr2line program.
The lack of addr2line on OS X has been reported before, see http://www.gnu-pascal.de/crystal/gpc/en/mail12553.html for alternatives. Also WriteStackDump doesn't give any useful information on darwin.
The OSX-specific method works very well.
Which is why I took the freedom to solve it that way.
Regards,
Adriaan van Os
Attached is an update to ncurses.pas and associated programs. It is a zipped tar archive. Compared to the prior release, in 2005, this one has:
1. auto configure 2. designed to autoconfigure and operate on all gpc systems using ncurses 3. considerable expansion of functionality of function keys. 4. more example programs, including the game of "life" 5. Requires newest release of gpc, with predefined type "CWordBool"
See the documentation file, ncurses-gpc.txt
Willett Kempton
In case my last post was unclear, I am seeking a couple of testers to try the autoconfiguration on different platforms, to see if it configures and runs correctly. (tar is on my last post)
Willett Kempton
On 7 Feb 2006, at 1:27 AM, willett wrote:
Attached is an update to ncurses.pas and associated programs. It is a zipped tar archive. Compared to the prior release, in 2005, this one has:
- auto configure
- designed to autoconfigure and operate on all gpc systems using
ncurses 3. considerable expansion of functionality of function keys. 4. more example programs, including the game of "life" 5. Requires newest release of gpc, with predefined type "CWordBool"
See the documentation file, ncurses-gpc.txt
Willett Kempton
<ncurses-gpc-20060207.tar.gz>
Willett Kempton wrote:
Attached is an update to ncurses.pas and associated programs.
Thanks for the ncurses update. I tried the "life" program but it doesn't seem to print instructions on the screen when pressing F1 on start. When I tried to quit "life" by force, a crash occurred (but only once, I can't reproduce it). It's a range check error in Getchq + 0x40.
**********
Host Name: g5.local Date/Time: 2006-02-07 11:49:26 +0100 OS Version: 10.3.9 (Build 7W98) Report Version: 2
Command: life Path: ./life Version: ??? (???) PID: 624 Thread: 0
Exception: EXC_BREAKPOINT (0x0006) Code[0]: 0x00000001 Code[1]: 0x0000f9ec
Thread 0 Crashed: 0 life 0x0000f9ec _p_EndRuntimeError + 0x60 (error.pas:903) 1 life 0x0000faf0 _p__rts_Error_S37_Strerror + 0 (error.pas:931) 2 life 0x0000dfac _p_IORangeCheckError + 0 (error.pas:626) 3 life 0x000035e8 _p__M0_S4_Getchq + 0x40 (crt.c:300) 4 life 0x00004168 _p__M0_S15_Getkey + 0x38 (crt.c:300) 5 life 0x000047d8 _p__M0_S18_Nextcommand + 0x88 (crt.c:300) 6 life 0x000054b0 _p__M0_S28_Getone + 0x74 (crt.c:300) 7 life 0x000056c0 _p__M0_S29_Getpositions + 0x78 (crt.c:300) 8 life 0x00005948 _p__M0_S30_Initgame + 0xec (crt.c:300) 9 life 0x00006708 _p__M0_main_program + 0x28 (crt.c:300) 10 life 0x00006b0c main + 0x50 (crt.c:300) 11 life 0x00001d84 _start + 0x188 (crt.c:267) 12 dyld 0x8fe1a278 _dyld_start + 0x64
PPC Thread State: srr0: 0x0000f9ec srr1: 0x0202d030 vrsave: 0x00000000 cr: 0x24000224 xer: 0x00000000 lr: 0x0000f9c8 ctr: 0x98d958b0 r0: 0x00000001 r1: 0xbfffef10 r2: 0x0003f994 r3: 0xffffffff r4: 0x00000003 r5: 0x00000028 r6: 0x0000002c r7: 0x00000c03 r8: 0x00000000 r9: 0x00000000 r10: 0x00000000 r11: 0xa8d92a78 r12: 0x98d958b0 r13: 0x00000000 r14: 0x00000000 r15: 0x00000000 r16: 0x00000000 r17: 0x00000000 r18: 0x00000000 r19: 0x00000000 r20: 0x00000000 r21: 0x00000000 r22: 0x00000000 r23: 0x00000000 r24: 0x00000000 r25: 0x00000000 r26: 0x0000012c r27: 0xbfffef60 r28: 0x00039580 r29: 0xbfffef70 r30: 0xbfffef60 r31: 0x0000f994
Binary Images Description: 0x1000 - 0x3bfff life ./life 0x8fe00000 - 0x8fe4ffff dyld /usr/lib/dyld 0x9278f000 - 0x927bafff libncurses.5.dylib /usr/lib/libncurses.5.dylib 0x93a50000 - 0x93a54fff libmathCommon.A.dylib /usr/lib/system/libmathCommon.A.dylib 0x98d8e000 - 0x98eddfff libSystem.B.dylib /usr/lib/libSystem.B.dylib
Regards,
Adriaan van Os
Adriaan,
Thanks very much for your report.
If key F1 didn't work, I'm betting you: 1) are on MacOSX using "terminal", AND 2) have not reset the terminal, so it is still at term=xterm. If so, you can just "set term=vt102" and you should see that it runs fine.
However, your report also points to an unclarity in "life's" error messages. I've fixed that and will use the modified version when I distribute.
I can't reproduce the crash either-- what constitutes "quit by force"? But a problem with "quit by force" is also not a high priority.
Thanks,
Willett
On 11 Feb 2006, at 09:07, Adriaan van Os wrote:
Thanks for the ncurses update. I tried the "life" program but it doesn't seem to print instructions on the screen when pressing F1 on start. When I tried to quit "life" by force, a crash occurred (but only once, I can't reproduce it). It's a range check error in Getchq + 0x40.
willett wrote:
If key F1 didn't work, I'm betting you: 1) are on MacOSX using "terminal", AND 2) have not reset the terminal, so it is still at term=xterm. If so, you can just "set term=vt102" and you should see that it runs fine.
It was at xterm-color and indeed the instructions show up when setting it at vt102, thanks.
However, your report also points to an unclarity in "life's" error messages. I've fixed that and will use the modified version when I distribute.
I can't reproduce the crash either-- what constitutes "quit by force"?
Pressed some keys (can't remember which) and then closed the Terminal window.
But a problem with "quit by force" is also not a high priority.
Ah, one of the famous excuses for not fixing bugs !
Regards,
Adriaan
Adrian:
I'm attempting to revitalize some old pascal projects. I've unfortunately installed XCode 2.2 and all of the GPC stuff, and indeed the example projects work like a charm.
When I import one of my old CodeWarrior Pascal projects, XCode doesn't know about the CPG compiler (in the edit active target window, which is entirely different than the example CPG projects.. I notice from creating a new project that there is a Make file, etc. What do I need to do to the imported projects to make them behave?
Thanks, Joseph Ayers
Joseph Ayers wrote:
Adrian:
I'm attempting to revitalize some old pascal projects. I've unfortunately installed XCode 2.2 and all of the GPC stuff, and indeed the example projects work like a charm.
This is surprising, because with Xcode 2.2 and 2.2.1 you need a workaround for a bug in Xcode. The workaround can be found in the MacPascal mailing list archives http://lists.sonic.net/mailman/private/mac-pascal/ in the thread "[MacPascal] FPC -> GPC -- what are the consequences?". I am duplicating some of it below, but generally questions about Xcode are best asked on the MacPascal mailing list rather than here.
When I import one of my old CodeWarrior Pascal projects, XCode doesn't know about the CPG compiler (in the edit active target window, which is entirely different than the example CPG projects.. I notice from creating a new project that there is a Make file, etc. What do I need to do to the imported projects to make them behave?
The answer is that it doesn't work (sorry) because GPC doesn't use Xcode's native build system, but a Makefile instead (as you noticed) and this is for the following reasons:
1. Apple's native Xcode build system is closed and very unfriendly towards compilers other than for the C family 2. Apple is too arrogant to fix the bugs in Xcode's build system(s)
So, I can only refer you to the examples, templates and Readme file of the GPC Xcode Kit (and the MacPascal mailing list for additional questions).
Regards,
Adriaan van Os
_______________________________________________ MacPascal mailing list MacPascal@listman.sonic.net http://lists.sonic.net/mailman/listinfo/mac-pascal
steven.borley wrote:
Hi Adriaan,
Some time ago...
On 17 Dec 2005, at 17:54, Adriaan van Os wrote:
If you prefer Xcode 2.2, I can explain how to work around the stupid Xcode 2.2 bug (it's not difficult)
Please could you explain the work around for me :-)
With the current GPC Xcode Kit, create a new project, using one of the GNU Pascal templates. Double-click on the Deploy or Debug Target and look at the Arguments line. It reads something like:
$(ACTION)_application_pack
The actual text of the Arguments line will vary with the template choosen, so "_application_pack" is just an example. The bug in Xcode 2.2 is that "_application_pack" (or a similar value) is not passed to the build system if $(ACTION) is empty. Of course, the dumbos at Apple that maintain Xcode will never fix it.
To work around it, open the Makefile that was created for the project and edit it as follows:
Change
# Make-targets for build
.PHONY : _tool _tool: compile_tool create_tool
to
# Make-targets for build
.PHONY : default default: _application_pack # Xcode 2.2 bug
.PHONY : _tool _tool: compile_tool create_tool
Again, "_application_pack" is just an example and it has to be replaced by the actual value you found in the Arguments line of the Target.
That's all. Let me know if it works.
-
Adriaan van Os -
Frank Heckenbach -
Joseph Ayers -
willett -
Willett Kempton