58
votes

I'm remote debugging a large app between DElphi XE2 (update #4) and a Windows XP target. PAServer is running on the target and the application works fine and stops at breakpoints (you would NOT believe how hard just that achievement was - hint - delete your DPROJ and start again if it has been through any IDE prior to XE).

I notice that the display of local variables and watches show my strings in a strange format compared to the usual display of the 'some string' format that one sees when debugging locally. I see:

enter image description here

Can anyone tell me why the strings are displayed this way? I also get quite a bit of { NULL } and garbage between {}'s on output variables that are not yet assigned. Thanks.

. I see that this format indicates wide strings. I tried a simple app on Windows 7 and got the following result. My App at a breakpoint:

enter image description here

The displayed local string variables:

enter image description here

Note the truncated 'Hello'. It would seem that XE2 has a problem with remote unicode strings at times. My PaServer is version 1.0.2. Can anyone check that this is the latest? 'Twas taken from Update #4...

4
I'm guessing you're running into something you'll want to log on Quality Central, and I doubt any mere end-user can fix this for you. Upvoted for being brave enough to try this.Warren P
What does your remote profile look like? Did you have any issues installing the PA on the remote server? Is the remote server fully patched and up to date? What happens when you expand S2 in the local variables view?Daisetsu
@Daisetsu: Remote profile is very basic to another IP system. No other installer issues. I will try expanding the variable to a memory dump and see what happens.Brian Frost
I can confirm the presence of this bug in PAServer. It seems that it gets confused with Unicode strings. If you change the strings to ANSI, it works, but that is not a solution.JJD2K

4 Answers

4
votes

I'm not entirely sure why you have the {} around the string values, - my hunch is that it is to demonstrate that the values are coming from a remote execution - but I know for a fact that S is being truncated due to optimization...

{$O-} // Disable Optimization
var
  S: AnsiString;
  S2: UnicodeString;
begin
  S := 'Hello';
  S2 := 'Hello2';
  ShowMessage(S2);
end;
{$O+} // Enable Optimization

You'll now note that the value 'Hello' (of variable S) remains intact when debugging. Likewise if you make use of the value assigned to S:

var
  S: AnsiString;
  S2: UnicodeString;
begin
  S := 'Hello';
  S2 := 'Hello2';
  ShowMessage(S + S2);
end;

Delphi's optimization now identifies that S is being used within its valid scope, and so the value is preserved.

So, what you're calling a "bug" is in fact a "compiler feature" exactly as Borland/Inprise/Codegear/Embarcadero intended.

3
votes

(I am copying code from @Dave)

var
  S1: AnsiString;
  S2: UnicodeString;
begin
  S1 := 'Foo';
  S2 := 'Bar';
  ShowMessage(Format('%s!', S2));
end;

I am guessing local var S1 here is optimized because it is not used anywhere, so the value is not relvant anymore.

Try run this on a local machine, can you see S1?

1
votes

I am not sure if it pertains, but I am aware of System.AnsiStrings containing specialized commands such as "Format", etc... Using something like the following may resolve your issue:

var
  S1: AnsiString;
  S2: UnicodeString;
begin
  S1 := 'Foo';
  S2 := 'Bar';
  ShowMessage(Format('%s!', S2));
end;

Also there are a few open bugs, just to rule out any of those, what specific versions of the os and tools are you using i.e. Win7 x64 Ultimate etc.?

0
votes

Project -> Options -> Delphi Compiler -> Linking -> Include remote debug symbols = true