Number 3.2 is not dead - it can look into the future !!! - or is it Voodoo ?

[paule32]

Hello,
I checked my Application, and came to the Conclusion, that FPC can look into the Future.
As example, I used my own custom system.pas with this Code:

Code: Pascal  [Select][+][-]

1. {$mode delphi}
2. program test1;
3. var
4.   s1, s2: String;
5.   p1, p2: PChar;
6. begin
7. s1 := 'mufoLo';
8. s2 := 'Hello World  --> ' + s1;
9.   MessageBox(0,s2,s1,0);
10.   //move(p1, p2, sizeof( char ));
11. end.
12.  

If you compile, and start this Application under Windows 11 Desktop, you get a nice MessageBox on the Screen.
Okay, not happends else...

But, when you use this Code:

Code: Pascal  [Select][+][-]

1. {$mode delphi}
2. program test1;
3.  
4. var
5.   s1, s2: String;
6.   p1, p2: PChar;
7. begin
8. s1 := 'mufoLo';
9. s2 := 'Hello World  --> ' + s1;
10.   MessageBox(0,s2,s1,0);
11.   move(p1, p2, sizeof( char ));
12. end.
13.  

FPC begin to look into the Future...

Why did I ask it there ?
Now, lets show the MessageBox - it will be displayed on Desktop (0 - Handle).
but, before you start the Application, the Second Line will cause a ill formed Action, so Windows print out the 0xc00005 Error.

Why in the hell, look FPC into the Future ?
I never saw an Application, that call a modal Dialog - or is MessageBox not Modal ?

Okay, with Handle 0, it is not modal, and the background Application will run into a message Loop that call your main code, and display a MessageBox all the Time.

Let's try it with an other Application Handle (e.g. 1520).
You could see the differences ?

For me, I was thinking, that the Application Loop is stared, and will be resume, when the User close the Dialog...

Something Voodoo goes non there ... 

[rvk]

I never saw an Application, that call a modal Dialog - or is MessageBox not Modal ?

No, a MessageBox (from Windows API) is only modal if you provide a HWnd.
If HWnd is null it will be non-modal dialog.

I'm not sure where but this must be documented somewhere.

[Martin_fr]

So what does your code for "MessageBox" look like?

With the default this does not compile.  I can add unit "windows", but even then I need to make changes.

But if I do:

Code: Pascal  [Select][+][-]

1.     {$mode delphi}
2.     program test1;
3.     uses windows;
4.     var
5.       s1, s2: String;
6.       p1, p2: PChar;
7.     begin
8.     s1 := 'mufoLo';
9.     s2 := 'Hello World  --> ' + s1;
10.       MessageBox(0,pchar(s2),pchar(s1),0);
11.       move(p1, p2, sizeof( char ));
12.     end.
13.  

Then it runs, and shows the messagebox. And no error until I close it.

[rvk]

With the default this does not compile.  I can add unit "windows", but even then I need to make changes.

He probably uses his own rtl but keeps forgetting to mention that.

@paule32 Please mention that fact in all your posts (if it applies).

Or put it in your signature in capital letters so no one can miss it.

[Martin_fr]

He did mention it:

I used my own custom system.pas

.

But that still doesn't tell me what code is executed by that call. Nor if it is inlined...


Let's for a moment pretend the crash happens in the MessageBox call (or inlined code). Then, if it happened on the last instruction the IP points to the next instruction => the "move" line. (Or the stack may unroll to that).

Yes, I did read that the error does not happen if there is no next line. But the existence of that line (and therefore the use of extra variables) can change memory layout and register allocation. So theoretically, it could affect the call, and make MessageBox crash.


Which reminds me, he said 3.2

And 3.2 has an issue in the optimizer that can screw up the register allocator if compiled with O2 or above.... Very rare occurring, very hard to trigger. But another could be.

In the end, more info is needed.
- the code for MessageBox
- the asm of the routine that crashes, maybe the caller too.
- ...

Or a working replacement for my broken crystal ball.

[paule32]

@Martin_fr:
I use the "move" function with my custom system.pas, and the "compiler" function's that are internal used by the FPC 3.2. RTL.
When the function "move" does not work, then I could not get the text in the MessageBox.
Because there are some magic things, to "use", and "add" AnsiStrings in the WriteLn procedure.

I have update the source codes + batch.bat file, which is used to compile first the FPC_RT.DLL, and then the test1.exe
I did have some typos, but now, I am ready to create PE .DLL und PE .EXE files with the on-board-tools that come with the FPC package.
Before my other test's, I used mingsys64 (msys2) tools, to link .exe file from all *.o and *.a files.

