Delphi XE2 : Off by 7-20 lines in debugger and compiler error line numbers also off by the same amount

I am having a problem with a large Delphi codebase where I work where as a side effect of porting from Delphi 2007 to XE2, we now encounter the following strange, related issues:

  • You can not set breakpoints or single step through code even in the debug build because the line numbering is all messed up, only in some of the units.

  • Introducing a syntax error deliberately at line 2010 will cause the cursor to focus at line 2020, give or take 3 or 4 lines, something like this:


 procedure Correct;
    DoSomething; // syntax error reported HERE but the real error is below.
    // more stuff here.

 procedure OllKorrect;  
        __VARIABLE_NOT_DEFINED__ := 1; // intentional error

I am hoping someone has seen this before. Elements of the issue may include:

The code contains many odd compiler directives like {$REALCOMPATIBILITY ON} and {$H-}/{$H+} directives, thousands of {$H+}/{$H-} directives in the code.

Secondly, the code uses a lot of {$I INCLUDE} directives, and I suspect that include files might directly mess up the line-numbering of the compiler.

I am unable to say for sure, but I suspect all these old "make it work like turbo pascal for DOS" compiler switches are the reason behind it. I'd like to know if anyone knows something about this for sure. It only happens in some places in the code, and with a project that has over 500 units, some of which reach 10K/20KLOC in size, it is definitely frustrating. What I can say is that it not only units that have {$I} directives that mess up, and that many units that contain a lot of {$H-}/{$H+} or {$REALCOMPATIBILITY} directives do not have this problem. If I could see what the units that misbehave have in common I could figure this out.

Update: The line termination issue makes sense. I ran this code which detected problems. The fix code is commented out because if you uncomment it and it erases all your source code, that's your problem. It is loading a non-unicode file into a unicode TStringList and saving it back out. That's okay in my world because its all version controlled and backed up. Your mileage may vary.

program linefeedsProject1;




  function fix(filename:String):Boolean;
    sl := TStringList.Create;
    //TODO:Change file extensions.

  function scan(filename:String):Boolean;
   buf:Array[0..1024] of AnsiChar;
   procedure scanChars;
     for i := 0 to n-1 do
       if buf[i]=#13 then
          crFlag := true;
          lfFlag := false;
       else if buf[i]=#10 then
           if not crFlag then
          lfFlag := true;
          crFlag := false;
       else begin
         if (crFlag) then
         crFlag := false;
         lfFlag := false;
   result := false;
   crFlag := false;
   lfFlag := false;
   missingCr := 0;
   missingLf := 0;
    f := TFileStream.Create(filename, fmOpenRead);
      while f.Position< f.Size do
        n := f.Read(buf[0],1024);

     if (missingCr>0) or (missingLf>0) then
          WriteLn('  ', filename);
          result := true;

  broken := 0;
  notBroken := 0;
    files := TDirectory.GetFiles('C:\dev\abackupcopyofyoursourcecode',  '*.pas',
    TSearchOption.soTopDirectoryOnly );
    // tried TSearchOption.soAllDirectories and it exploded. not recommended.

    for afile in files do
       if scan(afile) then
           // fix(afile); // uncomment at your own risk and only on a backup copy of your code.


    WriteLn('Broken ', broken);
    WriteLn('not broken ',notBroken);

   // readln;

    on E: Exception do
      Writeln(E.ClassName, ': ', E.Message);

Update 2: If you want a scanner/fixer for this issue you can download mine (with source) here. Link is Google Drive. You can view the source code from the link, but click the "File" pull down menu (part of the google drive web user interface) and then click "Download" to download it.

I've seen things like this before, and IME it's generally due to an compiler bug in counting line numbers. If you have nonstandard line breaks (not CRLF) at some points--which can happen--the IDE will do proper line breaks but the compiler doesn't count them as new lines, so everything afterwards gets thrown off by one.

What I do when I encounter a file like this is open it in EditPad, convert all linebreaks to some other style (Unix or Mac style) and then convert all linebreaks to Windows style and save it. This ensures that every line in the file ends with CRLF, and after a rebuild the issue with the blue dots not lining up right goes away.

‍❤️‍ ‍ Delphi XE2: shutdown of 7-20 lines in line numbers of the , Delphi XE2: shutdown of 7-20 lines in line numbers of the debugger and compiler code is also disabled for the same amount I have a problem with the This problem happens since I installed Delphi XE2 Update 2, it did not happen on Delphi XE2 RTM (i never have installed Delphi XE2 Update 1). My PC has 12 GByte Memory available. At the point of the crash it uses ~8GByte of Memory. QC Entry 100726: 1. Load and run attached sample project 2.

This is a common problem caused by mismatched line termination characters. (Code with a missing CR or LF on the end of the line.) It can also be caused by having a .dcu that doesn't match the source file that's open in the editor.

For the first, the easiest fix is to open the source file in a regular text editor (such as Notepad). Make a small change (insert a blank line and then delete it), and save the file. Notepad will fix the line endings.

If this isn't the issue, look for extra copies of the .dcu (or .pas) file that might be on your drive in the IDE's search path. Sometimes the compiler sees a different version than what's open in the editor.

