Watch, Follow, &
Connect with Us

QualityCentral

Public Report
Report From: Delphi-BCB/Midas/TClientDataSet    [ Add a report in this area ]  
Report #:  104240   Status: Open
[x64] Access Violation in MidasLib
Project:  Delphi Build #:  16.0.4429.46931
Version:    16.4 Submitted By:   Stefan Tashev
Report Type:  Crash / Data loss / Total failure Date Reported:  3/18/2012 8:32:13 PM
Severity:    Critical / Show Stopper Last Updated: 5/16/2012 11:58:38 PM
Platform:    All versions Internal Tracking #:   28236
Resolution: None (Resolution Comments) Resolved in Build: : None
Duplicate of:  None
Voting and Rating
Overall Rating: (1 Total Rating)
3.00 out of 5
Total Votes: 15
Description
[x64]
In a 64bit application when using TClientDataSet with an Index on a WideString field of 20 or more characters and linking MidasLib, an access violation occurs.

This sample is as simple as possible, but the actual problem occurs when a provider builds its packet dataset from a TSQLQuery with order by on such a field.
Steps to Reproduce:
The following code shows the steps:
0. Create a 64bit console application
1. Create a ClientDataSet
2. Add a FieldDef for a WideString field with size 20 or more
3. Set an index on that field
4. Add two records
5. On adding the second record the AV occurs

program DXE2_MidasLib_Bug;

// conditions for error to appear:
// 64 bit platform ( 32 bit - the problem is gone )
// uses MidasLib ( when not using MidasLib the problem is gone )
// index on widestring field
// 20 or more chars for the field ( 19 or less - the problem is gone )
// two or more records in client dataset

{$APPTYPE CONSOLE}

{$R *.res}

uses
  System.SysUtils, DBClient, DB,
  MidasLib;

const
  TestFieldName = 'TEST';

var
  cds: TClientDataSet;

begin
  try
    cds:= TClientDataSet.Create(nil);
    try
      with cds.FieldDefs.AddFieldDef do
        begin
          Name:= TestFieldName;
          DataType:= ftWideString;
          Size:= 20;
        end;

      cds.IndexFieldNames:= TestFieldName;
      cds.CreateDataSet;
      try
        cds.AppendRecord(['first']);
        cds.AppendRecord(['second']);  // AV here
      finally
        cds.Close;
      end;
    finally
      FreeAndNil(cds);
    end;

    WriteLn('Success!');
  except
    on E: Exception do
      Writeln(E.ClassName, ': ', E.Message);
  end;

  WriteLn('Press Enter...');
  ReadLn;
end.
Workarounds
No workaround found!
Attachment
None
Comments

Tomohiro Takahashi at 5/17/2012 7:34:17 PM -
This report was opened with valid Internal Tracking Number.
Thanks.

Paul Thompson at 8/4/2012 3:43:32 AM -
I believe this problem is to do with the PSGetKeyFields method returning a non empty string.  The problem can be reproduced with standard ADO components by creating persistent fields and adding pfInKey to the ProviderFlags for one of the key fields - which should be a WideString. I have a sample project available to demonstrate this, but I think it boils down to the same thing reported here.

Milan Vydareny at 12/26/2012 5:18:35 PM -
I have a similar situation. Using RAD Studio XE2 Update 4

SERVER: TIBDatabase, TIBDataSet (A) and TIBDataSet (B) A and B access different tables in the underlying Interbase database. Both tables have multiple keys, at least one of which is defined as a VARCHAR(20) string CHARACTER SET UTF8. (Interbase reserves 82 bytes as a maximum storage requirement for these fields.)

CLIENT: TClientDataset mapped individually to the server  respective TDataSetProvider components through standard Datasnap connection.

Server running 32-bit version. Client running 64-bit version on same platform. Activate either of the TClientDataset components and immediately receive "C0000005 ACCESS_VIOLATION". The same test run with the 32-bit client version runs successfully. The failing address is :A405E1; MidasLib.

If the Server is modified by unchecking the pfInKey ProviderFlags for the fields that are VARCHAR keys (displayed by the Fields Editor) the Access Violation occurs for neither the 64-bit version of the Client nor the 32-bit client. Of course, the application goes haywire because it no longer knows the correct key fields, so this is not a workaround.

It seems to indicate, however, that the problem lies in the way Midas handles key fields that are widestrings. Remove such keys, and the AV disappears.

Milan Vydareny at 12/26/2012 5:26:04 PM -
I have also discovered some additional anomalies possibly related to this issue. Same scenario as before using a 32-bit server application with Datasnap. This time, using a stored procedure in the Interbase database. The input parameters for the procedure are LargeInt. However, trying to execute the procedure with a 32-bit client results in the amusing message "Catastrophic Failure." Not much to go on.

However, changing the code that sets the parameters to access them as Integers rather than LargeInt fixes the issue and the client runs successfully.

In other words, change the following:

ClientDataset.Params.ParamsByName('A_PARAM').AsLargeInt := SomeIntegerValue;

to the following:

ClientDataset.Params.ParamsByName('A_PARAM').AsInteger := SomeIntegerValue;

In general, there is some evidence to convince me that parameter handling in Midas needs some serious attention.

Server Response from: ETNACODE01

Copyright© 1994 - 2013 Embarcadero Technologies, Inc. All rights reserved.