Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 8 of 8 total
Thread Memory tables used by multiple threads
Thu, Feb 9 2006 7:34 PMPermanent Link

Oliver Bock
I'm getting a crash in DBISAM 4.22b4 with the stack trace from madExcept
shown below.  It appears that DeleteAllPasswords is trying to use a
TList that has already been destroyed.

It only happens when I create a memory TDBISAMTable in a second thread
for the same client.  It does not happen if it is not a memory table,
and there is no problem in the first thread that attaches to the server.

I create the TDBISAMTable as follows:

   t := TDBISAMTable.Create(nil);
   t.SessionName := fDB.SessionName;
   t.DatabaseName := 'Memory'
   t.TableName := table_name;

Am I doing this right?

I note that there is no way for this table to find the TDBISAMDatabase
(fDB) for this thread because I only tell it "Memory".  Perhaps it
associates a single Memory TDBISAMDatabase with both threads and then
tries to free it twice?


0046c5c5 Classes       2827 TList.Get
00668bac dbisamen           TDataSession.DeleteAllPasswords
00667d19 dbisamen           TDataSession.Destroy
00404670 system        8385 TObject.Free
00662e24 dbisamen           TDataEngine.FreeDataSessions
0065a42d dbisamen           TDataEngine.Destroy
00404670 system        8385 TObject.Free
006b0449 dbisamtb           TDBISAMEngine.FreeInstance
00404a32 system        9060 @ClassDestroy
0047987a Classes       9759 TComponent.Destroy
00404670 system        8385 TObject.Free
006c336a dbisamtb           Finalization
0040519c system       10704 FinalizeUnits
0044d79c madExcept          InterceptFinalizeUnits
00405475 system       11374 @Halt0
0093094f ArtfulLedger   336 initialization
Thu, Feb 9 2006 7:39 PMPermanent Link

Oliver Bock
Oliver Bock wrote:
> I'm getting a crash in DBISAM 4.22b4 with the stack trace from madExcept
> shown below.  It appears that DeleteAllPasswords is trying to use a
> TList that has already been destroyed.

I should have added that my code is executing on the server in a server
procedure.  It is using the session provided by OnServerProcedure and
creating a separate TDBISAMDatabase (fDB) for each thread.


  Oliver
Fri, Feb 10 2006 3:59 AMPermanent Link

"Frans van Daalen"

"Oliver Bock" <oliver-elevatesoft-news@ikucwe.com> wrote in message
news:BB4722A7-FC96-4DDA-882C-6632C5D06B9D@news.elevatesoft.com...
> Oliver Bock wrote:
>> I'm getting a crash in DBISAM 4.22b4 with the stack trace from madExcept
>> shown below.  It appears that DeleteAllPasswords is trying to use a TList
>> that has already been destroyed.
>
> I should have added that my code is executing on the server in a server
> procedure.  It is using the session provided by OnServerProcedure and
> creating a separate TDBISAMDatabase (fDB) for each thread.
>
>
You need an unique session per thread as well
http://www.elevatesoft.com/dbisam4d5_multi_threaded_applications.htm

Fri, Feb 10 2006 2:50 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Oliver,

<< It only happens when I create a memory TDBISAMTable in a second thread
for the same client.  It does not happen if it is not a memory table, and
there is no problem in the first thread that attaches to the server. >>

What do you mean by "second thread" ?  Do you mean the second session that
is connected to the database server ?  If so, then it shouldn't matter since
the two don't use the same session and should not interfere with one
another.  Or are you sharing resources in the server procedure across
multiple sessions ?

--
Tim Young
Elevate Software
www.elevatesoft.com

Sun, Feb 12 2006 6:14 PMPermanent Link

Oliver Bock
Frans van Daalen wrote:
> "Oliver Bock" <oliver-elevatesoft-news@ikucwe.com> wrote in message
> news:BB4722A7-FC96-4DDA-882C-6632C5D06B9D@news.elevatesoft.com...
>> Oliver Bock wrote:
>>> I'm getting a crash in DBISAM 4.22b4 with the stack trace from madExcept
>>> shown below.  It appears that DeleteAllPasswords is trying to use a TList
>>> that has already been destroyed.
>> I should have added that my code is executing on the server in a server
>> procedure.  It is using the session provided by OnServerProcedure and
>> creating a separate TDBISAMDatabase (fDB) for each thread.
>>
>>
> You need an unique session per thread as well
> http://www.elevatesoft.com/dbisam4d5_multi_threaded_applications.htm

Hi Frans,

I create a separate session for each thread at the client end, and
DBISAM takes care of creating matching sessions on the server.


   Oliver
Sun, Feb 12 2006 6:20 PMPermanent Link

Oliver Bock
Tim Young [Elevate Software] wrote:
> Oliver,
>
> << It only happens when I create a memory TDBISAMTable in a second thread
> for the same client.  It does not happen if it is not a memory table, and
> there is no problem in the first thread that attaches to the server. >>
>
> What do you mean by "second thread" ?  Do you mean the second session that
> is connected to the database server ?  If so, then it shouldn't matter since
> the two don't use the same session and should not interfere with one
> another.  Or are you sharing resources in the server procedure across
> multiple sessions ?

Yes, sorry, I meant a second session (in a second thread) connected to
the database server.  As far as I know, there is no sharing of resources
across multiple sessions.

According to the manual:

> ...all TDBISAMDatabase components must also be unique and have their SessionName properties referring to the unique SessionName property of the TDBISAMSession component defined in the manner discussed above.

I guess my question boils down to this: if threads should have separate
instances of any TDBISAMDatabases they use, then who takes care to
ensure there are separate instances of the hidden "Memory"
TDBISAMDatabase?  I was wondering whether my problem might be related to
this discrepancy.


   Oliver
Mon, Feb 13 2006 11:26 AMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Oliver,

<< I guess my question boils down to this: if threads should have separate
instances of any TDBISAMDatabases they use, then who takes care to ensure
there are separate instances of the hidden "Memory" TDBISAMDatabase?  I was
wondering whether my problem might be related to this discrepancy. >>

DBISAM takes care of that, so as long as you have the SessionName property
hooked up correctly for the table or query components, then there won't be
an issue.

--
Tim Young
Elevate Software
www.elevatesoft.com

Thu, Feb 16 2006 1:55 AMPermanent Link

Oliver Bock
Tim,

After much effort I've managed to reduce this to a very simple
client/server demonstration with no threads, which I'll send to you via
a bug report.

For the record, I get a crash when:

CLIENT
1. Create a session.
2. Create a database.
3. Use a TDBISAMQuery to create a memory table.
4. Call a server procedure.
9. Destroy objects and exit.

SERVER (must be using FastMM 4.58 with full debug mode)
5. Receive the server procedure call.
6. Creates a TDBISAMDatabase using the session provided as a param.
7. Open a TDBISAMTable using the memory table.
8. Destroy the TDBISAMTable and TDBISAMDatabase.
10. Exit and crash.
Image