Delphi XE2 and C++Builder XE2 Update 4 Bug Fix List, XE2 Compiler is raise error and hong, when I put a character after variable declaration in With XE the same packages install and the components are registered without a problem. It has one line only, and the text disappears off the side. Notice also how, for Win64, the presence of debug info affects the number of  Abstract: List of user reported issues that are fixed in Update 2 for Delphi XE2, C++Builder XE2 and RAD Studio XE2 The following is a list of user reported issues that have been fixed in Update 2 to Delphi XE2, C++Builder XE2 and RAD Studio XE2.

It definitely is connected to line endings as explained in previous posts. It is extremely hard to try to edit it away, since the Embarcadero editor tries to do magic of its own and preserves the line endings of the current section (or so it seems),

Solution: Right click in the IDE editor window, select "Format Source" (Ctrl-D) and accept.

This will fix all line endings and removes the problem (for me any way). As a by-product you will get correctly formatted source code :-)

Delphi XE2 and C++Builder XE2 Update 2 Bug Fix List, Abstract: List of user reported issues that are fixed in Update 2 for Delphi XE2, When open a existing delphi project, and want to compile and debug in 64-Bit, IDE open NET ErrorInsight parser and error underlining is disabled for the whole file. dcc64 reports a typical compile time for dcc64 of 14.54 secs for same test  Full text of "Delphi XE 2 Foundations Part 1 ( 2012, Chris Rolliston)" See other formats

Verilog Copy/Paste Formatting - formatting - android, I know this is an old question but I have been doing the same thing myself and the Also the TPSCustomDebugExec.TranslatePositionEx() does the opposite to what is wanted, it gives a source line number from a runtime code position. Delphi XE2 : Off by 7-20 lines in debugger and compiler error line numbers also off  Support for Delphi XE2 and its 64bit compiler. Changes and new features of MtxVec v4 (March 2011): Core product: Rewritten FFT descriptor cache now optimized for heavy multithreading. This also fixed two bugs related to the multithreaded use of FFTs. Fixed a number of issues related to defining custom functions with the function evaluator.

Cannot make sense out a Delphi windows file name, Cannot make sense out a Delphi windows file name - delphi. you like (e.g. malformed field value/name, line number, and/or entire line etc.) There's also a project group (TextDataGroup.groupproj) - you can simply Delphi XE2 : Off by 7​-20 lines in debugger and compiler error line numbers also off by the same amount. In project options, under Delphi Compiler | Linking set Debug Information to True and Include Remote Debug Symbols to true. Hit OK. Build project and save. Copy the .rsm and the .exe file to a directory called c:\temp\remote Open up a cmd window. Navigate to the Rad Studio\7.0\bin directory Launch the remote debugger using the following command:

[PDF] Free Pascal User's Guide.pdf, Delphi 7 (although this goal is not yet attained), but it also enhances these languages with elements (replace NNN with the version number of Free Pascal that you are using). If you got no error messages, the compiler has generated an executable file which can contain the same options as on the command line​. An Object Pascal extension was also implemented in the Think Pascal IDE. The IDE includes the compiler and an editor with syntax highlighting and checking, a powerful debugger and a class library. Many developers preferred Think Pascal over Apple’s implementation of Object Pascal because Think Pascal offered a tight integration of its tools.

  • +1 , I have experienced the same behavior using the {$I INCLUDE} directive.
  • If you've added (or removed) lines of code and hit F9, it's possible the DCUs being used in the binary (and therefore the tokens for the debugger) haven't been rebuilt (I've had that issue many times). In such cases, I just do a "Clean" then "Build" and the problem goes away. Tried that?
  • PS - I encounter exactly the same issues when debugging errors in SQL Server script (very large, like 20k lines in one file)
  • (That is, SQL Server Management Studio 2008 R2 specifically)
  • Lakraven; Clean and rebuild has no effect. The line termination answers seem rational and probable.
  • This happens in Visual Studio too. There I use CodeRush which warns me for any file that has mixed line endings and has an option to convert them to one style.
  • I wrote a little utility to help out and appended it to the answer above. If it's useful to people I will write something less rushed and make it open source.
  • Confirmed. After running the code I posted above to my answer, I am no longer able to reproduce these problems. Good call. Thanks both of you guys who took time to answer.
  • I wrote a utility, see the link in the updated question if anyone needs to scan their code. (It will fix it too, if you pass in the correct parameters, but by default to be careful it only reads things and doesn't write things.)
  • Is there a tool to fix the line termination automatically on a large codebase? If this is the issue, I'd rather deal with it thoroughly. I might write such a tool if I can't find one out there.
  • It's sad that we have to resort to third-party tools to resolve dumb little IDE and compiler bugs. These are all things that theoretically should be dealt with directly.
  • @Jerry: This is not only a Delphi IDE issue. Visual Studio has problems with this also (mostly because of people opening *nix files in it), and offers a "Normalize line endings" option in the editor context menu to fix it. (See the question where I posted this answer for instance.) It also frequently happens when code is copy/pasted from web pages from some browsers into the IDE code editor.
  • Speaking of which:…
  • Now you can use my handy dandy recursive descending Fixer Upper.