DLL access error

[direktor05 2]

Hello,

 

Im calling a DLL written in Delphi, when exiting form I get Access Error. How to deal with debugging of this kind of errors when you don't know exactly what is wrong but only get memory location access error? I think there is a problem with memory management, loading and unloading, creating and destroying components. But where....? Are there any tools to better analyze this? I'm using Delphi 11.3

 

Help is very welcome.

[David Heffernan 2345]

You can debug the dll, assuming you have the source code

[direktor05 2]

3 hours ago, David Heffernan said:

You can debug the dll, assuming you have the source code

Yes I have, same thing - access error is still there. not knowing where it came from no matter what you debug.

[Lajos Juhász 293]

During the debug you must get a call stack.

[direktor05 2]

3 hours ago, Lajos Juhász said:

During the debug you must get a call stack.

right with not much info. the is the CPU window with a lot of assembler code to dig through

[direktor05 2]

how about this: http://www.pe-explorer.com/

[David Heffernan 2345]

You are debugging the host. You need to debug the DLL.

 

c++ - How to debug a DLL file in Delphi - Stack Overflow

[PeterBelow 238]

22 hours ago, direktor05 said:

Hello,

 

Im calling a DLL written in Delphi, when exiting form I get Access Error. How to deal with debugging of this kind of errors when you don't know exactly what is wrong but only get memory location access error? I think there is a problem with memory management, loading and unloading, creating and destroying components. But where....? Are there any tools to better analyze this? I'm using Delphi 11.3

 

Help is very welcome.

Are you calling the DLL from a Delphi app or some other environment?

Anyway, even if you use a DLL from a host app made with the same Delphi version it is not safe to pass data types to the DLL for which the compiler does automatic memory management (string, dynamic arrays, objects that internally use such data types, e.g. TStringlist). At minimum you have to use the SimpleShareMem or ShareMem unit on both sides to get both modules to use the same memory manager. This may not be enough if the DLL implements forms or datamodules, since these use global VCL variables like Application and Screen, of which each module has its own instance. The only way to make both modules share the same VCL instance is to build both with the core RTL and VCL run-time packages.

[direktor05 2]

On 4/30/2024 at 4:55 PM, David Heffernan said:

You are debugging the host. You need to debug the DLL.

 

c++ - How to debug a DLL file in Delphi - Stack Overflow

Heff you are a genious!

[direktor05 2]

On 4/30/2024 at 8:53 PM, PeterBelow said:

Are you calling the DLL from a Delphi app or some other environment?

Anyway, even if you use a DLL from a host app made with the same Delphi version it is not safe to pass data types to the DLL for which the compiler does automatic memory management (string, dynamic arrays, objects that internally use such data types, e.g. TStringlist). At minimum you have to use the SimpleShareMem or ShareMem unit on both sides to get both modules to use the same memory manager. This may not be enough if the DLL implements forms or datamodules, since these use global VCL variables like Application and Screen, of which each module has its own instance. The only way to make both modules share the same VCL instance is to build both with the core RTL and VCL run-time packages.

and you too!