0

I just implemented a CI/CD environment with Delphi 10.4+gitlab+build machine Everything worked apparently correct, with the build process running smoothly, but when using the program, it randomly show errors that never occurs compared if I build manually via "shift+F9" (build) inside Delphi itself. The build process:

call "C:\\Program Files (x86)\\Embarcadero\\Studio\\21.0\\bin\\rsvars.bat"
msbuild /target:rebuild /property:config=Debug;DCC_BuildAllUnits=true  /p:platform=Win32 project.dproj

Also, I tried other msbuild variations like:

msbuild /target:rebuild /property:config=Debug  /p:platform=Win32 project.dproj

(and also with 2 steps (target:clean and target:build)

I also compared msbuild dcc32.exe command with "Delphi" dcc32.exe command, and they are basically equal but for an additional (inexistent) folder for msbuild output:

-I"c:\program files (x86)\embarcadero\studio\21.0\lib\Win32\release\EN";...

The weirdest thing is: after doing a msbuild build, if I open my project with Delphi, do a clean+compile the program became weirder, giving other errors, but if I do full build (shift+F9) then it runs smoothly again To me, it looks like some of the components used aren't properly compiled under msbuild or are used with other parameters, but I have no idea of what could it be or how to find it.

Error I got after building with cmd msbuild + clean at Delphi + compile at Delphi:

First chance exception at $0019FB95. Exception class $C0000096 with message 'privileged instruction at 0x0019fb95'. Process project.exe (11324)

Followed by:

First chance exception at $0040AE84. Exception class $C0000005 with message 'access violation at 0x0040ae84: read of address 0x0000000b'. Process project.exe (11324)

Looking at the error, it is raised in this code:

procedure TAdvancedField.asImageLoadToBitMap(var outBitmap:TBitmap); var FS        : TMemoryStream;
    FirstBytes: AnsiString;
    Graphic   : TGraphic; 
begin   try
    FS := TMemoryStream.Create;
    (Self as TBlobField).SaveToStream(FS);
    fs.Position := 0;
    SetLength(FirstBytes, 8);
    FS.Read(FirstBytes[1], 8);
    //Graphic := nil;  //I add this line after my debug, and commented to confirm
    
    //if Copy(FirstBytes, 1, 2) = 'BM' then
    //begin
    //  Graphic := TBitmap.Create;
    //end else
    //if FirstBytes = #137'PNG'#13#10#26#10 then
    //begin
    //  Graphic := TPngImage.Create;
    //end else
    //if Copy(FirstBytes, 1, 3) =  'GIF' then
    //begin
    //  Graphic := TGIFImage.Create;
    //end else
    //if Copy(FirstBytes, 1, 2) = #$FF#$D8 then
    //begin
    //  Graphic := TJPEGImage.Create;
    //  TJPEGImage(Graphic).CompressionQuality := 100;
    //end;
    
    if Assigned(Graphic) then
    begin
      try
        FS.Seek(0, soFromBeginning);
        Graphic.LoadFromStream(FS); //The error raised HERE
        outBitmap.Assign(Graphic);
      except
      end;
      Graphic.Free;
    end
    else
    begin
      outBitmap.Assign(nil);
    end;
finally
    fs.Free;   
end; 
end;

As you can see, the Graphic variable isn't initialized anywhere. But with a clean Delphi build it runs perfectly with Assigned(Graphic) always returning false, but after msbuild it returns as true. If this is correct to other similar cases it'll lead to unexpected behavior all across the project.

Another situation: I put a button at my main form with a single raise exception, + application exception handler + JCVStackTrace handler, and this is the captured stack:

[017B7DE5] pcnConversao.RegTribISSQNToStr (Line 1301, "pcnConversao.pas" + 1) + $104
[006B6973] Vcl.Controls.TWinControl.ArrangeControl + $147
[006BB36F] Vcl.Controls.TWinControl.DoKeyUp + $73
[005A4998] Vcl.StdCtrls.TCustomCheckBox.SetChecked + $0
[006BB4CF] Vcl.Controls.TraverseControls + $37
[006BB36F] Vcl.Controls.TWinControl.DoKeyUp + $73
[0067E227] Vcl.Forms.TCustomForm.CreateWnd + $97
[006BA8BC] Vcl.Controls.TWinControl.WMInputLangChange + $8
[004F4A18] System.Classes.TStreamWriter.WriteLine + $C
[006BB47A] Vcl.Controls.TWinControl.WMChar + $2
[006BB36F] Vcl.Controls.TWinControl.DoKeyUp + $73
[005A4998] Vcl.StdCtrls.TCustomCheckBox.SetChecked + $0
[004F4A18] System.Classes.TStreamWriter.WriteLine + $C

By the way, pcnConversao is only used indirectly by my project

The correct would be:

[01709661] UModulo.TModulo.BitBtn3Click (Line 568, "UModulo.pas" + 0) + $11
[006BB3E7] Vcl.Controls.TWinControl.WndProc + $693
[005A4A10] Vcl.StdCtrls.TButtonControl.WndProc + $6C
[006BB547] Vcl.Controls.DoControlMsg + $23
[006BB3E7] Vcl.Controls.TWinControl.WndProc + $693
[0067E29F] Vcl.Forms.TCustomForm.WndProc + $6DB
[006BA934] Vcl.Controls.TWinControl.MainWndProc + $2C
[004F4A90] System.Classes.StdWndProc + $14
[006BB4F2] Vcl.Controls.TWinControl.DefaultHandler + $E6
[006BB3E7] Vcl.Controls.TWinControl.WndProc + $693
[005A4A10] Vcl.StdCtrls.TButtonControl.WndProc + $6C
[004F4A90] System.Classes.StdWndProc + $14

Note: Looks like the different stack is directly related with Stack Frames checked at Delphi Compiler->Compiling->Code Generation, still no related with the diverging way of the compiler at not initialized variable

  • What errors shows your program? – Delphi Coder May 07 '21 at 05:23
  • edited question with 2 errors, I'll paste others tomorrow if needed – Lucas Schatz May 07 '21 at 12:01
  • 1
    I can't see any error messages. Details matter here. – David Heffernan May 07 '21 at 18:24
  • Looks like it's something related with the .dproj Created a new .dproj and duplicated my configs, until now I found this parameters in to dcc32.exe in the new dproj that isn't defined in my current one: `-K00400000 -GD` I'm doing some more testing, and so far I got no error in both builds, as soon I got the error I'll post here – Lucas Schatz May 08 '21 at 17:36
  • Ok, but still, not initializing local variables will lead to undesired behavior. When and where this behavior will occur is never te say, but at you’ve noticed is can be when use different build methods/configurations. Therefor the need the ALWAYS initialize local variables! – R. Hoek May 09 '21 at 13:42
  • @R.Hoek yes you are right, it's my mistake but just half of the problem I still don't know why I'm getting the difference in the stack trace, I think this could be the real pain to my problem – Lucas Schatz May 10 '21 at 12:42

1 Answers1

0

The problem was exactly that uninitialized variable. Still don't know why the behavior was different from the default build trough the IDE, but initializing as nil solved the problem