Subject | Re: [ib-support] Firebird and threads |
---|---|
Author | Brad Pepers |
Post date | 2001-11-02T02:24:16Z |
On November 1, 2001 04:33 pm, Leyne, Sean wrote:
(Mandrake 8.0) and the Classic version of Firebird. I'm using a version from
quite a few months ago so if there are any changes in the last few months to
fix threads, that could be why I'm still having trouble.
I'm accessing the database using the SQLAPI library which is a C++ interface
above the direct dsql C api. The SQLAPI library allows me to access other
databases with the same code and I'm also testing with Sybase. Keeping
everything else the same and just changing from Firebird to Sybase makes the
problem go away which is why I suspect Firebird. Also the backtrace when it
dies is always in the Firebird code like this:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 2051 (LWP 9354)]
0x4046798f in THD_restore_specific () from /usr/lib/libgds.so
(gdb) bt
#0 0x4046798f in THD_restore_specific () from /usr/lib/libgds.so
#1 0x404c3ffc in return_success () from /usr/lib/libgds.so
#2 0x404bce2c in REM_allocate_statement () from /usr/lib/libgds.so
#3 0x40475da0 in isc_dsql_allocate_statement () from /usr/lib/libgds.so
#4 0x0829e1a8 in IibCursor::Open () at quasar_company.cpp:328
#5 0x0828b103 in SACommand::Open () at quasar_company.cpp:328
#6 0x0828ba5d in SACommand::Prepare () at quasar_company.cpp:328
#7 0x0828bb91 in SACommand::Execute () at quasar_company.cpp:328
#8 0x0807e9d2 in QuasarDB::select (this=0x842eac8, plus=@0xbf5fd91c,
conditions=@0xbf5fd87c) at plu_db.cpp:120
#9 0x08052a66 in POS_Connection::readCommand (this=0x84577f8,
list=@0xbf5fda7c) at pos_connection.cpp:310
#10 0x08050ef8 in POS_Connection::processCommand (this=0x84577f8,
line=@0xbf5fdaec) at pos_connection.cpp:135
#11 0x08050c36 in POS_Connection::run (this=0x84577f8)
at pos_connection.cpp:109
#12 0x080f6a04 in start_thread () at quasar_company.cpp:328
#13 0x4002ec84 in pthread_start_thread_event (arg=0xbf5ffc00) at manager.c:274
The error has also happened at other times in isc_sql_execute2 as well as
isc_dsql_fetch so its not localized to isc_dsql_allocate_statement. As the
above shows I'm using pthreads through the Qt QThread C++ classes. It takes
quite a bit of hammering on the database for the error to occur (three
clients running constant selects and it still takes a while to trigger).
There are no updates or deletes being done, just selects.
--
Brad Pepers
brad@...
> Brad,I'm still trying to track down then why it doesn't work. I'm using Linux
>
> As long as each thread establishes it own connection to the database via
> a network methods (ie. local connections will NOT work), you should be
> fine.
>
> A number of others are already using Firebird/IB is this manner.
(Mandrake 8.0) and the Classic version of Firebird. I'm using a version from
quite a few months ago so if there are any changes in the last few months to
fix threads, that could be why I'm still having trouble.
I'm accessing the database using the SQLAPI library which is a C++ interface
above the direct dsql C api. The SQLAPI library allows me to access other
databases with the same code and I'm also testing with Sybase. Keeping
everything else the same and just changing from Firebird to Sybase makes the
problem go away which is why I suspect Firebird. Also the backtrace when it
dies is always in the Firebird code like this:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 2051 (LWP 9354)]
0x4046798f in THD_restore_specific () from /usr/lib/libgds.so
(gdb) bt
#0 0x4046798f in THD_restore_specific () from /usr/lib/libgds.so
#1 0x404c3ffc in return_success () from /usr/lib/libgds.so
#2 0x404bce2c in REM_allocate_statement () from /usr/lib/libgds.so
#3 0x40475da0 in isc_dsql_allocate_statement () from /usr/lib/libgds.so
#4 0x0829e1a8 in IibCursor::Open () at quasar_company.cpp:328
#5 0x0828b103 in SACommand::Open () at quasar_company.cpp:328
#6 0x0828ba5d in SACommand::Prepare () at quasar_company.cpp:328
#7 0x0828bb91 in SACommand::Execute () at quasar_company.cpp:328
#8 0x0807e9d2 in QuasarDB::select (this=0x842eac8, plus=@0xbf5fd91c,
conditions=@0xbf5fd87c) at plu_db.cpp:120
#9 0x08052a66 in POS_Connection::readCommand (this=0x84577f8,
list=@0xbf5fda7c) at pos_connection.cpp:310
#10 0x08050ef8 in POS_Connection::processCommand (this=0x84577f8,
line=@0xbf5fdaec) at pos_connection.cpp:135
#11 0x08050c36 in POS_Connection::run (this=0x84577f8)
at pos_connection.cpp:109
#12 0x080f6a04 in start_thread () at quasar_company.cpp:328
#13 0x4002ec84 in pthread_start_thread_event (arg=0xbf5ffc00) at manager.c:274
The error has also happened at other times in isc_sql_execute2 as well as
isc_dsql_fetch so its not localized to isc_dsql_allocate_statement. As the
above shows I'm using pthreads through the Qt QThread C++ classes. It takes
quite a bit of hammering on the database for the error to occur (three
clients running constant selects and it still takes a while to trigger).
There are no updates or deletes being done, just selects.
--
Brad Pepers
brad@...