mORMot Open Source

WladiD

Member

From: Germany

Registered: 2010-10-27

Posts: 35

Cloudy EAccessViolation in SortDynArrayAnsiString

Hi Arnaud,

this morning I received a bug report (determined by madExcept) from one user of Lauge. The worst fact is, that I can't figure out what happens and also can't reproduce it.

Here the call stack:

007330f0 +000 Lauge.exe  SynCommons         14366  +0 SortDynArrayAnsiString
00733873 +013 Lauge.exe  SynCommons         15157  +2 TDynArray.Equals
00733f2f +04b Lauge.exe  SynCommons         15583  +8 TDynArrayHashed.HashFind
00733c04 +01c Lauge.exe  SynCommons         15414  +2 TDynArrayHashed.FindHashedForAdding
007497d0 +018 Lauge.exe  SQLite3             3322  +1 TSQLRestServerDB.PrepareStatement
007499e7 +1cf Lauge.exe  SQLite3             3380 +42 TSQLRestServerDB.GetAndPrepareStatement
0074a4e4 +068 Lauge.exe  SQLite3             3640  +8 TSQLRestServerDB.EngineList
007437cb +38b Lauge.exe  SQLite3Commons     11699 +79 TSQLRestServer.URI
0074b06b +073 Lauge.exe  SQLite3             3957  +4 TSQLRestClientDB.URI
007415ef +047 Lauge.exe  SQLite3Commons     10643  +3 TSQLRestClientURI.ExecuteList
00741fd7 +017 Lauge.exe  SQLite3Commons     10890  +1 TSQLRestClientURI.InternalListJSON
00740dfb +06f Lauge.exe  SQLite3Commons     10279  +3 TSQLRest.Retrieve
0073e98e +056 Lauge.exe  SQLite3Commons      8784  +3 TSQLRecord.Create
007e3275 +075 Lauge.exe  LaugeCDB             543  +4 TCategoriesDB.GetCategoryFromDB
...

and here my usage counterpart:

function TCategoriesDB.GetCategoryFromDB(CategoryID:Int64;
    AdditionalWhereCondition:String):TSQLRecordCategory;
begin
    if AdditionalWhereCondition <> '' then
        AdditionalWhereCondition:=' AND ' + AdditionalWhereCondition;

    Result:=TSQLRecordCategory.Create(GLF.LDB.RestClient,
            '(SiteID = :(%):) AND (CategoryID = :(%):)%',
            [SiteID, CategoryID, AdditionalWhereCondition]);

    if Result.ID = 0 then
        FreeAndNil(Result);
end;

I use  your whole repository checkout cd47cf4439b92723 with the sqlite3.obj (3.7.5) from your v.1.12.

May be this is a known issue and you have already fixed it?

BTW: I think we need a code freeze (new release), hence all users of your SQLite 3 Framework use the same source.

Best regards!

ab

Administrator

From: France

Registered: 2010-06-21

Posts: 14,240

Website

Re: Cloudy EAccessViolation in SortDynArrayAnsiString

Your source code version is a 1.13, from the Delphi code point of view.
You should also update the obj file (see http://synopse.info/fossil/wiki?name=Get+the+source to have the link), in order to get the latest version 3.6.7.2 of the engine. But it should not be the problem here.

The SortDynArrayAnsiString() function should handle nil pointers as expected.
You should try with the latest version.
I made some corrections for every check out, so the version from source code repository is never to be told as stable.

Perhaps there is an algorithm hole in TDynArrayHashed.HashFind, not covered by the tests...
I was not able to reproduce it either.
In worse case, it should not raise an access violation, but make an infinite loop... which I tested and avoided.

I'm adding some new exciting feature: Virtual Tables in pure Delphi code.
So you'll be able to use SQL queries with the speed of our BigTable engine...
That's why the 1.13 is not released yet.
I hope to make it happen soon.

WladiD

Member

From: Germany

Registered: 2010-10-27

Posts: 35

Re: Cloudy EAccessViolation in SortDynArrayAnsiString

I have just updated to f53ad31ef60a34e9 and also the sqlite obj files and hope that this issue will gone.

I know, that it's not the fine way to use some pending code, but I have no other way out...you remember for Problem with Currency properties

Your Virtual Tables solution sounds really cool, I explore it, may be I need it in the near future.

Again, thank you VERY MUCH!

Last edited by WladiD (2011-05-06 07:48:44)

ab

Administrator

From: France

Registered: 2010-06-21

Posts: 14,240

Website

Re: Cloudy EAccessViolation in SortDynArrayAnsiString

I know, that it's not the fine way to use some pending code, but I have no other way out...you remember for Problem with Currency properties

Yes, 1.12 did have some issues... like any software!

In all case, thanks for your feedback!

Your Virtual Tables solution sounds really cool, I explore it, may be I need it in the near future.

It's still a work in progress.... latest check out in our source code repository should be better architecture: now the virtual tables are implemented apart from the DB front end they run on. So you could e.g. share the same virtual table on several DB engine... We'll see...