You are not logged in.
The code is as follows
program test;
{$mode delphi}{$H+}
{$I mormot.defines.inc}
uses
{$I mormot.uses.inc}
Windows,
mormot.core.base,
mormot.core.variants;
var
s: UTF8String;
V: Variant;
begin
s := '{"code":200,"msg":"ok"}';
V := _Json(RawUtf8(s));
WriteLn(V.code, V.msg);
end.After compiling with the following command, the program crashed when running. (mormot2.lpk has been rebuilt.)
# c:\fpcbuild\fpc\bin\i386-win32\fpc -FiD:\Borland\mORMot2\src -FuD:\Borland\mORMot2\packages\lazarus\lib\i386-win32 test.lpr
Free Pascal Compiler version 3.3.1 [2026/10/16] for i386
Copyright (c) 1993-2026 by Florian Klaempfl and others
Target OS: Win32 for i386
Compiling test.lpr
Linking test.exe
1352 lines compiled, 0.2 sec, 570096 bytes code, 22244 bytes data
# test
An unhandled exception occurred at $0042E7CC:
EVariantTypeCastError: Could not convert variant of type (Null) into type (AnsiString)
$0042E7CC
$00427F1B
$0042C703
$0040CE6DHowever, after compiling with the following command, the program ran correctly.
# c:\fpcbuild\fpc\bin\i386-win32\fpc -FiD:\Borland\mORMot2\src -FuD:\Borland\mORMot2\src\core test.lpr
Free Pascal Compiler version 3.3.1 [2026/10/16] for i386
Copyright (c) 1993-2026 by Florian Klaempfl and others
Target OS: Win32 for i386
Compiling test.lpr
Linking test.exe
1354 lines compiled, 0.2 sec, 661616 bytes code, 22244 bytes data
# test
200okThe versions of FPC and Lazarus are as follows:
Lazarus 5.99 (rev main_5_99-117-g2130d7edc2) FPC 3.3.1 [2026/10/16] i386-win32-win32/win64
I remember that the programs compiled from previous versions of FPC did not have the aforementioned problems.
This issue caused my project to fail at runtime after being compiled with a newer version of FPC/Lazarus.
Last edited by idigger (2026-10-17 19:15:57)
Offline
It is not clear if it is a mormot issue or a fpc issue....
Confirmed that it is a mORMot issue.
After repeatedly switching between different mormot versions for testing, it was ultimately determined that the issue was caused by commit 835079437d00d5d03e95464221b28df96d9b2dd6(* core: optimized TSynInvokeableVariantType.DispInvoke() 2026-07-06 15:58:25).
Last edited by idigger (2026-10-18 14:52:52)
Offline
mormot2.lpk compiler options level need change to -O1
Offline
Compiling `mormot2.lpk` with `-O1` does indeed help. However, versions prior to commit `835079437d00d5d03e95464221b28df96d9b2dd6` could be compiled using the default `-O3` setting without any runtime errors; therefore, the issue is likely introduced by commit `83507943`.
Offline
Thanks for bisecting. I can't reproduce it with your test on FPC 3.3.1 aarch64-win64 (-O1/-O2/-O3) or FPC 3.2.2 aarch64-linux (-O1/-O3), all print 200ok. So it looks like an i386 optimizer problem in FPC trunk rather than a logic bug. Does it go away with -O2 for mormot.core.variants.pas only? And which FPC revision is it (fpc -iW)?
Offline
FPC revision is 3.3.1 i386-win32-win32/win64(main e1e32858), Compiling `mormot2.lpk` with `-O1` or `-O2` works as expected, but using `-O3` results in a crash after the program is linked and executed. However, if `mormot.core.variants.pas` is reverted to the state it was in at commit `343a2ed879b67fad9f493f2f610df515c912841e`, the code functions correctly under all three optimization levels: `-O1`, `-O2`, and `-O3`.
Offline
Sounds like a FPC bug to me.
Note that the LCL can't work properly in -O3 on Windows IIRC, so you should not use -O3 on Windows with FPC most of the time.
No problem on Linux/Posix with -O3 I guess.
Offline
After reverting commit 83507943 (*core: optimized TSynInvokeableVariantType.DispInvoke() 2026-07-06 15:58:25), everything works perfectly on Windows (with -O1/-O2/-O3).
Offline
I have reported this to the FPC team; hopefully, they will make improvements. (https://gitlab.com/freepascal.org/fpc/s … tems/42024)
Last edited by idigger (2026-10-27 18:57:18)
Offline
Does it crash if you delete Writeln line?
Offline
The crash was actually unrelated to whether WriteLn existed or not; it was caused by V.code and V.msg.
The test code crashed when modified as follows.
program test;
{$mode delphi}{$H+}
{$I mormot.defines.inc}
uses
{$I mormot.uses.inc}
Windows,
variants,
mormot.core.base,
mormot.core.variants;
var
s: UTF8String;
V: Variant;
n: Integer;
m: String;
begin
s := '{"code":200,"msg":"ok"}';
V := _Json(RawUtf8(s));
n := V.code;
m := VarToStr(V.msg);
//WriteLn(n, m);
end.# test.exe
An unhandled exception occurred at $0041D49C:
EVariantTypeCastError: Could not convert variant of type (Null) into type (Int64)
$0041D49C (test.exe+$1D49C)
$004162DC (test.exe+$162DC)
$00401C85 (test.exe+$1C85)The above code runs without errors when compiled with -O2 to mormot2.lpk.
Last edited by idigger (2026-10-29 13:16:48)
Offline
That is what I figured. I intentionally avoid variant late binding in my code, there have been reported problems in the past. I suggest you use TDocVariant directly.
Offline
Thank you for your suggestion. However, modifying a lot of the old code is quite troublesome. It would be great if the FPC team could make improvements. I look forward to FPC becoming more stable and stronger.
Last edited by idigger (2026-10-29 15:37:48)
Offline
What a coincidence! FPC commit e16bdacf (2026-10-29 5:02:51) inadvertently fixed this issue. After compiling mormot2.lpk with this version of FPC with -O3, the program linked and ran without any issues.
Last edited by idigger (2026-10-31 18:57:45)
Offline