| Subject | RE: [ib-support] Any ideas |
|---|---|
| Author | Wilson, Fred |
| Post date | 2002-04-02T16:31:15Z |
Yup, we've been able to repeat it "on demand".. We haven't looked deeply
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 interface
that was coded.
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 was
setting the transaction handle to NULL. I suspect that the application
is/was still attempting to use it somewhere. The Rollback method, basically
was never getting called, or I should say, would never work (after a
Commit() failed), as one of the first checks in the Rollback() method is to
check for a NULL transaction handle. This, of course, produced a
transaction gap, but, as I mentioned, we haven't followed it further to see
what else was going on. We fixed this bug and have now continued on, looking
for a couple of more things.
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 it's
own memory structures. The whole point of the level of abstraction SQL
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? (server:e:\data
vs server: e :\data)?
Cheers,
JAC.
""Wilson, Fred"" <fred.wilson@...> wrote in message
news:E9E4431A916AD21191FD00104B986AEFC238C1@......
ib-support-unsubscribe@egroups.com
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
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 interface
that was coded.
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 was
setting the transaction handle to NULL. I suspect that the application
is/was still attempting to use it somewhere. The Rollback method, basically
was never getting called, or I should say, would never work (after a
Commit() failed), as one of the first checks in the Rollback() method is to
check for a NULL transaction handle. This, of course, produced a
transaction gap, but, as I mentioned, we haven't followed it further to see
what else was going on. We fixed this bug and have now continued on, looking
for a couple of more things.
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 it's
own memory structures. The whole point of the level of abstraction SQL
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? (server:e:\data
vs server: e :\data)?
Cheers,
JAC.
""Wilson, Fred"" <fred.wilson@...> wrote in message
news:E9E4431A916AD21191FD00104B986AEFC238C1@......
> IB5.6 running on W2000 (and NT4.0).work.
> Client applications using the IB API directly. We obviously done (or am
> doing) something wrong. We can reproduce the error(s) below with some
> I suspect that the client application(s) is trashing some memory somewhereTo unsubscribe from this group, send an email to:
> (maybe the DPB, the TPB, XSQLDA, etc).. Any ideas what, specifically, can
> cause the below, from the Interbase Log:
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> 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 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/