Panic (1002) Target OS: Linux for x86 ppcx64 can't be executed lazarus / 64-FPC development ---------------------------------------------------------------------- quantumfoam · 2022-11-25 23:20 I'm reporting what looks like compiler bug. Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i program Project1; type  PA_Node = ^TA_Node;  TA_Node = array[0..3] of PA_Node;   var n1,n2:PA_Node;begin  n2 := nil;  n1[3] := n2; // Panic (1002) Target OS: Linux for x86 ppcx64 can't be executed; error code -139//   n1^[3] := n2; // this of course works, I would just expect less panic for just forgotten caretend.   EDIT: @MarkMLl OS: Linux Mint 21 Cinnamon, 64 bit, Linux Kernel: 5.15.0-53-generic PC: AMD Athlon 200GE with Radeon Vega Graphic x 2, 8GB RAM Lazarus: ver. 2.2.4 Date: 2022-01-03 FPC version 3.2.2 x86_64-linux- gtk2 Installers: fpc-laz_3.2.2-210709_amd64.deb, fpc- src_3.2.2-210709_amd64.deb, lazarus-project_2.2.4-0_amd64.deb @Thaddy It does not compile. This is just simplified example. In my real code it was way harder to find. ---------------------------------------------------------------------- ccrause · 2022-11-26 04:34 Indeed, seems like the compiler falls into an endless loop between compared_defs_ext and equal_defs trying to find a suitable type conversion for your example.  This ends in a SIGSEGV, due to the eventual stack overflow. ---------------------------------------------------------------------- MarkMLl · 2022-11-26 07:36 Quote from: quantumfoam on November 26, 2022, 12:20:28 amI'm reporting what looks like compiler bug. In which case you need to say what version of the compiler you're running, and precisely what your execution environment is. I would suggest editing your original message to include that so that all the important info is in one place. Please do not rely on putting it in your signature, since as soon as you change your sig all the context information in older postings will be lost. MarkMLl ---------------------------------------------------------------------- Thaddy · 2022-11-26 08:54 As far as I can see that code should always result in runerror 216 in all modes and all supported targets. That is not a compiler error, but programmer error. I have to test it, though, but I am quite sure. I expect the code to compile, but raise an error at runtime. Today no compiler at hand until afternoon. ---------------------------------------------------------------------- MarkMLl · 2022-11-26 11:10 Is n1[3] := n2 valid though? n1 is a classical pointer rather than (a pointer to) an (instance of) a class or some maintained type where I'd expect a missing dereference to be tolerated. MarkMLl ---------------------------------------------------------------------- Thaddy · 2022-11-26 11:12 Quote from: MarkMLl on November 26, 2022, 12:10:18 pmIs n1[3] := n2 valid though? n1 is a classical pointer rather than (a pointer to) an (instance of) a class or some maintained type where I'd expect a missing dereference to be tolerated. MarkMLl It also depends on mode. ---------------------------------------------------------------------- Thaddy · 2022-11-26 14:56 Now have been able to test it for mode fpc, objpas and delphi: as I suspected, well, expected, runerror 216, access violation. Linux and Windows. That code is plain wrong. It will always fail (well, almost always if for some reason you have luck). @MarkMLI in Mode Delphi, automatic deferencering is always on, so both forms should work (and do compile). But BOTH forms of the code crash as I expected.... Note I can not reproduce a kernel panic or crash, just the access violation. (all user mode) (And at OP: the code does compile, you will just get a runtime error 216 as I predicted. My brain compiler from this morning is error prone, but not in this case and after testing with the real Freepascal compilers) ---------------------------------------------------------------------- MarkMLl · 2022-11-26 16:40 Quote from: Thaddy on November 26, 2022, 03:56:56 pm@MarkMLI in Mode Delphi, automatic deferencering is always on, so both forms should work (and do compile). But BOTH forms of the code crash as I expected.... In the general case, I'd not expect automatic dereferencing to apply to an ordinary array type i.e. with a declared number of parameters. If FPC does that... well, I'd much rather not get into yet another fight about whether it departs unduly from the spirit of Pascal as a simple strongly-typed language :-/ MarkMLl ---------------------------------------------------------------------- marcov · 2022-11-26 16:54 quantumfoam: A compiler crash (GPF/runtime error, internal error) is always a bug, no matter how nonsensical the code is. Please report it with the reproducing piece of code in the bugtracker (which you already have). If the example is extremely contrived (and IMHO this is not it), it just might take longer to resolve as it will not be high on the priority lists. But it is still a bug. ---------------------------------------------------------------------- Thaddy · 2022-11-26 17:06 Marco, it is not a compiler crash. ---------------------------------------------------------------------- marcov · 2022-11-26 21:07 Quote from: Thaddy on November 26, 2022, 06:06:22 pmMarco, it is not a compiler crash. Quotemarcov@minerva:~$ ppcx64 test Hint: End of reading config file /home/marcov/.fpc.cfg Target OS: Linux for x86-64 Compiling test.pp test.pp(10,3) Warning: Variable "n1" does not seem to be initialized Segmentation fault So what do you call a segmentation fault then? An "oopsie"?