FPC 64-bit and sample "30 - MVC Server"

MilanKG · 2018-02-25 10:04:40

Hi, i'm Milan and i'm new with Synapse mORMot,

I tried use sample "30 - MVC Server" with Lazarus 1.9 and FPC 3.1.1 with 64-bit build, win7 x64... on first look all works well, but when I navigate to a nonexistent link e.g "http://localhost:8092/blog/articleView?id=100009999",
MVC app crashed. In debug :

Debug1

Then "Break", "Continue"

Debug1

And finall app was crashed...

32-bit app works well without problems.

Last edited by MilanKG (2018-02-25 10:12:15)

ab · 2018-02-25 13:52:01

What do you call "crashed"?

This is not a crash, but an expected EMVCApplication exception.
The workflow should continue as expected, intercepting the exception and redirecting the HTTP client into the "404 not found" error page.

I guess this is more about a Lazarus/GDB problem/limitation/bug when dealing with exceptions.
Run it outside the debugger, and check the logs and the behavior of the server.

MilanKG · 2018-02-25 14:04:41

ab wrote:

What do you call "crashed"?
This is not a crash, but an expected EMVCApplication exception.
The workflow should continue as expected, intercepting the exception and redirecting the HTTP client into the "404 not found" error page.
I guess this is more about a Lazarus/GDB problem/limitation/bug when dealing with exceptions.
Run it outside the debugger, and check the logs and the behavior of the server.

I said, 32-bit build works fine and produces a 404 error page, while the 64-bit build is crashing.

MVC Crash

MilanKG · 2018-02-25 14:10:13

I using fpcupdeluxe with cross compiler for win (32 and 64 bit).. convert Delphi project to Lazarus... 32 works well, correct handle raise exception, but 64 bit build not

From some reason 64 build doesn't correct handle raise exception in MVCViewModel.pas, and for result app was crashed.
I hope I gave you enough informations for fix

Last edited by MilanKG (2018-02-25 14:16:45)

ab · 2018-02-25 14:13:18

Try to disable exception logging.

Also ensure you use the latest revision of the framework - current is 1.18.4340.

MilanKG · 2018-02-25 14:19:16

ab wrote:

Try to disable exception logging.
Also ensure you use the latest revision of the framework - current is 1.18.4340.

I'm newby with Lazarus and mORMot, so exactly where i can disable exception logging?

Yes.. i use latest version framework from github.

Last edited by MilanKG (2018-02-25 14:20:31)

MilanKG · 2018-02-25 14:30:04

More inf. -

Assembler

ab · 2018-02-25 14:31:44

Logs are already disabled for this sample by default.

I was able to reproduce the problem, and will try to find out the cause.

There is no problem on Win64 when compiled with Delphi - so it is a FPC-specific issue.

MilanKG · 2018-02-25 14:48:08

ab wrote:

Logs are already disabled for this sample by default.
I was able to reproduce the problem, and will try to find out the cause.
There is no problem on Win64 when compiled with Delphi - so it is a FPC-specific issue.

I doing next test... remove dir "Views" , and in this case 64 bit app work correct , because "raise" is from mORMotMVC.pas

FluxBB bbcode test

From some reason "raise" from MVCViewModel.pas not work well

ab · 2018-02-25 14:49:37

I've enabled the logs, built with debug information, then the logs shows on FPC / Win64:

2/25/2018 14:38:50.608	Exception	    EMVCApplication {"Message":"Error=404"} at   $00000001001C1E02  ARTICLEVIEW,  line 337 of MVCViewModel.pas
2/25/2018 14:38:50.624	Exception OS	    EExternalException (C0000005) at   $00000001000F5725  RAWEXECUTE,  line 60856 of ../../mORMot.pas

But in fact, the error happens when the exception is raised in the low-level CallMethod() function.
Sounds like if the exception is not propagated by FPC outside this function.

So the try..finally in TServiceMethodExecute.RawExecute() is not working as expected.

What is weird is that it works just fine on Win32.
On Win64, it also works when compiled with Delphi, but not when compiled with FPC.

MilanKG · 2018-02-25 14:50:31

ab wrote:

I've enabled the logs, built with debug information, then the logs shows on FPC / Win64:
2/25/2018 14:38:50.608	Exception	    EMVCApplication {"Message":"Error=404"} at   $00000001001C1E02  ARTICLEVIEW,  line 337 of MVCViewModel.pas
2/25/2018 14:38:50.624	Exception OS	    EExternalException (C0000005) at   $00000001000F5725  RAWEXECUTE,  line 60856 of ../../mORMot.pas
But in fact, the error happens when the exception is raised in the low-level CallMethod() function.
Sounds like if the exception is not propagated by FPC outside this function.
So the try..finally in TServiceMethodExecute.RawExecute() is not working as expected.
What is weird is that it works just fine on Win32.
On Win64, it also works when compiled with Delphi, but not when compiled with FPC.

