|
|
lazarus.png (3,869 bytes) |
|
|
I cannot reproduce. Must be an FPC issue. Please test with released FPC. |
|
|
Hello Juha Manninen, thank you for your information. I tried it with my last previous FPC-Revision 48802. It works correctly. I dont know in which Revision between 48802 and 48871 this error was produced. Perhaps you can inform the FPC developers. R. Sombrowsky |
|
|
I moved this to FPC project. It would help if you bisect between 48802 and 48871 to find the exact guilty revision. |
|
|
I got following error when starting Lazarus with OPM [FORMS.PP] ExceptionOccurred Sender=EReadError Exception=Error reading MainDM.Height: Access violation Stack trace: $00000000005473CA $0000000000546519 $000000000070F48E INITLAZRESOURCECOMPONENT, line 3180 of lresources.pp $0000000000706741 INITRESOURCECOMPONENT, line 798 of lresources.pp $000000000054004C $00000000015F3D7F ONLINEPACKAGEMANAGERINTF_$$_init$, line 78 of onlinepackagemanagerintf.pas $0000000000437FFC TApplication.HandleException: EReadError Error reading MainDM.Height: Access violation Stack trace: $00000000005473CA $0000000000546519 $000000000070F48E INITLAZRESOURCECOMPONENT, line 3180 of lresources.pp $0000000000706741 INITRESOURCECOMPONENT, line 798 of lresources.pp $000000000054004C $00000000015F3D7F ONLINEPACKAGEMANAGERINTF_$$_init$, line 78 of onlinepackagemanagerintf.pas $0000000000437FFC Exception at 00000000005473CA: EReadError: Error reading MainDM.Height: Access violation. Failing revision is 48841 |
|
|
After a lot of tries I found that the last correct FPC-revision was 48840. The FPC-revision 48841 was the first with this error. The Lazarus-revision was 64743. The autor of FPC-revision 48841 was "florian" on Sundy 28.02.2021 |
|
|
I needed to revert FPC to this commit: commit baf2f57fa98fdc49f2714a59f5df69eb2b88a73a Author: Tomas Hajny <hajny@freepascal.org> Date: Sun Feb 28 10:29:59 2021 +0000 * align shortname to previous releases git-svn-id: https://svn.freepascal.org/svn/fpc/trunk@48839 3ad0048d-3df7-0310-abae-a5850022a9f2 to be able to build and execute the bigide Lazarus version. |
|
|
r48841 is a new optimization. If you build Lazarus without optimization, does it work? Next you must isolate the error into a smaller test program. |
|
|
A few tests: Lazarus-2.1-64751_fpc-3.3.1-48880 optimized -- crash Lazarus-2.1-64751_fpc-3.3.1-48880 normal -- crash Lazarus-2.1-64751_fpc-3.3.1-48880 r48841_revert.patch normal -- ok Lazarus-2.1-64751_fpc-3.3.1-48880 r48841_revert.patch optimized -- ok Something with the side effect detection is wrong: The pattern (a and b) or (c and not(b)) -> c xor ((c xor a) and b) is matched by (Assigned(Ancestor) and (FDPPI<>Ancestor.FDPPI)) or (not Assigned(Ancestor) and (FDPPI<>96)); So the field access is not protected by the short-circuit of Assigned(Ancestor). |
|
|
(fixed "TDataModul" in title and description to be "TDataModule") |
|
|
Thanks everybody for the analysis. Can you please check/confirm that r48884 fixes the issue? |
|
|
Sorry, I needed a few more trials, please test with at least r48886. |
|
|
Hi florian, I checked the Lazarus Rev. 64756 and FPC Rev. 48887 It works correct. Thank you. |
|
|
Aye, can confirm, seems to be fixed. Thanks! |
|
|
Success. |
|
|
Failure :( Apple aarch64, macOS 11.2.2 (Big Sur). Lazarus executable built with the bigide argument still dies on startup: trev@macmini8 [/Users/trev/laz_trunk] $ ./lazarus [FORMS.PP] ExceptionOccurred Sender=EReadError Exception=Error reading MainDM.Height: Access violation Stack trace: $00000001030888F4 $000000010307C498 $000000010307E550 $0000000103089588 $00000001031570D4 $0000000103156E4C $000000010314DD40 $0000000103080FBC $000000010307DB8C $0000000104185C38 TApplication.HandleException: EReadError Error reading MainDM.Height: Access violation Stack trace: $00000001030888F4 $000000010307C498 $000000010307E550 $0000000103089588 $00000001031570D4 $0000000103156E4C $000000010314DD40 $0000000103080FBC $000000010307DB8C $0000000104185C38 Exception at 00000001030888F4: EReadError: Error reading MainDM.Height: Access violation. (lldb) target create "./lazarus" Current executable set to '/Users/trev/laz_trunk/lazarus' (arm64). (lldb) r Process 13892 launched: '/Users/trev/laz_trunk/lazarus' (arm64) Process 13892 stopped * thread 0000001, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x70) frame #0: 0x000000010010a2a8 lazarus`CLASSES$_$TDATAMODULE_$__$$_DEFINEPROPERTIES$TFILER + 120 lazarus`CLASSES$_$TDATAMODULE_$__$$_DEFINEPROPERTIES$TFILER: -> 0x10010a2a8 <+120>: ldr w2, [x0, #0x70] 0x10010a2ac <+124>: cmp w2, w1 0x10010a2b0 <+128>: cset w2, ne 0x10010a2b4 <+132>: cmp w1, #0x60 ; =0x60 Target 0: (lazarus) stopped. |
|
|
@Trevor: So this worked with 48840 ? |
|
|
The last version I had working was 48839 (according to git - not sure whether the svn/git versioning lines up perfectly). |
|
|
48440 builds but cannot compile Lazarus due to the fpcres binary being killed on startup. I managed to get it working by rsync'ing a copy from /usr/local/share/fpcsrc/3.3.1/utils/fpcres/bin/aarch64-darwin/fpcres to /usr/local/bin. Then, yes, 48440 builds a bigide Lazarus executable that does not die on startup and seems to compile working native arm apps without issue. |
|
|
I really cannot reproduce it (though I am testing aarch64-linux and not aarch64-darwin, but there should be no difference in this regard). r48841 produces .Lj5422: ldr w1,[x19, 0000144] // [103] HavePPIData:=(Assigned(Ancestor) and (FDPPI<>Ancestor.FDPPI)) or ldr w2,[x0, 0000144] cmp w2,w1 cset w2,ne // [104] (not Assigned(Ancestor) and (FDPPI<>96)); cmp w1,0000096 cset w1,ne eor w2,w1,w2 cmp x0,#0 cset w0,ne and w0,w0,w2 eor w21,w1,w0 which is not valid. But with r48887 at least all problems are fixed and I get: // [103] HavePPIData:=(Assigned(Ancestor) and (FDPPI<>Ancestor.FDPPI)) or cbz x0,.Lj5424 ldr w1,[x19, 0000144] ldr w2,[x0, 0000144] cmp w1,w2 b.ne .Lj5425 .Lj5424: // [104] (not Assigned(Ancestor) and (FDPPI<>96)); cbnz x0,.Lj5426 ldr w0,[x19, 0000144] cmp w0,0000096 b.ne .Lj5425 |
|
|
Anything more I can do to help? I can provide VNC access to an M1 Mac mini if it helps. |
|
|
My knowledge about MacOS X is too little to make use of this. Did you really check that the compiler is up-to-date and that the classes.o is recompiled by this compiler? Else if a trunk compiler still matches this pattern wrong only in this case on aarch64-darwin, then there must be something really really weird going on. |
|
|
I have found the issue after investigating why the newly compiled fpcres binary was being killed on startup. The Big Sur of macOS for m1 aarch64 will not run any unsigned code (luckily the linker automatically signs the executables with an ad hoc signature and generates. a matching cdhash (code directory hash). The cdhash is used when macOS checks code before running it to verify that the contents of a binary have not changed since being code signed. The code signing information is hung off a vnode within the kernel, and modifying the file behind that cache causes the problem - you need a new vnode, which means a new file, that is, a new inode. So if the new executable gets copied over the old executable and the inode remains the same, the cdhash no longer matches and the application is killed on startup by the system. The same thing was happening with the Lazarus executable. Sorry to have wasted your time Florian. The current FPC trunk version of Sun Mar 21 21:39:57 2021 compiles the trunk Lazarus bigide version successfully. |
|
|
Thanks for confirming :) |
- Anonymous
