[danPerraud]

Hello everyone,
I am experiencing a critical issue with my Delphi application that uses a dll compiled with Visual Prolog.
My application, written in Delphi, previously used a DLL compiled with Visual Prolog version 8 without any problems.

However, after recompiling the same DLL with Visual Prolog version 11, even though the compilation options remained the same and both versions were 32-bit, my application started crashing with access violation errors, this in purely Delphi processing, connection to the database, without any functions in the prolog dll being called yet.

Here is the behavior I observe: The application successfully loads the DLL using ‘loadlibrary’, and no immediate errors are reported at this point. No functions in the DLL have yet been called; it was just loaded in the process. The crash happens later, especially when the application tries to connect to the database, which is purely Delphi code and unrelated to the functions of the Prolog DLL.
To clarify, the database connection logic has not been changed and it is the same code that worked before the DLL update. The crash happens with an access violation, but it's confusing because it's not triggered by a direct call to the DLL.
If I remove the loadLibrary, it works.

Thank you for your help.

[Thomas Linder Puls]

Yes, that sounds peculiar. And quite difficult to assist with.

I suggest you try the following:

• Make sure your Visual Prolog dll builds the dll directly to the target directory.
• Switch on "Debug -> Break on Exception"
• Configure the Delphi program as executable in "Project -> Settings -> Run Options"
• Start the debugger
• If/when you receive an "Access Violation" dialog in the debugger you press "Break"

The tricky part is that it seems that this will happen in your Delphi code. But anyway try opening the run stack (View -> Run Stack) and see what is shown in this window. You can post an image here if you need further assistance (which seems likely ).

[danPerraud]

Thank you for your valuable response.
I ran a program in debug mode.
I get these exceptions one by one (I click on 'Continue' between each) :

>ScmWorkerProcess.exe -i inpipe1.pgi -auth Auth1.pgi -p 1
Exception 0x04242420: (0x04242420) , at address: 0x772FFA72 First Chance Continuable.
Exception 0xE0434352: (0xE0434352) , at address: 0x772FFA72 First Chance.
Exception 0xE0434352: (0xE0434352) , at address: 0x772FFA72 First Chance.
Exception 0xE0FA1104: Visual Prolog exception, at address: 0x772FFA72 First Chance Continuable.
Exception 0x80000003: User breakpoint, at address: 0x140071A5 First Chance Continuable.
Exception 0x80000003: User breakpoint, at address: 0x140071A5 First Chance Continuable.
Exception 0x80000003: User breakpoint, at address: 0x140071A5 First Chance Continuable.
Exception 0x80000003: User breakpoint, at address: 0x140071A5 First Chance Continuable.
....

[Thomas Linder Puls]

Fine, but ...

Can you click break instead of continue and then look at the run stack (menu: View -> Run stack (Ctrl+Alt+C)) in the problematic places.

There is a number of exceptions and most of them are most likely harmless, so the problem will be which one to focus on (the one that makes your program behave really bad). Also the Visual Prolog exception may of course be interesting.

I also notice that the exceptions only occurs at two addresses, so it may seem that there are actually only two exceptions which just happens to be signaled a number of times (not really sure why, but exception handling can be quite complex behind the scenes).

By the way none of these exceptions are Access Violations.

[danPerraud]

Here is a document that describes execution in debug mode:

Run+debug+VP+DLL.pdf

(133.17 KiB) Downloaded 144 times

[Thomas Linder Puls]

Thank you.

It seems that some of our runtime handling of non-Visual-Prolog threads is causing the problem.

We will investigate the problem. And perhaps we may ask you to test a new runtime DLL before we release it.

[danPerraud]

Thank you, I am available to carry out tests.

[danPerraud]

Thomas,
I confirm, the Delphi application at a given moment triggers threads on the Delphi side, and it is at this moment that there are exceptions which cause the program to crash.

I am therefore waiting for a release which corrects the problem or which will contain an option to deactivate thread monitoring on the prolog side.
Thank you so much.

[Thomas Linder Puls]

We don't monitor threads for fun, so it is not an option to deactivate thread monitoring. Wish it was that simple.

We have investigated the provided data and tried to mimic some similar situation, but all our attempts have worked without any problems. So your program have some "complexity" which we have not been able to "catch".

I can see that you have some .NET interoperation and it may take part in the problem. It is however impossible for us to guess how.

You should also notice that a DLL will run initialization code on load, so event though you have not explicitly made any calls to your DLL, code from it has run.

Does the problem occur if you create a new visual prolog DLL, without any of your own code at all, just a standard "empty" DLL?

If so we can create DLL's corresponding to Vip 9 and Vip 10 that you could test with to see when the problem first occurred. That would help narrow down the cause of the problem.

[danPerraud]

Thank you for your reply,

I created an 'empty' DLL
The application no longer crashes!! (as long as the app does not attempt to use the functions of the dll), we go further!

I note differences in the code of the dll at the 'goal' level, the reason for my problem perhaps comes from that?

The empty dll:

Code: Select all

clauses
    new() :-
        mainDll::new(),
        destroyEvent:addListener(onDestroy).
 
end implement main
 
goal
    DLL = main::new(),
    DLL:init().

My dll:

Code: Select all

 #export caagl
 
implement caagl
    open core
clauses
run():-succeed.
 
%.....
%.....
 
end implement caagl
 
goal
  caagl::run().
 

[Thomas Linder Puls]

I think we have the problem there (at least we have one problem).

The new way that the main file looks is actually very important, because class facts and other such things are initialized in the call to mainDll::new.

With your goal/run code the initialization never takes place, and that it obviously a problem.

So try to add such a main class to your project and remove the old goal.

(I will then investigate which version it was that this changed, and write about it in the upgrade notes).

[Thomas Linder Puls]

Your DLL must have been made with an even older version of Visual Prolog, because even in Vip 7.4 a DLL project also contains code corresponding to the current one.

For various reasons I cannot say how Vip 7.3 behaved.

[danPerraud]

This code must even come from version 5 of visual Prolog
I added the main.pack and removed my old 'goal'.
And my app no longer crashes!!

I now have changes in behavior in the calculations, but I will be able to move forward.

Bravo and thank you very much for your help, and the time spent in research.

[Thomas Linder Puls]

Nice that we could solve the problem (that problem).