Subject | RE: [firebird-support] Re: *** possible bug in FB 2.5.2 supperclassic with UDF *** |
---|---|
Author | ICAMSoft |
Post date | 2013-11-28T11:44:26Z |
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:
>Very questionable conclusion.
> From that, i consider that the implementation of UDF is Ok and the
> problem is in Firebird itself
> Is possible to exist something wrong in the implementation of UDF thatYes, usage of malloc() instead of ib_util_malloc() results in random
> create problem only in super classic mode?
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