| Subject | Re: [IBO] ACCVIO loop in fbclient.dll during rundown, maybe related to TIB_EVENTS |
|---|---|
| Author | Helen Borrie |
| Post date | 2008-04-30T02:49:30Z |
At 11:45 AM 30/04/2008, you wrote:
IBO's practice of deferencing statement handles after moving them into (I think!) the Statements property of the connection got broken by a change that Vlad did in Fb 2 to reduce the round trips that were being done by the old client versions. That involved deferring some steps under some conditions which, as Vlad implemented it (and as it stayed throughout Fb 2.0.x and 2.1), mean that the original handle's address needs to be retained for the life of the statement.
So - under some but not all conditions, apparently - IBO's dereferencing of the handles became potentially unsafe with the Fb 2+ clients. Alex's take on it was that with isc_dsql_alloc_statement() it's legal, if unusual, for the client application code to dereference the statement handles. For isc_dsql_alloc_statement2(), however, which IBO abandoned many years ago, it was never "legit".
So what Vlad has done, for the benefit of users of interfaces that dereference statement handles as part of their own internal management of them - which includes other interfaces besides IBO - is to change the way a V.2 fbclient refers to the statement handles. IOW, Fb211 reverts the conditions with regard to statement handles to how it was before Fb2.
The symptom - to the extent it is recognised so far - is that disconnecting an application causes the detach function to go into a loop (consuming 100% of CPU) until the client crashes or the server AVs or both.
Hence my suggestion that you try the Fb211 client to see whether YOUR problem goes away. It doesn't imply that it's sure to fix your problem, AT ALL. It's just that swapping the client library on a couple of affected client machines would be pretty easy to do...
I must say I find it strange that you're using Fb 4.7, though. It was replaced by 4.8 to deal with a number of implementation faults in 4.7. I mean, it seems odd to me that you're going into a panic at the prospect of swapping the fbclient.dll library on affected client machines yet you apparently haven't been bothered about hanging onto a potentially faulty program interface for the past 10 months...
Helen
>I'll have to see if I can get the client to let me use their machineI don't think you read those postings very carefully. "Fb211" refers to the rebuilt client dll that you would distribute to replace the Fb 2.0 client dll. You would do that if you had a reason to, which might include using VERY OLD IBO versions that call isc_dsql_alloc_statement2() rather than isc_dsql_alloc_statement() to allocate statement handles.
>and try that. But what would it mean if that fixed it? Would I
>then have to upgrade everyone to FB211 and IBO 4.8? That would be
>scary.
IBO's practice of deferencing statement handles after moving them into (I think!) the Statements property of the connection got broken by a change that Vlad did in Fb 2 to reduce the round trips that were being done by the old client versions. That involved deferring some steps under some conditions which, as Vlad implemented it (and as it stayed throughout Fb 2.0.x and 2.1), mean that the original handle's address needs to be retained for the life of the statement.
So - under some but not all conditions, apparently - IBO's dereferencing of the handles became potentially unsafe with the Fb 2+ clients. Alex's take on it was that with isc_dsql_alloc_statement() it's legal, if unusual, for the client application code to dereference the statement handles. For isc_dsql_alloc_statement2(), however, which IBO abandoned many years ago, it was never "legit".
So what Vlad has done, for the benefit of users of interfaces that dereference statement handles as part of their own internal management of them - which includes other interfaces besides IBO - is to change the way a V.2 fbclient refers to the statement handles. IOW, Fb211 reverts the conditions with regard to statement handles to how it was before Fb2.
The symptom - to the extent it is recognised so far - is that disconnecting an application causes the detach function to go into a loop (consuming 100% of CPU) until the client crashes or the server AVs or both.
Hence my suggestion that you try the Fb211 client to see whether YOUR problem goes away. It doesn't imply that it's sure to fix your problem, AT ALL. It's just that swapping the client library on a couple of affected client machines would be pretty easy to do...
I must say I find it strange that you're using Fb 4.7, though. It was replaced by 4.8 to deal with a number of implementation faults in 4.7. I mean, it seems odd to me that you're going into a panic at the prospect of swapping the fbclient.dll library on affected client machines yet you apparently haven't been bothered about hanging onto a potentially faulty program interface for the past 10 months...
Helen