:
This message was edited by Ripper at 2006-4-21 1:51:15
: : : : :
This message was edited by Ripper at 2006-4-20 3:54:21
: : : : : hi guys,
: : : : :
: : : : : hope someone can maybe help me.
: : : : :
: : : : : i am getting access violations in my software. I now there is a map file that can be built when compiling the exe.
: : : : :
: : : : : if i don't find the correct memory address in the map file, what then ?
: : : : :
: : : : : or is there a specific way to read the memory addresses ?
: : : : :
: : : : : regards
: : : : : ripper
: : : : :
: : : : : i read after posting this message, you actually need the stact address, that way you can pin point the issue.
: : : : :
: : : : : i read about JEDI VCL for Delphi, which can catch the stact address. it is 3rd party software. do anyone know it ?
: : : : :
: : : : :
: : : : :
: : : : I would recommend using the build in debugger. That also allows you to watch the variables change as the program runs. Just place a break point at the procedure/event, which runs correctly, but before the error occurs. For example: if the error occurs in response to a button click, place the breakpoint at the first statement in the OnClick() event.
: : : :
: : : thanks for the reply. I was actually talking about when the exe runs, and to find the spot in the code where it actually happend, the access violation. (not in debug mode).
: : :
: : You can use Search>Find Error to jump to the statement with that address, although I myself almost never use that. It might be that the statement raising the exception is somewhere in one of the Borland units. Then you need to have the sources of those units installed.
: :
:
: ok, i got it, and traced the error, and the cpu window comes up. is there any way to link that to the actual code by just double clicking somewhere ?
:
:
:
:
As fas as I know, not. The CPU window and the access violation is often the indication that it is either inside the memory manager or within the code of a kernel library. If you don't want to use the debugger, then you should consider logging the calls to the procedures by adding a code to write to a log file to each procedure. This will give you a way of locating in which procedure the error is. Here is the logging code I usually use:
{$IFDEF DEBUG}
procedure LogCall(msg: string; const args: array of const);
begin
LogCall(Format(msg, args));
end;
procedure LogCall(msg: string);
var
f: textfile;
begin
AssignFile(f, 'errors.log');
Append(f);
writeln(msg);
CloseFile(f);
end;
{$ENDIF}
Make sure the errors.log file exists prior to running your code.
