| Subject | RE: [ib-support] Any ideas |
|---|---|
| Author | Wilson, Fred |
| Post date | 2002-04-02T19:34:42Z |
It appears that we can reproduce the corruption on demand. Not to worry
about not being able to re-create the version. We do use a version control
program, and use it very particularly to track versions. I can re-produce
the exact source/obj's/exe's at the drop of a hat ;)
Never calling commit (or rollback) is not exactly what's causing the
problem. BTW, if the app dies (connection goes away), IB rolls back the
transaction, so the app(s) going away have never been a problem. The
problem is in the commit (and rollback) methods, when the commit fails (and
it can/will at times).
The bug is below:
~~~~~~~~~~~~~~~~~~~~~~~~
XIBOStatus *TXIBO::CommitTrans( void )
{
int result;
// If a transaction has not been started, return an error.
if( mTransactionHandle == NULL )
{
return SetErrorString(XIBOErr_TransactionNotStarted, -1);
}
// Commit the transaction.
result= isc_commit_transaction( mISCStatus, &mTransactionHandle );
// clear all member data except connection when there is no transaction.
mTransactionHandle= NULL;
if(mStatementHandle)
{
isc_dsql_free_statement( mISCStatus, &mStatementHandle, DSQL_drop );
mStatementHandle= NULL;
}
DeleteSQLDA( &mOutSQLDA );
DeleteSQLDA( &mInSQLDA );
if( mSQLParamStr != NULL )
{
free( mSQLParamStr );
mSQLParamStr = NULL;
}
mBlobHandle= NULL;
mEOF= true;
// If there was an error, return error value.
if( result != 0 )
{
return SetErrorString(XIBOErr_CommitTransFailed, result);
}
return SetErrorString( XIBOErr_None );
}
~~~~~~~~~~~~~~~~~~~~~~~~
Note, that if the commit fails, the transaction handle is nuked (
mTransactionHandle= NULL; ) and the resources aren't cleaned up.
Now, when the application realizes that the commit has failed and calls
rollback:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
XIBOStatus *TXIBO::RollbackTrans( void )
{
int result;
// If a transaction has not been started, return an error.
if( mTransactionHandle == NULL )
{
return SetErrorString(XIBOErr_TransactionNotStarted, -1);
}
// Rollback the transaction.
result= isc_rollback_transaction( mISCStatus, &mTransactionHandle );
// clear all member data except connection when there is no transaction.
mTransactionHandle= NULL;
if(mStatementHandle)
{
isc_dsql_free_statement( mISCStatus, &mStatementHandle, DSQL_drop );
mStatementHandle= NULL;
}
DeleteSQLDA( &mOutSQLDA );
DeleteSQLDA( &mInSQLDA );
if( mSQLParamStr != NULL )
{
free( mSQLParamStr );
mSQLParamStr = NULL;
}
mBlobHandle= NULL;
mEOF= true;
// If there was an error, return an error value.
if( result != 0 )
{
return SetErrorString(XIBOErr_RollbackTransFailed, result);
}
return SetErrorString( XIBOErr_None );
}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
You'll note that the rollback will never happen as the method checks for a
nuked transaction handle right off the bat:
if( mTransactionHandle == NULL )
{
return SetErrorString(XIBOErr_TransactionNotStarted, -1);
}
and kicks out. Since the transaction handle was nuked in the commit method,
we now have a problem, Houston ;)
First, we've created a transaction gap, as the application has an
un-commited transaction. Next, well, like I mentioned, we haven't looked
into what goes on after, we've simply (so far) fixed this bug, but the
application continues to run, and leaves some data in a state that will
cause commit possibly to fail again. After a short period of running in this
wacked up state (mmmmm, maybe 15 minutes or so, depending on how busy it
is), we start seeing the corruption on/in IB itself.
As I mentioned before, I'm certain, that at some point after this, one or
more member structures are toast or become toasted and bingo.
The application is written in C++ ( BCB 5.0) and runs on Win2000. All the
applications are. The one in question is a fairly complex, multithreaded
application.
As I mentioned before, right, at the moment, we're just ID'ing and fixing
bugs for this release, so, currently, I'm not spending time tracking down
what the application does when the commit fails. I will later.
When the SQA people first told me that an application was corrupting the
database, I certainly didn't believe them ;) Anyway, they should me some
logs from the applications and I notice the commit failing (we know why, and
that, in itesef is ok), and I found the bug in the code.
Best,
Fred Wilson
SE, Bell & Howell
fred.wilson@...
-----Original Message-----
From: Jason Chapman (JAC2) [mailto:jason@...]
Sent: Tuesday, April 02, 2002 11:24 AM
To: ib-support@yahoogroups.com
Subject: Re: [ib-support] Any ideas
If the investigation into this produces a bug, i.e. badly written client
code can corrupt a DB, then it is going to be important to trace. Never
calling a commit / rollback should never cause a problem, happens all the
time when apps die.
What language is the app written in?
What OS?
How complicated?
If it's Delphi & API Direct, I'ld be more than happy to take a look in my
spare time. Although I would imaging business specific confidentiality
maybe a problem for you and I might take a while to get the "spare" time.
Anyway, don't get rid of the version that breaks IB, not even to change the
connection string.
Good Luck,
JAC
""Wilson, Fred"" <fred.wilson@...> wrote in message
news:E9E4431A916AD21191FD00104B986AEFC238C9@......
ib-support-unsubscribe@egroups.com
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
about not being able to re-create the version. We do use a version control
program, and use it very particularly to track versions. I can re-produce
the exact source/obj's/exe's at the drop of a hat ;)
Never calling commit (or rollback) is not exactly what's causing the
problem. BTW, if the app dies (connection goes away), IB rolls back the
transaction, so the app(s) going away have never been a problem. The
problem is in the commit (and rollback) methods, when the commit fails (and
it can/will at times).
The bug is below:
~~~~~~~~~~~~~~~~~~~~~~~~
XIBOStatus *TXIBO::CommitTrans( void )
{
int result;
// If a transaction has not been started, return an error.
if( mTransactionHandle == NULL )
{
return SetErrorString(XIBOErr_TransactionNotStarted, -1);
}
// Commit the transaction.
result= isc_commit_transaction( mISCStatus, &mTransactionHandle );
// clear all member data except connection when there is no transaction.
mTransactionHandle= NULL;
if(mStatementHandle)
{
isc_dsql_free_statement( mISCStatus, &mStatementHandle, DSQL_drop );
mStatementHandle= NULL;
}
DeleteSQLDA( &mOutSQLDA );
DeleteSQLDA( &mInSQLDA );
if( mSQLParamStr != NULL )
{
free( mSQLParamStr );
mSQLParamStr = NULL;
}
mBlobHandle= NULL;
mEOF= true;
// If there was an error, return error value.
if( result != 0 )
{
return SetErrorString(XIBOErr_CommitTransFailed, result);
}
return SetErrorString( XIBOErr_None );
}
~~~~~~~~~~~~~~~~~~~~~~~~
Note, that if the commit fails, the transaction handle is nuked (
mTransactionHandle= NULL; ) and the resources aren't cleaned up.
Now, when the application realizes that the commit has failed and calls
rollback:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
XIBOStatus *TXIBO::RollbackTrans( void )
{
int result;
// If a transaction has not been started, return an error.
if( mTransactionHandle == NULL )
{
return SetErrorString(XIBOErr_TransactionNotStarted, -1);
}
// Rollback the transaction.
result= isc_rollback_transaction( mISCStatus, &mTransactionHandle );
// clear all member data except connection when there is no transaction.
mTransactionHandle= NULL;
if(mStatementHandle)
{
isc_dsql_free_statement( mISCStatus, &mStatementHandle, DSQL_drop );
mStatementHandle= NULL;
}
DeleteSQLDA( &mOutSQLDA );
DeleteSQLDA( &mInSQLDA );
if( mSQLParamStr != NULL )
{
free( mSQLParamStr );
mSQLParamStr = NULL;
}
mBlobHandle= NULL;
mEOF= true;
// If there was an error, return an error value.
if( result != 0 )
{
return SetErrorString(XIBOErr_RollbackTransFailed, result);
}
return SetErrorString( XIBOErr_None );
}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
You'll note that the rollback will never happen as the method checks for a
nuked transaction handle right off the bat:
if( mTransactionHandle == NULL )
{
return SetErrorString(XIBOErr_TransactionNotStarted, -1);
}
and kicks out. Since the transaction handle was nuked in the commit method,
we now have a problem, Houston ;)
First, we've created a transaction gap, as the application has an
un-commited transaction. Next, well, like I mentioned, we haven't looked
into what goes on after, we've simply (so far) fixed this bug, but the
application continues to run, and leaves some data in a state that will
cause commit possibly to fail again. After a short period of running in this
wacked up state (mmmmm, maybe 15 minutes or so, depending on how busy it
is), we start seeing the corruption on/in IB itself.
As I mentioned before, I'm certain, that at some point after this, one or
more member structures are toast or become toasted and bingo.
The application is written in C++ ( BCB 5.0) and runs on Win2000. All the
applications are. The one in question is a fairly complex, multithreaded
application.
As I mentioned before, right, at the moment, we're just ID'ing and fixing
bugs for this release, so, currently, I'm not spending time tracking down
what the application does when the commit fails. I will later.
When the SQA people first told me that an application was corrupting the
database, I certainly didn't believe them ;) Anyway, they should me some
logs from the applications and I notice the commit failing (we know why, and
that, in itesef is ok), and I found the bug in the code.
Best,
Fred Wilson
SE, Bell & Howell
fred.wilson@...
-----Original Message-----
From: Jason Chapman (JAC2) [mailto:jason@...]
Sent: Tuesday, April 02, 2002 11:24 AM
To: ib-support@yahoogroups.com
Subject: Re: [ib-support] Any ideas
If the investigation into this produces a bug, i.e. badly written client
code can corrupt a DB, then it is going to be important to trace. Never
calling a commit / rollback should never cause a problem, happens all the
time when apps die.
What language is the app written in?
What OS?
How complicated?
If it's Delphi & API Direct, I'ld be more than happy to take a look in my
spare time. Although I would imaging business specific confidentiality
maybe a problem for you and I might take a while to get the "spare" time.
Anyway, don't get rid of the version that breaks IB, not even to change the
connection string.
Good Luck,
JAC
""Wilson, Fred"" <fred.wilson@...> wrote in message
news:E9E4431A916AD21191FD00104B986AEFC238C9@......
> Yup, we've been able to repeat it "on demand".. We haven't looked deeplyinterface
> into it to see what happens to the application (it's only one of 'em) when
> it "goes west", but we know how to provoke it and we know that there was
> some badly written code that's in the wrapper layer around the API
> that was coded.was
> Right now, we're trying to get a release ready to go, so we're more
> interested in getting the bug fixed (which we did) than tracing through,
> trying to find out exactly what the application did after the "incident".
> Later, I can look through the app and see what it was doing.
> What it was doing, in the Commit method, was, if the commit() failed, it
> setting the transaction handle to NULL. I suspect that the applicationbasically
> is/was still attempting to use it somewhere. The Rollback method,
> was never getting called, or I should say, would never work (after ato
> Commit() failed), as one of the first checks in the Rollback() method is
> check for a NULL transaction handle. This, of course, produced asee
> transaction gap, but, as I mentioned, we haven't followed it further to
> what else was going on. We fixed this bug and have now continued on,looking
> for a couple of more things.it's
> Like I mentioned, the corruption is 100% reproducable.
>
> Best,
> Fred Wilson
> SE, Bell & Howell
> fred.wilson@...
>
>
>
> -----Original Message-----
> From: Jason Chapman (JAC2) [mailto:jason@...]
> Sent: Tuesday, April 02, 2002 12:41 AM
> To: ib-support@yahoogroups.com
> Subject: Re: [ib-support] Any ideas
>
>
> No ideas, but I can't see how a client can be doing this by corrupting
> own memory structures. The whole point of the level of abstraction SQL(server:e:\data
> based servers are supposed to give is that a rogue client can not corrupt
> the db.
>
> When you say you can reproduce, you mean you can take a perfectly good db
> and trash it by running your apps?
>
> What about the old chestnut of the connection string error?
> vs server: e :\data)?somewhere
>
> Cheers,
>
> JAC.
>
> ""Wilson, Fred"" <fred.wilson@...> wrote in message
> news:E9E4431A916AD21191FD00104B986AEFC238C1@......
> > IB5.6 running on W2000 (and NT4.0).
> > Client applications using the IB API directly. We obviously done (or am
> > doing) something wrong. We can reproduce the error(s) below with some
> work.
> > I suspect that the client application(s) is trashing some memory
> > (maybe the DPB, the TPB, XSQLDA, etc).. Any ideas what, specifically,can
> > cause the below, from the Interbase Log:http://docs.yahoo.com/info/terms/
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >
> > BUBBA (Server) Mon Apr 01 11:29:04 2002
> > Database: D:\INTRBASE\BIN\GA
> > internal gds software consistency check (pointer page vanished from
> > DPM_next (249))
> >
> >
> > BUBBA (Server) Mon Apr 01 11:42:19 2002
> > Database: D:\INTRBASE\BIN\GA
> > internal gds software consistency check (pointer page vanished from
> > DPM_next (249))
> >
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >
> > Thanks,
> >
> > Best,
> > Fred Wilson
> > SE, Bell & Howell
> > fred.wilson@...
> >
> >
> >
> > To unsubscribe from this group, send an email to:
> > ib-support-unsubscribe@egroups.com
> >
> >
> >
> > Your use of Yahoo! Groups is subject to
> >To unsubscribe from this group, send an email to:
> >
> >
>
>
>
>
> To unsubscribe from this group, send an email to:
> ib-support-unsubscribe@egroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
> To unsubscribe from this group, send an email to:
> ib-support-unsubscribe@egroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
ib-support-unsubscribe@egroups.com
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/