Forum > FPC development

Panic (1002) Target OS: Linux for x86 ppcx64 can't be executed

(1/3) > >>

quantumfoam:
I'm reporting what looks like compiler bug.


--- Code: Pascal  [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---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:
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:

--- Quote from: quantumfoam on November 26, 2022, 12:20:28 am ---I'm reporting what looks like compiler bug.

--- End quote ---

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:
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:
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

Navigation

[0] Message Index

[#] Next page

Go to full version