Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Posts posted by aehimself

  1. Be careful, the above code is NOT thread safe. If you have multiple threads using the same logger you'll end up crashing said thread due to unhandled exception in the exception handler or simply corrupting your log file.

    It's good for single threaded applications, though.


    Edit: Having a second look I'd vote against this method in general. If you know you will dump everything in a file no matter what it's better to write to that file and read it back all up if you want to display it in the UI. This way you are simply wasting resources, especially if your log file grows large.

    Also, appending to a memo has it's performance penalty which is extremely painful if items are arriving rapidly.

    • Like 1

  2. Got the same result as @Kas Ob. when building a JSON object and using my custom hasher:

    procedure TForm1.FormCreate(Sender: TObject);
     s256: TAESHA256Hasher;
     tb: TBytes;
     json: TJSONObject;
     s256 := TAESHA256Hasher.Create;
      json := TJSONObject(TJSONObject.ParseJSONValue(Memo1.Text));
      SetLength(tb, json.EstimatedByteSize);
      SetLength(tb, json.ToBytes(tb, 0));
      tb := s256.HashOf(tb);

    Ps: I know I'm leaking json.



    [Window Title]




    So either the example is wrong or they are not parsing the document as we think (I also tried removing the opening and closing braces so only the body is processed - no luck).

  3. I just want to make sure my logic is correct here. I built a really simple test, see .dpr and the generated .map file attached. I used this method to extract method addresses.


    Stack trace was as following:



    Now, from each address I substracted image base ($400000) and $1000, which resulted the following relative addresses:




    In the map file "Address - Publics by name" section I looked for the address which is the closest but below each relative address. This gives me the method names.

    In the map file "Line numbers for xxx" section I searched for the exact relative address. This gives me the line numbers, if any.


    Based on the above approach my reconstructed stack trace is the following:


    StackTrace.GetExceptionStackInfo ( StackTrace:44 )
    System.SysUtils.Exception.RaisingException ( ??? )
    System.SysUtils.ExceptHandler ( System.SysUtils:23574 )
    ??? ( System.pas:22018 )
    ??? ( System.pas:22108 )
    Project1.Three ( Project1:14 )
    Project1.Two ( Project1:19 )
    Project1.One ( Project1:24 )
    Project1.Project1 ( ??? )


    It resembles what went on, but I have some missing information which I was unable to find.

    I have two questions... is this the way to reconstruct the call stack from a map file? And if yes, how I can find the missing information?


  4. Quote


    Unofficial, programmers love Pascal/Delphi/Free Pascal/Lazarus-IDE, but Official, they never confess that use that technologies and they shame of that.

    Pascal/Delphi programmer never put that information in CV that he love or use Pascal/Delphi.

    Delphi/Pascal programmers shame of Delphi/Pascal, and put in CV that use Microsoft C#, Python, PHP or something cool and very popular today.




    Btw I never experienced random crashes of my applications, not one since Windows 2000. I mean of course I did, but all of them was the fault of my code, not the OS silently attempting to kill it. And I would be REALLY surprised if it was true (especially now since Embarcadero / Idera has MS links if I'm not mistaken).

    • Like 1

  5. We do have this combination at work. SCM is Git, client is written in Delphi, server is written in C#. Recently changed the process to use MSBuild to compile the Delphi project too.

    Works like a charm.

  6. 1 hour ago, Wagner Landgraf said:

    Thank you very much for the feedback. Since you mentioned you just "gave it a try", you are not using it anymore, and/or didn't use it in production?

    I'm also interested in knowing how it is (and the other mentioned tools) when it comes to performance and stability, since I intend to use it in server applications.

    I had ~2 releases with DebugEngine, then I switched back to MadExcept. It's stack traces are less messed up when packed with UPX. I'd personally prefer DebugEngine as it is not installing hooks (thus - not having the issues I mentioned) getting stack traces is it's main purpose.


    Performance wise - you won't feel a difference tbh. None of these tools will make your application less stable or significantly slower.

    • Thanks 1

  7. I gave DebugEngine a try and it is very good. Sometimes it provides stack traces strange (method where exception happened, two inner methods of DebugEngine and then the real stack trace) but it's really easy to install and use. It is also unaffected by the two issues I have with MadExcept (TThread.FatalException and Exception.InnerException is rendered useless).


    It comes with a utility to attach the map (or it's own compressed smap) format to the .EXE itself, however the final executable is larger than with MadExcept (guess the .map compression is not that advanced in DebugEngine than in MadExcept).


    I don't have much experience with JclDebug... I tried it once, and I disliked every bit of it. Only to be able to see stack traces I had to include ~30 extra files in my project and the stack traces were not accurate.; so I gave up on it.

    If you can fit into the free usage conditions of MadExcept I'd say go with that. Otherwise, DebugEngine (or a license for MadExcept) would be my choice.


    P.s.: keep in mind that also MadExcept and DebugEngine is known to have stack issues if the .exe is packed with UPX.

    • Like 1
    • Thanks 1

  8. This question is way too broad to be able to be answered correctly. In general, have Try..Except blocks.

    What you do inside the exception handler completely depends on the kind of application you are writing.


    If you don't want your application to crash / misbehave after an exception happened you have to make sure you "reset it to a default state". Roll back transactions, close datasets, free up objects, closing TCP connections, etc. You might want to make a note of it too for debugging purposes so write details to a log file and let your user know that something went south.

    It's also good to have stack traces so look into MadExcept / DebugEngine - both are really easy to install and can be used for free - with restrictions of course.

    • Like 2

  9. Thank you for the explanation, it all makes sense now. I don't really need workarounds; if this area will be touched it will be properly changed instead to use a hack-of-a-hack...


    Don't get me wrong - I know this should not be done because it won't work; this is why I was this surprised that it does in our case. The sole purpose of this topic was for me to understand why it does, when it should not 🙂

  10. Update: wrong. #0s are not present.


     ss: TStringStream;
     s: TStream;
     tb: TBytes;
     ss := TStringStream.Create('Árvíztűrő tükörfúrógép');
      s := ss;
      SetLength(tb, s.Size);
      s.Read(tb, Length(tb));

    Lossy conversion as you mentioned, though.

  11. 36 minutes ago, Remy Lebeau said:

    Most likely, that code predated the shift to Unicode in Delphi 2009.

    Not most likely, it does. Was Delphi 6 or 7, way before I joined the company.

    36 minutes ago, Remy Lebeau said:

    This is exactly why you SHOULD NOT put binary data into a UnicodeString.

    I know, this is why I was really surprised that it actually works like this. We are just lucky with our locale it seems 🙂

    36 minutes ago, Remy Lebeau said:

    Doesn't work.  It fills only 1/2 of the UnicodeString's memory with the non-textual binary (because SizeOf(WideChar) is 2, so the SetLength() is allocating twice the number of bytes as were read in), then converts the entire UnicodeString (including the unused bytes) from UTF-16 to ANSI producing complete garbage, and then writes that garbage as-is to file.  So yes, the same number of bytes MAY be written as were read in (but that is not guaranteed), but those bytes are useless.

    First one was only a demonstration; I knew it won't work. I found it strange that the output byte count is the same as the input (because of the double size as you pointed out) though. Guess I was lucky with the random choice of exe.

    36 minutes ago, Remy Lebeau said:

    That code is copying the binary as-is into an AnsiString of equal byte size, converting that AnsiString to a UTF-16 UnicodeString using the user's default locale, then converting that UnicodeString from UTF-16 back to ANSI using the same locale.  Depending on the particular locale used, that MAY be a lossy conversion, you MIGHT end up with the same bytes that you started with, or you MIGHT NOT.

    So if I get it right... we read the binary data, doubling it's size as we pad each character with a #0 during AnsiString -> String conversion?

    The real code is creating a TStringStream out of this and passing it as a parameter of a method, which is expecting a stream. That method will access the contents with .Seek and .Read I suppose.

    I didn't test this, but am I safe to assume that this would include the extra #0s, causing the binary data to be corrupted?

  12. While digging in the depths of a legacy application I was shocked to see that a binary data received through the network is stored and handled as a String.

    And it works.


    Imagine the following code:

    procedure TForm1.Button1Click(Sender: TObject);
     tb: TBytes;
     s: String;
     tb := TFile.ReadAllBytes('C:\temp\Project1.exe');
     SetLength(s, Length(tb));
     Move(tb[0], s[1], Length(tb));
    // If CompareMem(@tb[0], @s[1], Length(tb)) Then ShowMessage('Contents are the same');
     TFile.WriteAllText('C:\temp\project2.exe', s, TEncoding.Default);

    Fails. Produces the same amount of bytes, but it doesn't work.


    However, just by introducing a string casting:

    procedure TForm1.Button1Click(Sender: TObject);
     tb: TBytes;
     s: String;
     ans: AnsiString;
     tb := TFile.ReadAllBytes('C:\temp\Project1.exe');
     SetLength(ans, Length(tb));
     Move(tb[0], ans[1], Length(tb));
     s := String(ans);
     TFile.WriteAllText('C:\temp\Project2.exe', s, TEncoding.Default);

    output executable is... well, executable.


    My bet is on some pointer magic Delphi is doing in the background, but can someone please explain WHY this works?!