I read somewhere that you must include "Threads" in your uses clause to
ensure multithread memory allocation!
Google for it (USD, DELPHI, FIREBIRD, THREAD, USES).
MAYBE your random problem is when 2 concurrent users uses your UDF function
and try to allocate/dispose memory.
Sorry my bad english.
Fabiano.
De: firebird-support@yahoogroups.com
[mailto:firebird-support@yahoogroups.com] Em nome de ICAMSoft
Enviada em: quinta-feira, 28 de novembro de 2013 08:44
Para: firebird-support@yahoogroups.com
Assunto: RE: [firebird-support] Re: *** possible bug in FB 2.5.2
supperclassic with UDF ***
Prioridade: Alta
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 300 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
