CleanRegisteredVirtualTableModule called too often

h.hasenack · 2012-10-09 09:53:15

I'm using a dynamically create TRestServer, and for this I have to register my model with a certein server.

Unfortunately, the TSQLRestServer calls (through the SQLite3 engine) the destructor TSQLVirtualTableModuleServerDB.Destroy;, whign inturn calls CleanRegisteredVirtualTableModule.

This causes my TVirtualTableModules.FServer to ne set to nil, and my CreateMissingTables call to fail.

      Model := TLCSWorkbaseModel.Create(lURI);
      VirtualTableExternalRegisterAll(lModel, FConnectionProperties);
      RestServerDB := TLCSServerSQLRestServerDB.Create(lModel, lSqLite3FileName, False); // indirectly calls TSQLVirtualTableModuleServerDB.Destroy; cause FServer to be NIL
      Model.Owner := lRestServerDB; //Make Restserver destroy model

      RestServerDB.CreateMissingTables; // exception FServer=nil raised here

So for now I disabled the CleanRegisteredVirtualTableModule call from within TSQLVirtualTableModuleServerDB.Destroy, and my dynamic table creation works again. I dont get why the

destructor TSQLVirtualTableModuleServerDB.Destroy;
begin
// HH:Disabled
//  if fServer<>nil then
//    (fServer as TSQLRestServerDB).CleanRegisteredVirtualTableModule;
  inherited Destroy;
end;

Remember I'm creating a 2nd RestServer on the fly here, one (my "root" server) is already running.

Here's the call stack to the destructor call when I create my secondary rest server.

SQLite3.TSQLVirtualTableModuleServerDB.Destroy
:0040949b TObject.Free + $B
SynSQLite3.sqlite3_free_table($3909DD8)
:00673be1 sqlite3_free_table + $278D
SynSQLite3.sqlite3_create_module_v2(59809240,'External',$38BF43C,$38BF410,SynSQLite3.sqlite3InternalFreeObject)
:00673c60 sqlite3_create_module_v2 + $1C
:00695D34 Sqlite3::TSQLVirtualTableModuleSQLite3::SetDB(Self=:038BF410, aDB=:039777B8)
:00695DE4 Sqlite3::TSQLVirtualTableModuleServerDB::TSQLVirtualTableModuleServerDB(Self=:038BF410, aClass=:0062A310, aServer=:038B7C00, ...)
:00693898 Sqlite3::TSQLRestServerDB::InitializeEngine(Self=:038B7C00)
:00693758 Sqlite3::TSQLRestServerDB::TSQLRestServerDB(Self=:038B7C00, aModel=:0398E0E0, aDB=:039777B8, aHandleUserAuthentication=true, ...)
:0069392A Sqlite3::TSQLRestServerDB::TSQLRestServerDB(Self=:038B7C00, aModel=:0398E0E0, aDBFileName={ L"C:\\Users\\Hans\\AppData\\Roaming\\SN" }, aHandleUserAuthentication=true, aPassword={ NULL }, ...)
:00A1BAE3 Ulcs_server_main::TLCSRestServer::TLCSRestServer(Self=:038B7C00)
:00A1C5EA Ulcs_server_main::LCSRestServer()
:00A1C379 Ulcs_server_main::TLCSHttpServer::TLCSHttpServer(Self=:03953A60)
:00A1C4DA Ulcs_server_main::LCSHttpServer()
:00A3AC96 Lcs_server::initialization()
:75b4339a kernel32.BaseThreadInitThunk + 0x12
:776a9ef2 ntdll.RtlInitializeExceptionChain + 0x63
:776a9ec5 ntdll.RtlInitializeExceptionChain + 0x36

ab · 2012-10-09 11:00:12

Does have each TSQLRestServer instance its own TSQLModel instance?
It should be the case for proper use.

I'm afraid you may get an access violation in some circumstances if you remove the "... := nil" loop.

h.hasenack · 2012-10-09 11:27:03

Yes, each has it's own model.
It seems like the SetDB call jumps into the SQLite3 engine, which causes the destructor to be called (maybe the wrong one?) which clears the FServer properties.

No AV encountered regarding this matter upto now.

Hans

ab · 2012-10-09 11:36:18

I think there was indeed an issue about abusive reset of all TSQLVirtualTableModuleServerDB.Destroy of a given TSQLRestServerDB in destructor TSQLVirtualTableModuleServerDB.Destroy.
See http://synopse.info/fossil/info/463f1ebe6f

mORMot Open Source

#1 2012-10-09 09:53:15

CleanRegisteredVirtualTableModule called too often

#2 2012-10-09 11:00:12

Re: CleanRegisteredVirtualTableModule called too often

#3 2012-10-09 11:27:03

Re: CleanRegisteredVirtualTableModule called too often

#4 2012-10-09 11:36:18

Re: CleanRegisteredVirtualTableModule called too often

Board footer