Hi,

MSE created some patches for fpc 2.0.4 rc1
to fix some widestring and db issues.
http://svn.sourceforge.net/viewcvs.cgi/mseide-msegui/trunk/patch_fpc_2_0_4/

I seems they are not applied to rc2.

Can someone with widestring and db knowledge
of fpc dev take a look at this?

It would be nice that for mse/fpc we do not
need to apply patches to release 2.0.4 to be able
to use mse.

thx in advance,

Den Jean

Partly, however, e.g. the cwstring change discussion was started but no conclusion was drawn.

Den Jean wrote:

Hi,

.
.

Thanks for this information. There's been no decision made in the core team that they should / need to be included for 2.0.4 so far, nor were they submitted as issues with 2.0.4-rc1 officially (I haven't been aware of them at all personally). As a general statement (without having looked at them in detail), we need to consider their importance and associated risks carefully.

Tomas

Can you send the RTL/FCL patches to me so I can have a look at it ? I tried to view them with the viewcvs, but when I request a diff, the script fails.

Michael.

The db-files in fpc-2.0.4-rc2 are better up-to-date then the mse-one's. What's left is irrelevent, or in the fopen case, an ugly hack that shoudn't be there, imho.

So for the db-part, nothing has to change.

Joost

thx for checking,
is someone :-) looking to implement/fix blob/text
in the mysql binding ?
(see mse talk)

Did you fix Mantis 6898 in the meantime?

Martin

I didn't but Michael did in the mean time, so it seems.

Well, I can live with that, until I come up with a real solution. I hope that the fix doesn't brake any of the db-tests.

Joost

It seems that Michael used my file for rc1 to build the patch against fixes_2_0, so your changes in 4152 (Fix for datasets with a Recordsize which will not fit in a word) are lost.
The patch to fix Mantis 6898 against 4023 is:
"
Index: bufdataset.inc
=================================================================== --- bufdataset.inc (revision 4023)
+++ bufdataset.inc (working copy)
@@ -77,6 +77,7 @@
var pc : pchar;

 begin
+ if fopen then begin
   FOpen:=False;
   FCurrentRecBuf := FFirstRecBuf;
   SetLength(FUpdateBuffer,0);
@@ -87,6 +88,7 @@
     FreeRecordBuffer(pc);
     end;
   SetLength(FFieldBufPositions,0);
+ end;
 end;
 procedure TBufDataset.InternalFirst;
"

Without this patch tbufdataset writes in coincidental memory areas if it is opened/closed several times with and without dbexceptions. It is the case if in MSEide one presses the test button in SQL editor while debugging the query.
You can imagine what happens later...

Martin

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.

I don't see where the pointer-logix goes wrong in InternalOpen and in InternalClose, can you show to me where the problem is?

Joost

No, the problem is if here was a db exception on open. Without any exception it is OK.

Martin

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?

Joost

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).

procedure TBufDataset.InternalClose;
var pc : pchar;
begin
  FOpen:=False;
  FCurrentRecBuf := FFirstRecBuf;   <<<<<<<<<<<<<------!!!!!
  SetLength(FUpdateBuffer,0);
  while assigned(FCurrentRecBuf) do
    begin
    pc := pointer(FCurrentRecBuf);
    FCurrentRecBuf := FCurrentRecBuf^.next;
    FreeRecordBuffer(pc);                 <<<<<<<<<<<<<<<<-------!!!!
    end;
  SetLength(FFieldBufPositions,0);
end;

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

Martin

:(

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