Subject | Re: [firebird-support] Re: FB Service shutting down all by itself |
---|---|
Author | Helen Borrie |
Post date | 2007-09-11T00:53:22Z |
At 07:51 AM 11/09/2007, you wrote:
1) a naughty UDF
2) a sharing violation between client threads
3) using IPServer connections for local threaded operations
"to make Firebird run faster". If you're using Superserver, HT will
add more potential opportunities for thread violations. It will make
it even more likely to surface whatever is causing your AVs.
For 1), make sure that the UDF library is the one that belongs to
your distribution of Firebird - check the property sheet. Also make
sure that you have UDFAccess configured to find only that library
location, and check that any string UDFs in your declarations have
the FREE_IT keyword included.
For 2), check any threaded data access in your application to make
sure that each thread's data access is running in a completely
self-contained [IB_Session/IB_Connection/IB_Transaction + data access
objects] structure that is created for the thread and destroyed
immediately the thread terminates from any cause, including
abnormal. (Essential: the dedicated IB_Session *must* be the first
object in the creation order and the last to be destroyed.)
For 3), if a local client is threading operations, don't use an
IPServer connection (Protocol cpLocal), use cpTCP_IP with Server
localhost (if available) or hostname/IP address. And, of course, make
sure that the isolated structures described in 2), e.g. isapi apps,
are properly set up NOT having any ib_connections with Protocol cpLocal!!
Another thought, if your apps and PSQL modules are using events, is
to make sure your network people haven't suddenly locked down all the
unused ports in the firewall without telling you.
./heLen
>Hi - looked at the log - there are entries like:Three possible sources of this AV are
>
>"Access Violation - The code attempted to access a virtual address
>without privilege to do so. the exceptioi will cause the Firebird
>server to terminate abnormally"
>
>Which it did and re-started
1) a naughty UDF
2) a sharing violation between client threads
3) using IPServer connections for local threaded operations
>I believe this is because the server has hyperthreading switched offKeep hyperthreading disabled. The prime reason for doing this is not
>(make FB run faster?) but the db uses UDF's (the std firebird ones)
>and there may be a threading issue if a call is being made to the
>same UDF by more than one user at the same time.
>(Only a theory - we have enabled hyperthreading tonight and will
>advise result)
"to make Firebird run faster". If you're using Superserver, HT will
add more potential opportunities for thread violations. It will make
it even more likely to surface whatever is causing your AVs.
For 1), make sure that the UDF library is the one that belongs to
your distribution of Firebird - check the property sheet. Also make
sure that you have UDFAccess configured to find only that library
location, and check that any string UDFs in your declarations have
the FREE_IT keyword included.
For 2), check any threaded data access in your application to make
sure that each thread's data access is running in a completely
self-contained [IB_Session/IB_Connection/IB_Transaction + data access
objects] structure that is created for the thread and destroyed
immediately the thread terminates from any cause, including
abnormal. (Essential: the dedicated IB_Session *must* be the first
object in the creation order and the last to be destroyed.)
For 3), if a local client is threading operations, don't use an
IPServer connection (Protocol cpLocal), use cpTCP_IP with Server
localhost (if available) or hostname/IP address. And, of course, make
sure that the isolated structures described in 2), e.g. isapi apps,
are properly set up NOT having any ib_connections with Protocol cpLocal!!
Another thought, if your apps and PSQL modules are using events, is
to make sure your network people haven't suddenly locked down all the
unused ports in the firewall without telling you.
./heLen