Jump to content
omnibrain

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

Recommended Posts

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.

Share this post


Link to post

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 by David Heffernan
  • Thanks 1

Share this post


Link to post

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.

Share this post


Link to post

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

Share this post


Link to post
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.

  • Like 1

Share this post


Link to post

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.

Share this post


Link to post
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.

Share this post


Link to post
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...

Share this post


Link to post

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

  // 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( UnicodeAnsiString( 'back-door', code-page) ) ) = if same codeS then ass = 'back-door', else = '?'

Edited by programmerdelphi2k

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×