Possible changes to string/char handling in Delphi 11(.2)?

[programmerdelphi2k 237]

ok

[omnibrain 15]

3 hours ago, David Heffernan said:

What do you expect and intend to happen then with values of >= $80?

 

I don't think anything has changed in recent Delphi releases, but your code may have been broken forever. 

They should keep their "value". It could for example be the "length field" and $A9 for the 3rd byte/char received would mean that we have to work with the next 169 characters, the 171st char/byte received would then be a checksum over all bytes/chars received, which could be $F3 for example.

It could very well be that it has been broken forever, but we processed millions of "messages" per month and never had this problem. But like I said, I can't totally rule out, that we just never received such a message before. It could be just a single character causing this trouble by getting converted and only in few positions it would cause (visible) trouble.

Today we traced all the "messages" at a customer, but of course it did not happen. Tomorrow I'm going to add additional logging code, so we pinpoint closer where the exception happens and then we should know what the "wrong data" is.

[David Heffernan 2345]

We still have no real clue what your code is doing. The excerpt you posted doesn't much help. Storing byte arrays in an ansistring is for sure broken. Always has been since unicode Delphi. But it's not clear you are doing that.

 

You should stop hoping that it's a Delphi bug and look at your code. Almost certainly that's where the problem is. 

Edited November 29, 2022 by David Heffernan

[aehimself 396]

If you can detect a malformed packet, you simply can log the input and the output. Once the issue is detected, dump these in a local file so the customer can send it to you.

Then, it's a matter of running the same byte sequence against your "processor" to see what / why it happens.

 

You also can do the same if you can't detect the failure, but in this case dumping has to be initiated by a user input.

 

In unexplainable situations I find it helpful to divide my classes up even further. Have a class ONLY for the COM handling, outputting TBytes. Have one converting these to AnsiSting-based "packets". Have an other one to process these. Usually during coding these tiny classes I'm fixing the issue I had in the beginning.

[omnibrain 15]

Good news everybody, we got a trace and it looks like we can provoke this issue with our test hardware.

[programmerdelphi2k 237]

@omnibrain what was the problem, in fact? 

[omnibrain 15]

3 hours ago, programmerdelphi2k said:

@omnibrain what was the problem, in fact? 

As suspected unsave byte/char handling. We converted the offending parts to TByte now. But it was also a problem because the code expected a byte converting to an integer value, but the message could have had legit anything else at this point.
The trigger was an unusual message. Once we had a trace we could recreate it with our test hardware and it was obvious. The exception was many calls deep into the processing code and got only caught on the top of the call stack so we would have probably taken a few more days to really find this part.
Perhaps we should add something like MadExcept. It's a shame that Delphi offers no inbuilt StackTrace at runtime.

[aehimself 396]

Glad you found the culprit, detecting rare conditions can be a pain in the back!

 

Stack traces is a must tbh. MadExcept can be used for free, but with limitations; make sure you read the EULA. DebugEngine is a standalone (and completely free) alternative to MadExcept, also @Fr0sT.Brutal maintains a much more lightweight solution called IceDebug if I'm not mistaken.

[Sherlock 663]

8 minutes ago, omnibrain said:

Perhaps we should add something like MadExcept. It's a shame that Delphi offers no inbuilt StackTrace at runtime.

That is a good thing. Anything built into Delphi slowly decays due to lack of maintenance. Until one day it produces only errors and management has to decide wether to trash it or build something around it to try and fix it. Most prominent recent example: ErrorInsight fixed through LSP. Or the Parnassus tools...taking longer and longer to appear in GetIt with each new Delphi version.

[omnibrain 15]

6 minutes ago, Sherlock said:

That is a good thing. Anything built into Delphi slowly decays due to lack of maintenance.

Sure, but coming from Java and .Net it's just a basic language feature missing. Maybe it's easier to implement if everything runs in a VM...

[programmerdelphi2k 237]

about translitation: AnsiString = char(1120) ... HELP  (my fault dont read all content... 

  // When a literal is assigned to an AnsiString, the compiler will convert that literal to Unicode using the code page of the
  // AnsiString and then convert that back to literal. This ensures that the AnsiString contains characters valid for its codepage.
  // If an invalid character is specified, it will be converted to byte "$3F" (question mark) to signal that an invalid byte sequence(s)
  // was encountered.
 

var

  ass: AnsiString;

begin

    ass := 'back-door';  <=> ass := AnsiString( Unicode(  AnsiString( 'back-door', code-page) ) ) = if same codeS then ass = 'back-door', else = '?'

Edited December 1, 2022 by programmerdelphi2k

[aehimself 396]

16 minutes ago, programmerdelphi2k said:

    ass := 'back-door';

[programmerdelphi2k 237]

no bad-WORds here 

 

ass = AnsiStringS  

Edited December 1, 2022 by programmerdelphi2k