But now, I only use FPC, and nasm64 - the netwide assemble, available for a range of operating systems.

The current stand (08.04.2024) is:
https://github.com/paule32/Qt_FPC

[Martin_fr]

Have you checked if it crashes, if you use -O- instead of -O3 ?

I had a quick look at the batch.

I noted that you build fpintres before you build your own system unit. So I would guess that unit is still build against the normal system unit coming with fpc? That seems odd?


If it crashes wit -O-
Can I chose the easier way (easier for me)? And ask for the asm output of the crash? (and the entire routine leading up to it)

Actually, for side by side comparison:
- the asm of the code that will crash
- the asm of the code that will not crash

Ideally compiled with -O- -alr

Also, I am sure you checked that when the debugger shows the crash location, that it is at the top-level of the stack, and not showing the caller.

[paule32]

Have you checked if it crashes, if you use -O- instead of -O3 ?

not yet.

I had a quick look at the batch.

I noted that you build fpintres before you build your own system unit. So I would guess that unit is still build against the normal system unit coming with fpc? That seems odd?

yes, you right. I used my own custom system.pas, and using the fpc option -n  (for not use standard units)

If it crashes wit -O-
Can I chose the easier way (easier for me)? And ask for the asm output of the crash? (and the entire routine leading up to it)

not tested, yet.
you can use at your own by modify the build.bat ch file.

Actually, for side by side comparison:
- the asm of the code that will crash
- the asm of the code that will not crash

This are the information's, that I could gatter:

Code: Text  [Select][+][-]

1. Possible file format: Portable executable for AMD64 (PE) (E:\Program Files\IDA Freeware 8.4\loaders\pe64.dll)
2.  
3.   bytes   pages size description
4. --------- ----- ---- --------------------------------------------
5.    524288    64 8192 allocating memory for b-tree...
6.     65536     8 8192 allocating memory for virtual array...
7.    262144    32 8192 allocating memory for name pointers...
8. -----------------------------------------------------------------
9.    851968            total memory allocated
10.  
11. Loading processor module E:\Program Files\IDA Freeware 8.4\procs\pc64.dll for metapc...Initializing processor module metapc...OK
12. Autoanalysis subsystem has been initialized.
13. Loading file 'E:\Projekte\fpc-qt\src\tests\test1.exe' into database...
14. Detected file format: Portable executable for AMD64 (PE)
15.   0. Creating a new segment  (0000000000401000-0000000000402000) ... ... OK
16.   1. Creating a new segment  (0000000000402000-0000000000404000) ... ... OK
17.   2. Creating a new segment  (0000000000404000-0000000000405000) ... ... OK
18.   3. Creating a new segment  (0000000000405000-0000000000406000) ... ... OK
19.   4. Creating a new segment  (0000000000406000-0000000000407000) ... ... OK
20. Reading imports directory...
21.   5. Creating a new segment  (0000000000406110-0000000000407000) ... ... OK
22.   6. Creating a new segment  (00000000004060B0-0000000000406110) ... ... OK
23. Type library 'mssdk64_win7' loaded. Applying types...
24. Types applied to 8 names.
25. Plan  FLIRT signature: SEH for vc64 7-14
26. Marking typical code sequences...
27. Flushing buffers, please wait...ok
28. File 'E:\Projekte\fpc-qt\src\tests\test1.exe' has been successfully loaded into the database.
29. Hex-Rays Decompiler plugin has been loaded (v8.4.0.240320)
30.   License: 48-F4EE-0000-00 Freeware version (1 user)
31.   The decompilation hotkey is F5.
32.   Please check the Edit/Plugins menu for more information.
33. Using FLIRT signature: SEH for vc64 7-14
34. Propagating type information...
35. Function argument information has been propagated
36. The initial autoanalysis has been finished.
37. 400000: process E:\Projekte\fpc-qt\src\tests\test1.exe has started (pid=16088)
38. 7FFC82C00000: loaded C:\Windows\System32\ntdll.dll
39. 7FFC82030000: loaded C:\Windows\System32\KERNEL32.DLL
40. 7FFC804B0000: loaded C:\Windows\System32\KERNELBASE.dll
41. 7FFC7D390000: loaded C:\Windows\SYSTEM32\apphelp.dll
42. 7FFC82C16A00: thread has started (tid=14888)
43. 7FFC820F0000: loaded C:\Windows\System32\user32.dll
44. 7FFC80A20000: loaded C:\Windows\System32\win32u.dll
45. 10000000: loaded E:\Projekte\fpc-qt\src\tests\fpc_rtl.dll
46. 7FFC82C16A00: thread has started (tid=4504)
47. 7FFC81BD0000: loaded C:\Windows\System32\GDI32.dll
48. 7FFC80270000: loaded C:\Windows\System32\gdi32full.dll
49. 7FFC80840000: loaded C:\Windows\System32\msvcp_win.dll
50. 7FFC80390000: loaded C:\Windows\System32\ucrtbase.dll
51. 7FFC82C16A00: thread has started (tid=17460)
52. 7FFC82C3CBA3: The instruction at 0x7FFC82C3CBA3 referenced memory at 0x106C6C64. The memory could not be read -> 00000000106C6C64 (exc.code c0000005, tid 16380)
53. PDBSRC: loading symbols for 'C:\Windows\System32\ntdll.dll'...
54. PDB: using PDBIDA provider
55. PDB: downloading http://msdl.microsoft.com/download/symbols/ntdll.pdb/3505304BE2C7C2D86FB32785BC2F9FBC1/ntdll.pdb => C:\Users\JENSKA~1\AppData\Local\Temp\ida\ntdll.pdb\3505304BE2C7C2D86FB32785BC2F9FBC1\ntdll.pdb
56. PDB: loading C:\Users\JENSKA~1\AppData\Local\Temp\ida\ntdll.pdb\3505304BE2C7C2D86FB32785BC2F9FBC1\ntdll.pdb