So what is solution?

ab · 2018-02-25 14:58:49

The weirdest is that it works under Linux x86-64 (I just ensure this) with FPC.
(it is also reassuring for me, since FPC + Linux 64bit is a platform with premium importance for use - whereas FPC + Win64 was never one since the Delphi version works with no problem)

So I guess that there is some low-level exception unwinding problem specifically with FPC on Win64.
Sounds more than a FPC bug/limitation than a mORMot bug to me.

I don't see any way of circumventing the problem easily.

ab · 2018-02-25 15:03:57

AFAIR I already identified some kind of problem with FPC exception handling on Win64, when making SynLog.pas execption interception: I was forced to use the AddVectoredExceptionHandler Win64 API, since the official FPC RTL RaiseProc global variable was working with no problem on all platforms (Win32, Linux32, Linux64) but NOT on Win64.

I'm afraid this is linked to what we just observe....

Perhaps you may try to post a bug report to the FPC team, about RaiseProc not working under Win64.

MilanKG · 2018-02-25 15:08:53

ab wrote:

The weirdest is that it works under Linux x86-64 (I just ensure this) with FPC.
(it is also reassuring for me, since FPC + Linux 64bit is a platform with premium importance for use - whereas FPC + Win64 was never one since the Delphi version works with no problem)
So I guess that there is some low-level exception unwinding problem specifically with FPC on Win64.
Sounds more than a FPC bug/limitation than a mORMot bug to me.
I don't see any way of circumventing the problem easily.

Conclusion ... if i want build MVC server, for cloud.. whatever... because of cost, Lazarus and FPC is free, for win just 32 bit, but for linux can both 32 and 64 bit?
In future if i find any issue, i will report you .. thanks for your time and your answers

Have nice day

ab · 2018-02-25 15:19:02

Yes, for cloud, I would definitively use FPC + Linux x86_64 which is now stable enough for production.
If you can afford to pay the huge money for Windows cloud hosting, I guess you can either just use FPC + Win32 (which works fine), or afford to pay for Delphi Win64 compiler...

Anyway, for our problem, I don't see any easy way to circumvent this general exception issue.

For mORMotMVC, what we may do is add a new way of redirection.
For instance, we may add a new threadvar in which we put the exception to be raised, outside of the TServiceMethodExecute.RawExecute() scope.
(edit: I just started to implement it, but it was so ugly to use, that I erased my attempt)

MilanKG · 2018-02-25 15:29:35

ab wrote:

Yes, for cloud, I would definitively use FPC + Linux x86_64 which is now stable enough for production.
If you can afford to pay the huge money for Windows cloud hosting, I guess you can either just use FPC + Win32 (which works fine), or afford to pay for Delphi Win64 compiler...
Anyway, for our problem, I don't see any easy way to circumvent this general exception issue.
For mORMotMVC, what we may do is add a new way of redirection.
For instance, we may add a new threadvar in which we put the exception to be raised, outside of the TServiceMethodExecute.RawExecute() scope.

I'm Delphi (android, c, openwrt, etc.) programmer and working for some company... But i planing in future some my service, and of course i prefer Linux 64. MVC, mustache and others is new for me.. i'm still in phase studding..
I doing test with "Webserver Stress Tool" on sample "MVC Server" and results are impressive. I will be here to report if have any issue in future , and ask about SQL, non-SQL (what is the best for reading, what is the best for writing,
possibles to combine, what can work in memory, etc) .. etc...

Again, have nice day

mpv · 2018-02-25 15:36:13

In our implementation we call published methods using TMethod (as in old-old mormot) and everything is OK for FPC Win64 with exceptions (and the latest exception interception from SynLog work good. Thanks!). So something wrong inside low-level mORMot.CallMethod(). Sorry, but I do not understand how asm inside work to analyze deeper.

BTW I switch my development to FPC even for Windows because of 4 reason:
1) we buy XE2 many years ago, but in XE2 debugger for x64 target not work (complitation work)
2) we setup a continuous integration and need compiler on the CI server(s). I don't want to buy Delphi for my CI bots
3) XE2 IDE hangs sometimes on my project because of huge codebase. There is no such problems with FPC
4) I don't want to use Windows anymore. The more I study Linux, the more I understand that 20 years ago I made a big mistake by starting to develop under Windows. As far as I finish migration of my main project to Linux I will drop Windows on my laptop

Last edited by mpv (2018-02-25 15:36:48)

ab · 2018-02-25 15:53:18

@mpv
The problem is about unwinding exceptions under FPC + Win64.
There is an issue with FPC, which makes e.g. the official RaiseProc global procedure fail to work as it is on other platforms.
We circumvented this problem in SynLog by using the AddVectoredExceptionHandler Win64 API... but this is a workaround.
When working with a fake interface interception, our asm - which works correctly with Delphi - has problems with FPC, whereas there should be no difference when handling exceptions, since they handled at OS level, not as compiler features.
I'm not sure that any modification in mORMot asm may help anyway in this context.

