Access violation errors while running without the debugger

[christos papapostolou 0]

Hello, i am new to Delphi i come from a c++ background and i was assigned to migrate a legacy delphi app from delphi 7 borland to the latest embacardero version. The main issue that i am dealing with is that when i just run the program inside the IDE (with the debugger on obviously )   everything works fine, while when i run the app again from the IDE but without debugging when particular(not all!) forms .show i get access violation errors which i cannot locate cause i don't have the debugger. If someone with more experience than me can locate the issue i would be very happy to hear a solution for my problem  

[Cristian Peța 103]

You can use something like EurekaLog or madExcept to get a call stack.

Also you can use, while debugging, the address from the message in the CPU view in the context menu "Go to Addresses" and see if that is in your code. If not, then you need a call stack.

[FPiette 383]

I strongly recommend to use madExcept during development. It will catch - among other things - access to already freed object or memory which can cause what you see.

[Remy Lebeau 1396]

In addition to what others said - it is unusual to get an AccessViolation due to Execution of an address, usually it is due to a Read or Write instead.  If you are executing code at a bad memory address, that means you tried to call a function via a corrupted function pointer, or something like that, which will be much more difficult to find.   If it were just a read/write error, the error message would also give you the memory address of the code that tried to access the bad memory, so you could more easily jump right to that code.

[Kas Ob. 121]

14 hours ago, Remy Lebeau said:

or something like that

Yes , and to be more accurate explaining this case with both addresses are the same,

The EIP register pointing to a page-protected address, means the CPU is already try to fitch an instruction while the virtual mode triggered a page fault, hence the same address of the execution and accessing, this happens with few cases, like the stack is corrupted and a ret instruction caused the CPU to pick an invalid address to return to, or a hook or resolved API addresses pointing to a library, and that library has been already freed and its memory returned to the OS where marked again as protected or not allocated.

 

Not long ago there was similar bug discussed in the German forum comes from broken hooking that corrupt the stack after calling the hook, sorry can't find it now ! may be someone can help with that.

 

@christos papapostolou i would suggest to check and refine your uses clauses and find any exotic units or library that are outdated, also try to capture the stack list, it will help.

[PeterBelow 238]

On 7/19/2024 at 11:52 AM, christos papapostolou said:

Hello, i am new to Delphi i come from a c++ background and i was assigned to migrate a legacy delphi app from delphi 7 borland to the latest embacardero version. The main issue that i am dealing with is that when i just run the program inside the IDE (with the debugger on obviously )   everything works fine, while when i run the app again from the IDE but without debugging when particular(not all!) forms .show i get access violation errors which i cannot locate cause i don't have the debugger. If someone with more experience than me can locate the issue i would be very happy to hear a solution for my problem  

 

Moving from D7 to Delphi 12 (Athens) is a very big jump. If you can build the old codebase at least you don't have to worry about old 3rd-party components, but there have been a lot of changes on the way, the most important one perhaps the move from ANSI to Unicode (UTF16) characters. Sizeof(char) = sizeof(byte) = 1 is no longer true, and that hits hard if the old code misused string variables for storing binary data. Incrementing a pointer of type PChar will now increment it by 2, not by 1, and that can easily cause old code to overwrite memory, which may be at the root of your problem. It may work for debugging just due to a different stack layout caused by different options, e.g. for using stack frames. A stack overwrite can corrupt a return address and that may lead to the exception you see.

As recommended in other replies using a tool like MadExcept may be the best way to nail down the problem location, but if it is indeed a stack corruption the actual cause may be far from the location where it finally manifests. In this case doing an in-depth code review may be a better option, since there are likely more of these problematic code bits in your project.