Jump to content

Search the Community

Showing results for tags 'bug'.

More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • Delphi Questions and Answers
    • Algorithms, Data Structures and Class Design
    • VCL
    • FMX
    • RTL and Delphi Object Pascal
    • Databases
    • Network, Cloud and Web
    • Windows API
    • Cross-platform
    • Delphi IDE and APIs
    • General Help
  • Delphi General Discussions
    • Tips / Blogs / Tutorials / Videos
    • Delphi Third-Party
    • Job Opportunities / Coder for Hire
    • I made this
  • Software Development
    • Project Planning and -Management
    • Software Testing and Quality Assurance
  • Community
    • Community Management


  • Community Calendar

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start




Found 16 results

  1. Hi, just for you guys to weigh in, we have located a bug in the Delphi 10.4 compiler, that removes a totally valid assign statement in RELEASE mode, believing, that the code will never be executed. The actual method is from the mORMot library in releases before last week (unit SynCommons.pas, method TSynAnsiFixedWidth.AnsiBufferToUTF8. A full discussion is available at the mORMot-Forum: https://synopse.info/forum/viewtopic.php?id=5520 . I have reported the bug to Embarcadero: https://quality.embarcadero.com/browse/RSP-30088 . Please check out my report and try to confirm and weigh in there. It should be reproducible. --- Note, the compiler will tell you (Hint H2077), that the value assigned is never used and thus, in RELEASE mode, with optimizations enabled, drop the code completely. Thanks for your time and support 👍
  2. f_CRYPTO_get_ex_data should return Pointer, not Integer. The code in question is at OverbyteIcsLIBEAY.pas line 1847, SVN 1476: f_CRYPTO_get_ex_data: function(r: PCRYPTO_EX_DATA; idx: integer): integer; cdecl = Nil; The corresponding C declaration from OpenSSL's crypto.h: void *CRYPTO_get_ex_data(const CRYPTO_EX_DATA *ad, int idx); Suggested solution: f_CRYPTO_get_ex_data: function(r: PCRYPTO_EX_DATA; idx: integer): Pointer; cdecl = Nil; Reference: https://www.openssl.org/docs/man1.1.1/man3/CRYPTO_get_ex_data.html Ralf
  3. EVP_PKEY_paramgen() pkey should be a double pointer parameter. OverbyteIcsLIBEAY.pas line 1752, SVN 2063: f_EVP_PKEY_paramgen: function(pctx: PEVP_PKEY_CTX; pkey: PEVP_PKEY): Integer; cdecl = Nil; Notice the two ** asterisks in the OpenSSL's evp.h C declaration: int EVP_PKEY_paramgen(EVP_PKEY_CTX *ctx, EVP_PKEY **ppkey); Possible fixes: { More C like: Better if ppkey may be nil. } f_EVP_PKEY_paramgen: function(pctx: PEVP_PKEY_CTX; ppkey: PPEVP_PKEY): Integer; cdecl = Nil; { More Pascal like. Notice that nil cannot be passed this way. } f_EVP_PKEY_paramgen: function(pctx: PEVP_PKEY_CTX; var pkey: PEVP_PKEY): Integer; cdecl = Nil; Reference: https://www.openssl.org/docs/man1.1.1/man3/EVP_PKEY_paramgen.html Ralf
  4. At the time of this writing, TCryptoExNewFunc is declared as a function while it should be a procedure. OverbyteIcsLIBEAY.pas line 1752, SVN 1476: TCryptoExNewFunc = function(parent: Pointer; ptr: Pointer; ad: PCRYPTO_EX_DATA; idx: integer; argl: DWord; argp: Pointer): Integer; cdecl; This is the corresponding C declaration from OpenSSL's crypto.h, documented here: https://www.openssl.org/docs/man1.1.1/man3/CRYPTO_EX_new.html typedef void CRYPTO_EX_new (void *parent, void *ptr, CRYPTO_EX_DATA *ad, int idx, long argl, void *argp); This is the Pascal translation matching the C declaration: TCryptoExNewFunc = procedure(parent: Pointer; ptr: Pointer; ad: PCRYPTO_EX_DATA; idx: integer; argl: DWord; argp: Pointer); cdecl; Ralf
  5. note: We have seen these issues with multiple versions of the OpenSSL binaries, including the ones bundled with ICS 8.64. Please consider the following code snippet: var s := TSslContext.Create(nil); try s.SslCALines.Text := sslRootCACertsBundle(); try s.InitContext(); except on e: exception do ShowMessage(e.Message); end; finally s.Free(); end; This snippet works on most machines, but we have a few machines at client sites, where this code raises an exception: 'Error reading info file "Lines"'. (We haven't figured out yet why these specific machines have this issue). This exception is raised on OverbyteIcsWSocket.pas:14667 (ICS 8.64). InfoStack := PStack(f_PEM_X509_INFO_read_bio(InBIO, nil, nil, nil)); if not Assigned(InfoStack) then raise ESslContextException.CreateFmt('Error reading info file "%s"', [FileName]); Apparently the call to f_PEM_X509_INFO_read_bio() failed, but no information is give why, so we've added some calls to f_ERR_get_error() to see what is going wrong, and then it turns out the call to f_PEM_X509_INFO_read_bio() sets the error code 151580774 (get_header_and_data). To find out which of the hard coded certificates returned by sslRootCACertsBundle() were making this error happening, we've passed each of the certificates (sslRootCACerts001, sslRootCACerts002, etc) one by one to an TSSLContext to see which ones failed. This showed 2 interesting things: There is a 'typo' in sslRootCACerts009 and sslRootCACerts011: 'AGAT/3B+XxFNSRuzFVJ7yVTav52Vr2ua2J7p8eRDjeIRRDq/r72DQnNSi6q7pynP' + #13#10 + '9WQcCk3RvKqsnyrQ/39/2n3qse0wJcGE2jTSW3iDVuycNsMm4hH2Z0kdkquM++v/' + #13#10 + 'eu6FSqdQgPCnXEqULl8FmTxSQeDNtGPPAUO6nIPcj2A781q0tHuu2guQOHXvgR1m' + #13#10 + '0vdXcDazv/wor3ElhVsT/h5/WrQ8' + #13#10; sslRootCACerts010 = '-----END CERTIFICATE-----' + #13#10 + '# X509 SSL Certificate' + #13#10 + and 'S0Zj/gA0QHDBw7mh3aZw4gSzQbzpgJHqZJx64SIDqZxubw5lT2yHh17zbqD5daWb' + #13#10 + 'QOhTsiedSrnAdyGN/4fy3ryM7xfft0kL0fJuMAsaDk527RH89elWsn2/x20Kk4yl' + #13#10 + '0MC2Hb46TpSi125sC8KKfPog88Tk5c0NqMuRkrF8hey1FGlmDoLnzc7ILaZRfyHB' + #13#10 + 'NVOFBkpdn627G190' + #13#10; sslRootCACerts012 = '-----END CERTIFICATE-----' + #13#10 + '# X509 SSL Certificate' + #13#10 + (the END CERTIFICATE line is part of the wrong constant), which isn't a problem when you call sslRootCACertsBundle() since all constants are concatenated, but which shows up if you try to use these certificates separately. More interestingly, one these specific machines there seems to be an issue with sslRootCACerts033 and sslRootCACerts034. This is sslRootCACerts033: # X509 SSL Certificate # Subject Common Name: GlobalSign # Subject Organisation: GlobalSign # Subject Organisation Unit: GlobalSign Root CA - R2 # GlobalSign Root R2 SHA1 • RSA • 2048 # Issuer: Self Signed # Expires: 15/12/2021 -----BEGIN CERTIFICATE----- MIIDujCCAqKgAwIBAgILBAAAAAABD4Ym5g0wDQYJKoZIhvcNAQEFBQAwTDEgMB4G A1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjIxEzARBgNVBAoTCkdsb2JhbFNp Z24xEzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDYxMjE1MDgwMDAwWhcNMjExMjE1 MDgwMDAwWjBMMSAwHgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMjETMBEG A1UEChMKR2xvYmFsU2lnbjETMBEGA1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAKbPJA6+Lm8omUVCxKs+IVSbC9N/hHD6ErPL v4dfxn+G07IwXNb9rfF73OX4YJYJkhD10FPe+3t+c4isUoh7SqbKSaZeqKeMWhG8 eoLrvozps6yWJQeXSpkqBy+0Hne/ig+1AnwblrjFuTosvNYSuetZfeLQBoZfXklq tTleiDTsvHgMCJiEbKjNS7SgfQx5TfC4LcshytVsW33hoCmEofnTlEnLJGKRILzd C9XZzPnqJworc5HGnRusyMvo4KD0L5CLTfuwNhv2GXqF4G3yYROIXJ/gkwpRl4pa zq+r1feqCapgvdzZX99yqWATXgAByUr6P6TqBwMhAo6CygPCm48CAwEAAaOBnDCB mTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUm+IH V2ccHsBqBt5ZtJot39wZhi4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5n bG9iYWxzaWduLm5ldC9yb290LXIyLmNybDAfBgNVHSMEGDAWgBSb4gdXZxwewGoG 3lm0mi3f3BmGLjANBgkqhkiG9w0BAQUFAAOCAQEAmYFThxxol4aR7OBKuEQLq4Gs J0/WwbgcQ3izDJr86iw8bmEbTUsp9Z8FHSbBuOmDAGJFtqkIk7mpM0sYmsL4h4hO 291xNBrBVNpGP+DTKqttVCL1OmLNIG+6KYnX3ZHu01yiPqFbQfXf5WRDLenVOavS ot+3i9DAgBkcRcAtjOj4LaR0VknFBbVPFd5uRHg5h6h+u/N5GJG79G+dwfCMNYxd AfvDbbnvRG15RjF+Cv6pgsH/76tuIMRQyV+dTZsXjAzlAcmgQWpzU/qlULRuJQ/7 TBj0/VLZjmmx6BEP3ojY+x1J96relc8geMJgEtslQIxq/H5COEBkEveegeGTLg== -----END CERTIFICATE----- When processing this certificate on these specific machines OpenSSL gives this error, unless: - I remove one of the • in the 5th line from the top. (As long as there is only 1 • in the file it's ok, as soon as I add a 2nd • anywhere in the header the error returns) - I add a CRLF at the bottom of the file The same thing applies to sslRootCACerts034. I realize that this is probably a bug in OpenSSL itself, but it might be wise to remove the •'s from the hard coded certificates to work around this issue. Curious if anyone can shed some light on the cause of this 🙂 Merijn
  6. In OverbyteIcsWSocket.pas, PunyServerName is always filled with 8-bit data, even if it is a 16-bit UnicodeString on Unicode Delphis. This happens in OverbyteIcsWSocket.pas line 15916 (SVN 1469): Move(DataExt[5], Ws.FCliHelloData.PunyServerName[1], Slen); The line above works well with non Unicode Delphis, but copies incorrect data in Unicode enabled Delphis. Cause is the declaration of PunyServerName (line 3488): TClientHelloData = record ServerName: String; PunyServerName: String; // <-- Problem here. ... Later on, this results in incorrect conversion to ServerName. See that the OverbyteIcsSslWebServ demo outputs garbled SNI and Server Name instead of localhost: HTTPS Server is waiting for connections https://localhost/demo.html HTTP Server is waiting for connections http://localhost/demo.html [10:17:36] SNI "潬慣桬獯t Client Hello: Server Name: 潬慣桬獯t [10:18:15] SNI "潬慣桬獯t Client Hello: Server Name: 潬慣桬獯t A quick remedy is to declare PunyServerName as AnsiString and work around the warning "OverbyteIcsWSocket.pas(15968): W1057 Implicit string cast from 'AnsiString' to 'string'", possibly be adding a typecast. TClientHelloData = record ServerName: String; PunyServerName: AnsiString; // <-- 8-bit string, even in Unicode Delphis. ... Ralf
  7. OverbyteIcsLIBEAY.pas line 1994 (SVN 1469) declares f_EVP_DigestSignInit() like this: f_EVP_DigestSignInit: function(ctx: PEVP_MD_CTX; pctx: PEVP_PKEY_CTX; etype: PEVP_MD; impl: PEngine; pkey: PEVP_PKEY): Integer; cdecl = Nil; In Pascal, pctx is a single pointer, but C declares pctx as a double pointer: int EVP_DigestSignInit(EVP_MD_CTX *ctx, EVP_PKEY_CTX **pctx, const EVP_MD *type, ENGINE *e, EVP_PKEY *pkey); Following nearby declarations, Pascal should probably change pctx to a var parameter. Reference: https://www.openssl.org/docs/man1.1.1/man3/EVP_DigestSignInit.html Ralf
  8. Samples\Delphi\SslInternet\OverbyteIcsHttpsServer1.pas line 415 has a reference to OverbyteIcsWSocket.SslWSocketCopyRight which does not exist: Display(' ' + Trim(OverbyteIcsWSocket.SslWSocketCopyRight)); As a result, the OverbyteIcsHttpsServer1.pas unit does not compile. Ralf
  9. OverbyteIcsLIBEAY.pas line 2336 (SVN 1464) declares f_X509_check_ip_asc() like this: f_X509_check_ip_asc: function(Cert: PX509; Paddress: PAnsiChar; namelen: size_t; flags: Cardinal): Integer; cdecl = nil; This is different from the OpenSSL definition. The Pascal declaration has an extra namelen parameter not present in the C header: int X509_check_ip_asc(X509 *, const char *address, unsigned int flags); Reference: https://www.openssl.org/docs/man1.1.1/man3/X509_check_ip_asc.html Ralf
  10. OverbyteIcsSSLEAY.pas line 2160 (SVN 1464) declares f_SSL_set_msg_callback() to use a TProto_msg_cb callback. TProto_msg_cb is defined in line 1270 as a function: TProto_msg_cb = function (write_p, version, content_type: integer; buf: PAnsiChar; size_t: integer; ssl: PSSL; arg: Pointer): Integer; cdecl; { V8.40 handshake protocol message callback } This is different from the OpenSSL definition. The C header declares the callback as a procedure which does not return a value (void): void SSL_CTX_set_msg_callback(SSL_CTX *ctx, void (*cb)(int write_p, int version, int content_type, const void *buf, size_t len, SSL *ssl, void *arg)); Reference: https://www.openssl.org/docs/man1.1.1/man3/SSL_set_msg_callback.html Ralf
  11. OverbyteIcsSSLEAY.pas line 2097 (SVN 1464) declares f_SSL_clear() like this: f_SSL_clear: procedure(S: PSSL); cdecl = nil; This is different from the OpenSSL definition. The Pascal declaration is a procedure, but the C declaration a function with an Integer return value: int SSL_clear(SSL *ssl); Reference: https://www.openssl.org/docs/man1.1.1/man3/SSL_clear.html Ralf
  12. OverbyteIcsSSLEAY.pas line 2095 (SVN 1464) declares f_SSL_bytes_to_cipher_list() like this: f_SSL_bytes_to_cipher_list: function(s: PSSL; cbytes: PAnsiChar; len: size_t; isv2format: Boolean; sk, scvsvs: PSTACK_OF_SSL_CIPHER): LongInt; cdecl = nil; { V8.64 } This is different from the OpenSSL definition. The Pascal declaration passes sk and scvsvs as simple pointers, instead of pointer addresses or var parameters. In contrast, the C header uses a double pointer for both parameters: int SSL_bytes_to_cipher_list(SSL *s, const unsigned char *bytes, size_t len, int isv2format, STACK_OF(SSL_CIPHER) **sk, STACK_OF(SSL_CIPHER) **scsvs); Reference: https://www.openssl.org/docs/man1.1.1/man3/SSL_bytes_to_cipher_list.html Ralf
  13. ŁukaszDe

    [Bug] Line breaks - Local procedures

    When selected option is on than two spaces before local procedure/function are missing. Tested on GExperts 1.3.15 build 84 version.
  14. I finally got around to installing 10.3.3 and now I get this message every time I quit Delphi: --------------------------- Anwendungsfehler --------------------------- Exception EAssertionFailed in Modul GExpertsRS103.dll bei 00055131. Call DeactivateFontsInfo before calling this. (D:\source\_sourceforge\GExperts\externalsource\UniSynEdit\SynTextDrawer.pas, Zeile 475). --------------------------- OK --------------------------- I have been getting a more generic error ever since 10.2 but kind of got used to it. This now is more specific and I'll report it to the GExperts bug tracker as well.
  15. Hi, I try to adopt outstanding and free Pas2js transpiler to Delphi language. My main development IDE is Delphi CE Rio, so I decided to try a new Delphi syntax: generic collections and inline variables. And stumbled upon a runtime error. The code (simplified): program TestInlineVarForDictionary; {$APPTYPE CONSOLE} {$R *.res} uses SysUtils, Generics.Collections; procedure TestDictErr; var Dict: TDictionary<string,TObject>; begin Dict := TDictionary<string,TObject>.Create; for var item in Dict do Writeln('Key = ', item.Key, 'Name = ', item.Value.ClassName); end; procedure TestDictOK; var Dict: TDictionary<string,TObject>; item: TPair<string,TObject>; begin Dict := TDictionary<string,TObject>.Create; for item in Dict do Writeln('Key = ', item.Key, 'Name = ', item.Value.ClassName); end; begin try //!!TestDictOK; TestDictErr; except on E: Exception do begin Writeln(E.ClassName, ': ', E.Message); Write('Press Enter to continue...'); Readln; end; end; end. This program causes Exception class $C0000005 with message 'access violation at 0x0040a86e: write of address 0x0040a29e'. Can you confirm it? Is it a bug in the compiler or/and RTL, or am I misusing the new syntax? It's interesting: if you uncomment TestDictOK that does enumeration in old-style, the exception will disappear!
  16. I have the following code (Delphi Berlin): interface type TSliver = record public private case integer of 8: (Data8: int64); end; TSlice = record private FData: array [0..63] of byte; end; TSliverHelper = record helper for TSliver class function NS(const North, South: TSlice; out Changed: TSliverChanges): TSliver; static; inline; end; {$L 'C:\mydir\AVXGenerate.o'} //imported assembly generated by lazarus. procedure AVXGENERATE_TSLIVERHELPER_NS; external name 'AVXGENERATE_$$_TSLIVERHELPER_NS'; //no parameters for simplicity. implementation class function TSliverHelper.NS(const North, South: TSlice; out Changed: TSliverChanges): TSliver; {inline;} //RCX =North: PSlice //RDX =South: PSlice //R8 = Changed: PSliverChanges ((scUnchanged=0, scChanged=1, scInvalid=3)); //RAX = Result: TSliver (as Int64) begin AVXGENERATE_TSLIVERHELPER_NS; end; //asm // jmp AVXGENERATE_TSLIVERHELPER_NS; //end; The asm method works correctly, the inlined method does not. If we look at the generated code it's easy to see why this happens. a:= TSliver.NSTest(N,S,statusA); //a = -1 UnitTests.pas.877: b:= TSliver.NS(N,S, statusB); 00000000009A77CE 488D8C2480000000 lea rcx,[rsp+$0080] 00000000009A77D6 488D542440 lea rdx,[rsp+$40] 00000000009A77DB 4C8D44242E lea r8,[rsp+$2e] 00000000009A77E0 E82B5E0100 call TSliverHelper.NS 00000000009A77E5 4889442430 mov [rsp+$30],rax //b = 7 why? //Let's see what's happening in the inlined method. class function TSliverHelper.NS(const [ref] N,S: TBigRec; out status: TEnumRec): UInt64_Rec; Unit2.pas.4360: begin 00000000009BD610 55 push rbp 00000000009BD611 4883EC30 sub rsp,$30 00000000009BD615 488BEC mov rbp,rsp Unit2.pas.4361: AVXGENERATE_TSLIVERHELPER_NS; 00000000009BD618 E833350000 call AVXGENERATE_TSLIVERHELPER_NS //external asm procedure with no declared params. Unit2.pas.4362: end; //At this point RAX = result = -1, all OK 00000000009BD61D 488B4528 mov rax,[rbp+$28] //Oops, RAX gets overwritten, why? <<<<??????????????????????? 00000000009BD621 488D6530 lea rsp,[rbp+$30] 00000000009BD625 5D pop rbp 00000000009BD626 C3 ret Why does the compiler insert an assignment to RAX? I have not instructed it to do anything of the sort. Compiling this code also does not issue a warning that Result might be unassigned. Why does the compiler do this? (I know I can fix this by declaring the external proc as a function, but that's beside the point). EDIT When we redefine the external proc as a function and change the inline method as shown below, correct code gets generated. It also gives some insight what is going on: Unit2.pas.4360: begin 00000000009BD610 55 push rbp 00000000009BD611 4883EC30 sub rsp,$30 00000000009BD615 488BEC mov rbp,rsp Unit2.pas.4361: Result:= AVXGENERATE_TSLIVERHELPER_NS; 00000000009BD618 E833350000 call AVXGENERATE_TSLIVERHELPER_NS 00000000009BD61D 48894528 mov [rbp+$28],rax //pointless stack trashing Unit2.pas.4362: end; 00000000009BD621 488B4528 mov rax,[rbp+$28] //the exit code expects Result to be in the stackframe. 00000000009BD625 488D6530 lea rsp,[rbp+$30] 00000000009BD629 5D pop rbp 00000000009BD62A C3 ret The compiler is just copy pasting its exit code, regardless of the actual code in the body. Note that I've compiled the code with no stackframes