In the attachment, a screen shot.

[rvk]

I had a quick look at the batch.

I couldn't even build your rtl.

After changing your build.bat (which is a mess with all the hard path coding, even at the end for the test-dll)
I get an compilation exception.

fpintres.pp(3,10) Error: Compilation raised exception internally
Fatal: Compilation aborted
An unhandled exception occurred at $0000000100082D3D:
EAccessViolation: Access violation
  $0000000100082D3D  push,  line 1934 of symdef.pas
  $00000001001FA24D  AddUnit,  line 204 of pmodules.pas
  $00000001001FA2DD  AddUnit,  line 221 of pmodules.pas
  $00000001001FA6FF  loadsys]"]>Blockednit,  line 349 of pmodules.pas
  $00000001001FC61D  proc_unit,  line 1352 of pmodules.pas
  $0000000100043496  compile_module,  line 480 of parser.pas
  $0000000100061988  continue,  line 269 of ctask.pas
  $0000000100061B26  processqueue,  line 334 of ctask.pas
  $000000010001B0A4  Compile,  line 310 of compiler.pas
  $0000000100001ABD  $main,  line 308 of pp.pas
  $00000001000026B6  main_wrapper
  $0000000100013AD0  Exe_entry,  line 83 of x86_64/cpuwin.inc
  $00000001000018A0  _FPC_mainCRTStartup,  line 107 of sysinit.pp
  $00007FFC3BA27344
  $00007FFC3BCC26B1

After that, the errors keep piling up (which is logical if the first already fails).

There is also no Qt_FPC\src\sources\fpc-sys\fpcdll.asm

[Martin_fr]

Something else...

If your "move" has the same signature as the one by fpc

Code: Pascal  [Select][+][-]

1. Procedure Move(const source;var dest;count:...);

that is source, dest are untyped

then

Code: Pascal  [Select][+][-]

1.       move(p1, p2, sizeof( char ));

should not crash.

the values (pointers) in p1 and p2 may be random. But the 2 variables holding the pointers are on the heap, and accessible (you can read/write the random value of the pointer itself)

untyped params, mean you hand the address where the pointer is stored, not where it points to. And the "move" copies one byte from the variable (from the pointer stored in p1) to the other....

So whatever crashes => it is something else.

[Martin_fr]

In your asm...

You have 2 calls sub_40.....
I can only assume, that they are string related. assign, and append maybe.

If I compile with normal FPC, I get similar code for "s1 :=..." and "s2 := ...".

So that looks ok....


I don't know where 0x106C6C64 is... (the address mentioned in the error).
Or how it is derived...

As for the crash relating on the "move" present => I think that is just because it changes mem layout.
So without the move, whatever goes wrong, just coincidently points to data that prevents the crash.
But it would need much deeper debugging to confirm that...

[paule32]

@rvk:
I had update the sources, so the paths should be rleative.
I have add some remainder as comments in the build.bat ch file.

You have to replace the E:\Projekte... Path with your needs.

