[fpc-devel] fpc 2.0.4 rc2 and mse

Joost van der Sluis joost at cnoc.nl
Wed Aug 2 23:50:28 CEST 2006


On Wed, 2006-08-02 at 21:58 +0200, Martin Schreiber wrote:
> On Wednesday 02 August 2006 16.51, Joost van der Sluis wrote:
> > On Wed, 2006-08-02 at 06:57 +0200, Martin Schreiber wrote:
> > > > > Did you fix Mantis 6898 in the meantime?
> > > >
> > > > You said that TBufDataset can use invalid pointers, even if there
> > > > wasn't any exception, if a dataset is opened and closed more then once.
> > >
> > > No, the problem is if here was a db exception on open. Without any
> > > exception it is OK.
> >
> > Well, then that exception should be handled correctly. If you don't call
> > InternalClose, you'll have a mem-leak.
> >
> > I don't think that any exception (except out-of-memory) can occur in
> > InternalConnect. So I think you mean an exceptions like 'transaction not
> > set', or 'invalid password'? Which problem do you have in particular?
> >
> 
> Edit TSQLQuery.SQL with the SQL editor in MSEide.
> Enter a valid query ("select *  from table1").
> Press the 'Test' button -> the dataset will be opened, data fetched, 
> tbufdataset.ffirstrecbuf and fcurrentrecbuf are set, dataset is closed, 
> ffirstrecbuf is now invalid.
> 
> Enter a invalid query ("select sdf%&/we$$ from table1").
> Press the 'Test' button.
> Exception in TSQLQuery.internalopen, dointernalclose calls internalclose which 
> uses the 
> invalid ffirstrecbuf -> AV or freeing of wrong memory (that hapend in MSEide, 
> I needed 20 hours to find the cause).

:(

But thanks, now I could reproduce the bug and made testcase for it. 

> Possibly it is enough to set ffirstrecbuf to nil in internalclose (untested!).

That does solve the problem, yes. But it's still a temporary solution.
The real solution is imho the patch in the attachment. But I don't dare
to include that patch in 2.0.4, so I'll commit that one after 2.0.4 is
released, or only for 2.1.1.

The real problem is, that in the current implementation the
'internalclose' is actually used as a sort of 'finalize' section. Which
is very ugly, but it's undoable to correct that properly before 2.0.4 is
released.

Joost


-------------- next part --------------
A non-text attachment was scrubbed...
Name: db.diff
Type: text/x-patch
Size: 440 bytes
Desc: not available
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20060802/b955f816/attachment.bin>


More information about the fpc-devel mailing list