Subject RE: [firebird-support] Re: *** possible bug in FB 2.5.2 supperclassic with UDF ***
Author ICAMSoft

Hi Dmitry,

Thanks for your reply.

 

>> From that, i consider that the implementation of UDF is Ok and the

>> problem is in Firebird itself

>Very questionable conclusion.

 

Ok. i accept the point that too easily «debited» firebird for the problem, given how much mature is and the extrensive period of testing before release. My frank apology to all the community.

 

>> Is possible to exist something wrong in the implementation of UDF that
>> create problem only in super classic mode?

>Yes, usage of malloc() instead of ib_util_malloc() results in random
>crashes often visible on some FB architectures and invisible in other ones.

 

The - very simple - code of udf follows

(newer Delphi one for 64bit - The 32bit version is coded in Delphi7 slightly differently but again create firebird collapse of firebird 32bit Superclassic)

If somebody can help could be very good.

unit FB2_Functions;

 

interface

uses StrUtils,SysUtils,Classes,ansistrings;

 

function ib_util_malloc(l: integer): pointer; cdecl; external 'ib_util.dll';

function icam_ansi_gr_uppercase(const p: PAnsiChar): PAnsiChar;  export; cdecl;

 

function Ansi_GrUpper_Case(s:RawByteString):RawByteString;

var i,l:integer;

begin

   result:=trim(s);

   l:=Length(result);

   for i:=1 to l do begin

     case Result[i] of

      'a'..'z': Result[i]:= ansichar(Ord(Result[i])-32);

     end;

     case result[i] of

       'ά','α','Ά','A': result[i]:='Α';

       'γ': result[i]:='Γ';

       'δ': result[i]:='Δ';

       'ε','έ','Έ','E': result[i]:='Ε';

       'η','ή','Ή','H': result[i]:='Η';

       'θ' : result[i]:='Θ';

       'ι',#250,'ί','Ί','I': result[i]:='Ι';

       'λ' : result[i]:='Λ';

       'ξ' : result[i]:='Ξ';

       'ο','ό','Ό','O': result[i]:='Ο';

       'π' : result[i]:='Π';

       'υ','ύ','Ύ','Y': result[i]:='Υ';

       'φ' : result[i]:='Φ';

       'ψ' : result[i]:='Ψ';

       'ω','ώ','Ώ': result[i]:='Ω';

       #251,#224,'Ϋ': result[i]:='Υ';

       #192,'Ϊ': result[i]:='Ι';

       'σ','ς': result[i]:='Σ';

       'β','B': result[i]:='Β';

       'κ','K': result[i]:='Κ';

       'μ','M': result[i]:='Μ';

       'ν','N': result[i]:='Ν';

       'ρ','P': result[i]:='Ρ';

       'τ','T': result[i]:='Τ';

       'χ','X': result[i]:='Χ';

       'ζ','Z': result[i]:='Ζ';

     end;

   end;

end;

 

function icam_ansi_gr_uppercase(const p: PAnsiChar): PAnsiChar;   cdecl;

var s: RawByteString;

begin

  s := Ansi_GrUpper_Case(RawByteString(p));

  Result := ib_util_malloc(Length(s) + 1);

  StrPCopy(Result, s);

end;

 

Also i forgot to say in my first message

the way i managed reproduce the problem in my devel.pc only in super classic which is:

I run a very long update (regards 3000000 records) with extensive use of given udf (is included in update trigger) and before

it finishes, i run another update query for other table which regards some records (2000) but also uses in update trigger the same udf.

Then - in super classic - collapse happens. If i run the query one by one is ok.

In SS or Classic everything runs ok in any case.

 

Best regards,

and thanks for any given help or thought.

 

From: firebird-support@yahoogroups.com [mailto:firebird-support@yahoogroups.com] On Behalf Of Dmitry Yemanov
Sent: Thursday, November 28, 2013 12:59 PM
To: firebird-support@yahoogroups.com
Subject: [firebird-support] Re: *** possible bug in FB 2.5.2 supperclassic with UDF ***

 

 

28.11.2013 14:30, ICAMSoft wrote:

>
> From that, i consider that the implementation of UDF is Ok and the
> problem is in Firebird itself

Very questionable conclusion.

> Is possible to exist something wrong in the implementation of UDF that
> create problem only in super classic mode?

Yes, usage of malloc() instead of ib_util_malloc() results in random
crashes often visible on some FB architectures and invisible in other ones.

Dmitry

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.3426 / Virus Database: 3629/6873 - Release Date: 11/27/13