Frank D. Engel, Jr. wrote:
The strange thing is that sometimes the problem can be fixed by sticking extra WRITELNs in between various lines of code. So for example, if I am having trouble and think the following code is at fault:
x := SomeFunction(y, z); DoSomethingTo(x);I might change it to:
WRITELN('1'); x := SomeFunction(y, z); WRITELN('2'); DoSomethingTo(x); WRITELN('3');and sometimes this fixes the problem (but of course, I don't want that extra output...)
Any ideas/fixes/patches?
My father had this same problem. I seems that the compiler misbehaves (buffer-length/line-length interaction problem?) when the source text itself contains Mac-style end-of-lines (carriage returns only). Possibly the problem only occurs when the source file contains MIXED Mac-style and Unix-style end-of-lines. This can happen when you switch editor, or when you modify a program taken from elsewhere.
I have not investigated it deeply.
The problem disappeared when the source files where fully converted to Unix-style end-of-lines (Line feeds only). A decent text editor like BBEdit will make this change in two clicks.
Tom
the problem only occurs when the source file contains MIXED Mac-style and Unix-style end-of-lines. This can happen when you switch editor, or when you modify a program taken from elsewhere.
I have not investigated it deeply.
The problem disappeared when the source files where fully converted to Unix-style end-of-lines (Line feeds only). A decent text editor
I've been using Apple's Project Builder, from the development tools package.
I tried converting (Format->Line Endings->Use UNIX Line Endings (LF)), but this does not seem to have made any difference.
===== ======= Frank D. Engel, Jr.
Modify the equilibrium of the vertically-oriented particle decelerator to result in the reestablishment of its resistance to counterproductive atmospheric penetration.
__________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
Tom Verhoeff wrote:
Frank D. Engel, Jr. wrote:
The strange thing is that sometimes the problem can be fixed by sticking extra WRITELNs in between various lines of code. So for example, if I am having trouble and think the following code is at fault:
x := SomeFunction(y, z); DoSomethingTo(x);I might change it to:
WRITELN('1'); x := SomeFunction(y, z); WRITELN('2'); DoSomethingTo(x); WRITELN('3');and sometimes this fixes the problem (but of course, I don't want that extra output...)
Any ideas/fixes/patches?
My father had this same problem. I seems that the compiler misbehaves (buffer-length/line-length interaction problem?)
Unlikely, GPC does not buffer lines.
when the source text itself contains Mac-style end-of-lines (carriage returns only). Possibly the problem only occurs when the source file contains MIXED Mac-style and Unix-style end-of-lines. This can happen when you switch editor, or when you modify a program taken from elsewhere.
I have not investigated it deeply.
Can you send an example? (When I just put mixed line endings into some Pascal source, it didn't happen, of course.)
I still suspect it's a volatile bug (in GPC or the Pascal code).
Frank
Frank Heckenbach wrote:
I still suspect it's a volatile bug (in GPC or the Pascal code).
A volatile bug in GPC were to explain the internal compiler errors that I sometimes get for Pascal source that compiles at other times perfectly well. But these are all problems that occur when compiling (not when running a compiled program, as is the case with Frank Engel's topas).
Regards,
Adriaan van Os
***
... used VOID file /Developer/Pascal/GPCInterfaces/Develop/GPCPInterfaces/MacTypes.pas line 574 align 1 initial <integer_cst 0xce3858 6> chain <const_decl 0xce4a80 Condense>> /Developer/Pascal/GPCInterfaces/Develop/GPCPInterfaces/ MacTypes.pas:802: internal compiler error: Bus error
***
Warning : GPI file `gpcmacosall.gpi' does not contain nodes chunk GPCStringsAll.pas line 5
../../gpc-3.3d7/gcc/p/module.c:1714:get_node_id: failed assertion `n < wb.count'
Error : Internal compiler error. GPCMacOSAll.pas line 160048
***
Error : internal compiler error: in expand_call, at calls.c:3299 warnings.pas line 71
***
Error : unrecognizable insn: warnings.pas line 59
(insn 22 30 23 1 0x0 (set (reg:SI 124)
(subreg:SI (reg:TF 33 f1) 0)) -1 (insn_list 21 (nil))
(nil))
Error : internal compiler error: in extract_insn, at recog.c:2175 warnings.pas line 59
***
../../gpc-331d1/gcc/p/module.c:351:mseek: failed assertion `O <= F->size'
Error : Internal compiler error. SillyBalls.pas line 1
***
At 6:56 AM +0200 12/8/03, Adriaan van Os wrote:
Error : Internal compiler error. GPCMacOSAll.pas line 160048
Perhaps the solution to this problem would be for each ICE to either print a stack backtrace, or if that isn't possible, for each ICE to display the source file and line number in GPC that generates this? At least then Frank would be able to figure out where to look?
Or is this in the backend or otherwise hard to distinguish? Peter.
Peter N Lewis wrote:
At 6:56 AM +0200 12/8/03, Adriaan van Os wrote:
Error : Internal compiler error. GPCMacOSAll.pas line 160048
Perhaps the solution to this problem would be for each ICE to either print a stack backtrace, or if that isn't possible, for each ICE to display the source file and line number in GPC that generates this? At least then Frank would be able to figure out where to look?
No problem to provide the backtrace and the offending source line, but I doubt whether that will be helpful. If my understanding of "random" problems like the above (not Frank Engel's) is correct, the logic at the time of the crash isn't at fault, but some internal or external data structure has gone corrupt at an earlier time.
These are nasty problems. To find the cause you have to make the "random" problem more reproducible, more crashable.
One way to do that is to use stress testing tools, which is why I were experimenting with the --param option (to stress test the gnu garbage collector). Also, I will see if I can build gpc with Apple's debugging version of malloc. But -- it could even be something as bizar as a bug in Mac OS X's disk cache system (I am just speculating). Frank mentioned hardware failures.
The other way is to build into the software as much as possible internal checks. That can make it run slower (or even painfully slow), but it would be a special runtime or build option.
Regards,
Adriaan van Os
At 12:05 PM +0200 12/8/03, Adriaan van Os wrote:
Perhaps the solution to this problem would be for each ICE to either print a stack backtrace, or if that isn't possible, for each ICE to display the source file and line number in GPC that generates this? At least then Frank would be able to figure out where to look?
No problem to provide the backtrace and the offending source line, but I doubt whether that will be helpful. If my understanding of "random" problems like the above (not Frank Engel's) is correct, the logic at the time of the crash isn't at fault, but some internal or external data structure has gone corrupt at an earlier time.
These are nasty problems. To find the cause you have to make the "random" problem more reproducible, more crashable.
True enough, but at least knowing what it is accessing at the time might help - especially if you start seeing some consistencies in the reports.
One way to do that is to use stress testing tools, which is why I were experimenting with the --param option (to stress test the gnu garbage collector). Also, I will see if I can build gpc with Apple's debugging version of malloc. But -- it could even be something as bizar as a bug in Mac OS X's disk cache system (I am just speculating). Frank mentioned hardware failures.
Absolutely - especially as I have not see anything like this in all the compiling I've done on both my old G4 and my new dual G4. However, once you start seeing it on more than a couple Mac OS X users, hardware would become fairly unlikely given the relatively small number of GPC/Mac OS X users currently. However, a system software error is still a definite possibility in this case, especially given the relative newness of Mac OS X.
The other way is to build into the software as much as possible internal checks. That can make it run slower (or even painfully slow), but it would be a special runtime or build option.
Yep - AssertDataStructureValid. If the above traceback gave a hint as to which structure was the problem, it might then be possible to add a check for its validity regularly (say as much as each token, but perhaps just each statement), and that can then help trace the problem back.
But as you say, very ugly to figure out. Peter.
Peter N Lewis wrote:
At 6:56 AM +0200 12/8/03, Adriaan van Os wrote:
Error : Internal compiler error. GPCMacOSAll.pas line 160048
Perhaps the solution to this problem would be for each ICE to either print a stack backtrace, or if that isn't possible, for each ICE to display the source file and line number in GPC that generates this? At least then Frank would be able to figure out where to look?
No problem to provide the backtrace and the offending source line, but I doubt whether that will be helpful. If my understanding of "random" problems like the above (not Frank Engel's) is correct, the logic at the time of the crash isn't at fault, but some internal or external data structure has gone corrupt at an earlier time.
Peter was right, one of the reported crashes was indeed reproducible (details below). The question is whether this is a problem with enumerated types or with the option that debugs them.
Regards,
Adriaan van Os
[G4:~/gnu/testgpc/adriaan] adriaan% cat StyleItems.pas unit StyleItems; interface type StyleItemGPC = (bold,italic,underline,outline,shadow,condense,extend); end.
[G4:~/gnu/testgpc/adriaan] adriaan% gpc -c styleitems.pas --debug-gpi creating GPI file: styleitems.gpi GPI storing header: GNU Pascal unit/module interface GPI storing version: 20030507 D 3.3.1 GPI storing target: powerpc-apple-darwin GPI storing module name: Styleitems GPI storing source file name: styleitems.pas GPI storing module initializer: init_Styleitems GPI storing <77>: <identifier_node 0xccf630 Styleitems spelling StyleItems (styleitems.pas:1)>
.... huge output ...
GPI storing <103>: <const_decl 0xcd2ee0 Extend type <enumeral_type 0xcd2b60 Styleitemgpc unsigned SI size <integer_cst 0xc99918 constant unsigned 32> unit size <integer_cst 0xc99978 constant unsigned 4> align 32 symtab 0 alias set -1 precision 32 min <integer_cst 0xcd1e58 0> max <integer_cst 0xcd3018 6> values <tree_list 0xcd1d68 purpose <identifier_node 0xccf7b0 Bold spelling bold (styleitems.pas:3) value <const_decl 0xcd2c40 Bold>> value <integer_cst 0xcd1e58 constant unsigned tree_5 0> chain <tree_list 0xcd1d80 purpose <identifier_node 0xccf810 Italic spelling italic (styleitems.pas:3) value <const_decl 0xcd2cb0 Italic>> value <integer_cst 0xcd1ea0 constant unsigned tree_5 1> chain <tree_list 0xcd1d98 purpose <identifier_node 0xccf870 Underline spelling underline (styleitems.pas:3) value <const_decl 0xcd2d20 Underline>> value <integer_cst 0xcd1ee8 constant unsigned tree_5 2> chain <tree_list 0xcd1db0 purpose <identifier_node 0xccf8d0 Outline spelling outline (styleitems.pas:3) value <const_decl 0xcd2d90 Outline>> value <integer_cst 0xcd1f30 constant unsigned tree_5 3> chain <tree_list 0xcd1dc8 purpose <identifier_node 0xccf930 Shadow> value <integer_cst 0xcd1f78 4> chain <tree_list 0xcd1de0>>>>>> main_variant <enumeral_type 0xcd2b60 Styleitemgpc> chain <type_decl 0xcd2bd0>> VOID file styleitems.pas line 3 align 1 initial <integer_cst 0xcd3018 6> chain <const_decl 0xcd2e70 Condense>> styleitems.pas:4: internal compiler error: Bus error
The backtrace reads:
**********
Date/Time: 2003-08-12 13:11:10 +0200 OS Version: 10.2.4 (Build 6I32) Host: G4.local.
Command: gpc1 PID: 14659
Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000024
Thread 0 Crashed: #0 0x0001ebf0 in store_tree (module.c:1638) #1 0x00021908 in create_gpi_files (module.c:2862) #2 0x0002a9e8 in main_yyparse (parse.c:313) #3 0x000980a0 in compile_file (toplev.c:2134) #4 0x0009d308 in do_compile (toplev.c:5384) #5 0x0009d3d4 in toplev_main (toplev.c:5414) #6 0x00002740 in _start (crt.c:267) #7 0x000025c0 in start
PPC Thread State: srr0: 0x0001ebf0 srr1: 0x0000f930 vrsave: 0x00000000 xer: 0x00000000 lr: 0x0001e798 ctr: 0x00000000 mq: 0x00000000 r0: 0x00000001 r1: 0xbfffd570 r2: 0x00000000 r3: 0x00000000 r4: 0x002eec88 r5: 0x00000022 r6: 0x00000010 r7: 0x002f09f0 r8: 0x00000000 r9: 0x00cd1cd8 r10: 0x00846a70 r11: 0x00cd3048 r12: 0x90073aa0 r13: 0x00000000 r14: 0x002ee50c r15: 0x0036d76c r16: 0x00000001 r17: 0x00000000 r18: 0x00000000 r19: 0x00000000 r20: 0x00cd3060 r21: 0xa0006bf8 r22: 0x00ccf630 r23: 0x00cd3048 r24: 0xbfffd5b0 r25: 0x00000000 r26: 0x00cd3060 r27: 0x00000000 r28: 0x00000068 r29: 0x00000000 r30: 0xbfffd9d0 r31: 0x0001e50c
Adriaan van Os wrote:
Peter was right, one of the reported crashes was indeed reproducible (details below). The question is whether this is a problem with enumerated types or with the option that debugs them.
The latter. That was an easy one.
Frank
Peter N Lewis wrote:
At 6:56 AM +0200 12/8/03, Adriaan van Os wrote:
Error : Internal compiler error. GPCMacOSAll.pas line 160048
Perhaps the solution to this problem would be for each ICE to either print a stack backtrace, or if that isn't possible, for each ICE to display the source file and line number in GPC that generates this? At least then Frank would be able to figure out where to look?
For errors that the compiler itself recognizes (via `assert' or `abort'), it does so:
: Error : internal compiler error: in extract_insn, at recog.c:2175 : warnings.pas line 59
For real crashes (segfault, bus error etc.) that's not easily possible. The best thing is to look at the core file in a debugger. Unfortunately, gcc-3 suppresses coredumps. The following patch will change this (and the ulimit for the coredumpsize must be set > 0 in the shell).
--- gcc/toplev.c.orig Sat Nov 9 09:59:15 2002 +++ gcc/toplev.c Tue Nov 26 16:35:32 2002 @@ -1712,6 +1712,10 @@ crash_signal (signo) int signo; { + /* But less programmer friendly because coredumps are missing. -- Frank */ + error ("internal error: %s", strsignal (signo)); + raise (signo); + internal_error ("internal error: %s", strsignal (signo)); }
Frank
Hi everybody,
thanks to the suggestion from Jean-Pierre, Maurice and Frank, after playing around a bit, I figured out how to solve the problem of the resizing of the vectors: basically, I dispose of the copy vectors as soon as they are of no use any longer. With simple cases (where there are only a few calls to the resizing routine) the program works just fine, but look what I get with a "real case" (this is the output of GDB):
Program received signal SIGSEGV, Segmentation fault. Removefrommarklist (Apointer=void) at /home/frank/gpc/gcc-2.95.3/gcc/p/rts/heap.pas:226 226 /home/frank/gpc/gcc-2.95.3/gcc/p/rts/heap.pas: No such file or directory. in /home/frank/gpc/gcc-2.95.3/gcc/p/rts/heap.pas
I don't even know what's going on, can somebody tell me? Is this the kind of problem that Jean-Pierre was referring to?
Thanks a lot
Silvio
Le Mercredi 3 Septembre 2003 16:44, Silvio a Beccara a écrit :
Hi everybody,
thanks to the suggestion from Jean-Pierre, Maurice and Frank, after playing around a bit, I figured out how to solve the problem of the resizing of the vectors: basically, I dispose of the copy vectors as soon as they are of no use any longer. With simple cases (where there are only a few calls to the resizing routine) the program works just fine, but look what I get with a "real case" (this is the output of GDB):
Program received signal SIGSEGV, Segmentation fault. Removefrommarklist (Apointer=void) at /home/frank/gpc/gcc-2.95.3/gcc/p/rts/heap.pas:226 226 /home/frank/gpc/gcc-2.95.3/gcc/p/rts/heap.pas: No such file or directory. in /home/frank/gpc/gcc-2.95.3/gcc/p/rts/heap.pas
I don't even know what's going on, can somebody tell me? Is this the kind of problem that Jean-Pierre was referring to?
maybe you could try a variant, especially if you can guess a reasonnable estimate of the maximal size of your vector V.
define two integers as global variables: physicalsize and logicalsize. 1) initialize physicalsize to an estimate of the maximal size of V 2) create V with size physicalsize 3)initialize logicalsize to the true initial value of V (less than physicalsize of course) 4) do whatever you want to do with V , using logicalsize as size of V
when you need to resize, the resize procedure works a bit differently: if the new size is less than physicalsize, resize just updates logicalsize and returns if the new size is greater than physicalsize, increase physicalsize to a much larger value , using the preceeding method: create a new VV with size (the new) physicalsize check that the creation did succeed; if not, abort cleanly copy the relevant datas dispose (or freemem) the old V assign VV to V update logicalsize return (what <<much larger>> means is up to you, the idea is to avoid as much calls to new/dispose or getmem/freemem as possible)
This variant will reduce heap fragmentation, and incidentally it will be faster than the previous one (possibly much faster if resizing is a frequent operation)
Dear Jean-Pierre,
I think I will try your method. Thank you very much, you have been very helpful.
Best regards
Silvio
On Wed, 3 Sep 2003, Jean-Pierre Vial wrote:
| Le Mercredi 3 Septembre 2003 16:44, Silvio a Beccara a écrit : | > Hi everybody, | > | > thanks to the suggestion from Jean-Pierre, Maurice and Frank, after | > playing around a bit, I figured out how to solve the problem of the | > resizing of the vectors: basically, I dispose of the copy vectors as soon | > as they are of no use any longer. With simple cases (where there are only | > a few calls to the resizing routine) the program works just | > fine, but look what I get with a "real case" (this is the output of GDB): | > | > Program received signal SIGSEGV, Segmentation fault. | > Removefrommarklist (Apointer=void) at | > /home/frank/gpc/gcc-2.95.3/gcc/p/rts/heap.pas:226 | > 226 /home/frank/gpc/gcc-2.95.3/gcc/p/rts/heap.pas: No such file or | > directory. | > in /home/frank/gpc/gcc-2.95.3/gcc/p/rts/heap.pas | > | > | > I don't even know what's going on, can somebody tell me? | > Is this the kind of problem that Jean-Pierre was referring to? | | maybe you could try a variant, especially if you can guess a reasonnable | estimate of the maximal size of your vector V. | | define two integers as global variables: physicalsize and logicalsize. | 1) initialize physicalsize to an estimate of the maximal size of V | 2) create V with size physicalsize | 3)initialize logicalsize to the true initial value of V (less than | physicalsize of course) | 4) do whatever you want to do with V , using logicalsize as size of V | | when you need to resize, the resize procedure works a bit differently: | if the new size is less than physicalsize, resize just updates logicalsize | and returns | if the new size is greater than physicalsize, | increase physicalsize to a much larger value , using the preceeding method: | create a new VV with size (the new) physicalsize | check that the creation did succeed; if not, abort cleanly | copy the relevant datas | dispose (or freemem) the old V | assign VV to V | update logicalsize | return | (what <<much larger>> means is up to you, the idea is to avoid as much calls | to new/dispose or getmem/freemem as possible) | | This variant will reduce heap fragmentation, and incidentally it will be | faster than the previous one (possibly much faster if resizing is a frequent | operation) | | | -- | Jean-Pierre Vial |
Silvio a Beccara wrote:
Program received signal SIGSEGV, Segmentation fault.
I don't even know what's going on, can somebody tell me?
This means your program crashed. Probably you did something wrong. But without seeing your code, it's impossibly for us to tell.
Frank
Dear Frank,
here you find the code responsible for the error. As already said, it works just fine as far as it is called only a few times, but results in the aforementioned message when things become intensive.
procedure addoneket ( var ktsa: PMatr2Dob10; neact: integer; var lastket: integer );
var
i, j, itop, jtop, i1, i2, i3, i4, j1, j2, j3, j4: integer;
ktsb: Pmatr2Dob10;
begin
//create a new array, k4, one row longer //to accomodate the new vector. //copy k3 to k4, //then redimension k3, //finally copy k4 back into k3.
//printket ( ktsa, neact, '# ADDONEKET: ktsa before adding last ket' );
inc ( lastket ); jtop := 4 * neact; new ( ktsb, lastket, jtop );
for i := 1 to lastket - 1 do begin for j := 0 to jtop do begin ktsb ^[ i, j ] := ktsa ^[ i, j ]; end; end;
dispose ( ktsa ); new ( ktsa, lastket, 4 * neact );
for i := 1 to lastket - 1 do begin for j := 0 to jtop do begin ktsa ^[ i, j ] := ktsb ^[ i, j ]; end; end;
dispose ( ktsb ); //free some memory by disposing of ktsb.
//printket ( ktsa, neact, '# ADDONEKET: ktsa AFTER adding last ket' );
end; //end procedure
Best regards
Silvio
On Wed, 3 Sep 2003, Frank Heckenbach wrote:
| Silvio a Beccara wrote: | | > Program received signal SIGSEGV, Segmentation fault. | > | > I don't even know what's going on, can somebody tell me? | | This means your program crashed. Probably you did something wrong. | But without seeing your code, it's impossibly for us to tell. | | Frank | | -- | Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/, 7977168E | GPC To-Do list, latest features, fixed bugs: | http://www.gnu-pascal.de/todo.html | GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707 | |
Silvio a Beccara wrote:
Dear Frank,
here you find the code responsible for the error. As already said, it works just fine as far as it is called only a few times, but results in the aforementioned message when things become intensive.
procedure addoneket ( var ktsa: PMatr2Dob10; neact: integer; var lastket: integer );
I can't compile a single procedure.
Besides, the bug is likely outside of the procedure, and quite likely not a GPC bug. I don't have the time to debug your program, I'm afraid. Maybe someone else here can help you, but they'd *at least* need complete information, i.e., a complete program.
Frank
Actually, by taking (of all things) *COMMENTS* out of my code, I can prevent it from compiling.
perfectly well. But these are all problems that occur when compiling
(not when running a compiled program, as is the case with Frank Engel's topas).
opas
===== ======= Frank D. Engel, Jr.
Modify the equilibrium of the vertically-oriented particle decelerator to result in the reestablishment of its resistance to counterproductive atmospheric penetration.
__________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
Frank D. Engel, Jr. wrote:
Actually, by taking (of all things) *COMMENTS* out of my code, I can prevent it from compiling.
From compiling or crashing? If the former (and reproducibly), this
would help.
Adriaan van Os wrote:
One way to do that is to use stress testing tools, which is why I were experimenting with the --param option (to stress test the gnu garbage collector). Also, I will see if I can build gpc with Apple's debugging version of malloc. But -- it could even be something as bizar as a bug in Mac OS X's disk cache system (I am just speculating). Frank mentioned hardware failures.
Not unlikely with the current temperatures, at least in Europe. Usually, my machine is quite reliable, but in the last few days it got a number of random crashes due to thermic problems. (Almost reproducible in that a longer optimizing compilation in the afternoon was quite likely to crash at some point ...)
Frank
Adriaan van Os wrote:
A volatile bug in GPC were to explain the internal compiler errors that I sometimes get for Pascal source that compiles at other times perfectly well. But these are all problems that occur when compiling (not when running a compiled program, as is the case with Frank Engel's topas).
Warning : GPI file `gpcmacosall.gpi' does not contain nodes chunk GPCStringsAll.pas line 5
../../gpc-3.3d7/gcc/p/module.c:1714:get_node_id: failed assertion `n < wb.count'
../../gpc-331d1/gcc/p/module.c:351:mseek: failed assertion `O <= F->size'
These ones are probably a consequence of a previous error which caused GPC to crash while creating a GPI file.
If they happen without a previous (WRT to the age of the GPI files involved, of course) other error, let me know.
Frank
-
Adriaan van Os -
Frank D. Engel, Jr. -
Frank Heckenbach -
Jean-Pierre Vial -
Peter N Lewis -
Silvio a Beccara -
Tom Verhoeff