Note: I copied some .exe tools from a 32-Bit, and 64-Bit version of FPC 3.2.0 to the same folder where the 32-Bit tools resides for Windows 32-Bit PE executable files for:
- as.exe => as32.exe, as64.exe
- ld.exe => ld32.exe, ld64.exe
- fpc.exe => fpc32.exe, fpc64.exe
- nasm.exe (64-Bit Windows 10 Version)
- strip.exe
...

I don't use standard units (command line option -n)
All automated test's should be work under the 32-Bit Windows Console Host, now.

[Martin_fr]

Ok, I didn't look at the stack...

But, it is cut off....

It shows "move" inside the stack. But if it is "move + offset" (cut off?) then it could be an unlabelled jump-pad after the code for move....

I suggest to asm-single step the code.

EDIT:

It also appears that this is just a hex dump of the stack memory. Not an actual frame by frame stack. So addresses on that stack aren't necessarily callers....

[rvk]

I had update the sources, so the paths should be rleative.
I have add some remainder as comments in the build.bat ch file.

Change the exit in goto :eof
(it does the same but doesn't exit a cmd if you happen to be in one)

I changed the set prjdir in %cd%   (current directory because I start it in src)
Changed fpcdir1=q:\fpc and asmdir=q:\fpc
(I copied fpc.exe and ppcx64.exe and nasm.exe in that directory)

It fails in

C:\Users\Rik\Qt_FPC\src>q:\fpc\fpc.exe -Twin64 -Mdelphi -dwindows -dwin64 -v0     -FiC:\Users\Rik\Qt_FPC\src\sources\fpc-win     -FiC:\Users\Rik\Qt_FPC\src\sources\fpc-rtl     -FiC:\Users\Rik\Qt_FPC\src\sources\fpc-gnu     -FiC:\Users\Rik\Qt_FPC\src\sources\fpc-qt     -n     -O3 -Op3 -Os     -Si -Sc  -Sg     -Xd -Xe  -XD -CX -XXs     -sh -Ur      -WA -WD -WN -Anasmwin64 -al -vl     -FuC:\Users\Rik\Qt_FPC\src\sources\fpc-sys     -FuC:\Users\Rik\Qt_FPC\src\sources\fpc-qt      -FuC:\Users\Rik\Qt_FPC\src\units\fpc-rtl     -FuC:\Users\Rik\Qt_FPC\src\units\fpc-sys     -FuC:\Users\Rik\Qt_FPC\src\units\fpc-win     -FuC:\Users\Rik\Qt_FPC\src\units\fpc-qt -Anasmwin64 -al -dwindll     -FEC:\Users\Rik\Qt_FPC\src\units\fpc-sys C:\Users\Rik\Qt_FPC\src\sources\fpc-sys\fpintres.pp
2 207/768 Kb Used
fpintres.pp(3,10) Error: Compilation raised exception internally
Fatal: Compilation aborted
An unhandled exception occurred at $0000000100082D3D:
EAccessViolation: Access violation
  $0000000100082D3D  push,  line 1934 of symdef.pas
  $00000001001FA24D  AddUnit,  line 204 of pmodules.pas
  $00000001001FA2DD  AddUnit,  line 221 of pmodules.pas
  $00000001001FA6FF  loadsys]"]>Blockednit,  line 349 of pmodules.pas
  $00000001001FC61D  proc_unit,  line 1352 of pmodules.pas
  $0000000100043496  compile_module,  line 480 of parser.pas
  $0000000100061988  continue,  line 269 of ctask.pas
  $0000000100061B26  processqueue,  line 334 of ctask.pas
  $000000010001B0A4  Compile,  line 310 of compiler.pas
  $0000000100001ABD  $main,  line 308 of pp.pas
  $00000001000026B6  main_wrapper
  $0000000100013AD0  Exe_entry,  line 83 of x86_64/cpuwin.inc
  $00000001000018A0  _FPC_mainCRTStartup,  line 107 of sysinit.pp
  $00007FFC3BA27344
  $00007FFC3BCC26B1

Error: q:\fpc\ppcx64.exe returned an error exitcode

O wait... I use fpc trunk 3.3.1. That's probably it.

Free Pascal Compiler version 3.3.1-15529-g80750f7591 [2024/04/08] for x86_64
Copyright (c) 1993-2024 by Florian Klaempfl and others

I guess you need absolute fpc 3.2.2.

[paule32]

I guess you need absolute fpc 3.2.2.

I use 3.2.0 64-Bit Version.
You see the difference of fpc.exe and ppcx64.exe (in yout qoute) ?