mpv · 2018-02-28 07:19:26

Catch it!! Actual problem is inside SynLog.ExceptionInheritsFrom (we do not enter where for Linux build).
I'm create pull request
Just one strange thing - on FPC 3.1.1-r38162 [2018/02/08] ExceptionInheritsFrom works good. For older versions (I'm check for 3.0.2 & 3.0.4) patch required

ab · 2018-02-28 09:06:59

I don't understand well why it may fix the main problem, since even with AddVectoredExceptionHandler Win64 API this function is called.

Isn't just https://synopse.info/fossil/info/a801b139a4 a better fix?
The EOleSysError as defined in SynLog.pas will never match the one used from ComObj.pp - so your fix will never handle COM/DotNet errors as expected.

BTW there may be a similar issue in SyNodeSimpleProto.pas.
Perhaps TSMSimpleRTTIProtoObject.InitObject() could use SynCommons.GetPublishedMethods() and get rid of vmtParent?

ab · 2018-02-28 09:13:47

and https://synopse.info/fossil/info/077dbf58cc

mpv · 2018-02-28 09:35:51

Yes, your fix is better.
After this fix exception logging work well for FPC compilers 3.0.4 win64 & 3.1.1 win64:

20180228 09231051  ( EXC   		EMetabaseException {"errorCode":50,"Message":"Direct modification of UNITY entity tst_mainunity not allowed"} at   $000000010004B0C6 line 1760 of core/ubMixinClasses.pas

@MilanKG - please, verify your case on current trunk - it should not fails anymore.

About SyNode you are right and we already use SynCommons.GetPublishedMethods in fb_SyNode_fpc311

ab · 2018-02-28 09:42:21

@mpv Nice!

@MilanKG - I just checked sample 30 on FPC + Win64.
This doesn't fix the root problem of FPC exceptions improperly handled on this platform - as reported above https://synopse.info/forum/viewtopic.ph … 647#p26647
I still continue to believe that there is a implementation flow in FPC RTL.

MilanKG · 2018-03-01 20:55:00

@mpv @ab Still is same situation with new trunk

@ab Yes, i believe that is issue with FPC

-------------

I updated FPC with Revision 38393, but same situation.

Last edited by MilanKG (2018-03-01 22:33:50)

mORMot Open Source

#1 2018-02-25 10:04:40

FPC 64-bit and sample "30 - MVC Server"

#2 2018-02-25 13:52:01

Re: FPC 64-bit and sample "30 - MVC Server"

#3 2018-02-25 14:04:41

Re: FPC 64-bit and sample "30 - MVC Server"

#4 2018-02-25 14:10:13

Re: FPC 64-bit and sample "30 - MVC Server"

#5 2018-02-25 14:13:18

Re: FPC 64-bit and sample "30 - MVC Server"

#6 2018-02-25 14:19:16

Re: FPC 64-bit and sample "30 - MVC Server"

#7 2018-02-25 14:30:04

Re: FPC 64-bit and sample "30 - MVC Server"

#8 2018-02-25 14:31:44

Re: FPC 64-bit and sample "30 - MVC Server"

#9 2018-02-25 14:48:08

Re: FPC 64-bit and sample "30 - MVC Server"

#10 2018-02-25 14:49:37

Re: FPC 64-bit and sample "30 - MVC Server"

#11 2018-02-25 14:50:31

Re: FPC 64-bit and sample "30 - MVC Server"

#12 2018-02-25 14:58:49

Re: FPC 64-bit and sample "30 - MVC Server"

#13 2018-02-25 15:03:57

Re: FPC 64-bit and sample "30 - MVC Server"

#14 2018-02-25 15:08:53

Re: FPC 64-bit and sample "30 - MVC Server"

#15 2018-02-25 15:19:02

Re: FPC 64-bit and sample "30 - MVC Server"

#16 2018-02-25 15:29:35

Re: FPC 64-bit and sample "30 - MVC Server"

#17 2018-02-25 15:36:13

Re: FPC 64-bit and sample "30 - MVC Server"

#18 2018-02-25 15:53:18

Re: FPC 64-bit and sample "30 - MVC Server"

#19 2018-02-28 07:19:26

Re: FPC 64-bit and sample "30 - MVC Server"

#20 2018-02-28 09:06:59

Re: FPC 64-bit and sample "30 - MVC Server"

#21 2018-02-28 09:13:47

Re: FPC 64-bit and sample "30 - MVC Server"

#22 2018-02-28 09:35:51

Re: FPC 64-bit and sample "30 - MVC Server"

#23 2018-02-28 09:42:21

Re: FPC 64-bit and sample "30 - MVC Server"

#24 2018-03-01 20:55:00

Re: FPC 64-bit and sample "30 - MVC Server"

Board footer