Memory corruption in direct mode

Discussion of open issues, suggestions and bugs regarding ODAC (Oracle Data Access Components) for Delphi, C++Builder, Lazarus (and FPC)
Post Reply
a-s-z
Posts: 106
Joined: Wed 03 Dec 2008 06:01

Memory corruption in direct mode

Post by a-s-z » Mon 18 Jan 2010 09:58

Hello,

I am getting a nasty memory deallocation error when using direct mode. The error is critical, because the program stops responding after the error (the memory pool is not unlocked due to the exception)!
When using oci mode, everything is fine. The error does only occur, if Options.QueryRecCount is set.
I am using Delphi 2009, Odac 6.90.0.54, Oracle 10g.

There is no error when using previous odac version.

Any hints?

Compiling the application with debug information and fastmm in full debug mode yields the following logs:

Code: Select all

--------------------------------2010/1/18 10:10:06--------------------------------
FastMM has detected an error during a FreeMem operation. The block header has been corrupted. 

The current stack trace leading to this error (return addresses): 

Current memory dump of 256 bytes starting at pointer address 1E8B64:
54 00 4F 00 72 00 61 00 51 00 75 00 65 00 72 00 79 00 00 00 5C 00 00 00 00 00 00 00 AB AB AB AB
AB AB AB AB 00 00 00 00 00 00 00 00 C6 00 07 00 92 07 1C 00 F0 21 3A 77 48 49 4D 4C 70 21 3A 77
4C 21 3A 77 2C 21 3A 77 18 21 3A 77 01 00 00 00 01 00 00 00 01 00 00 00 00 00 00 00 03 00 00 00
04 00 00 00 04 00 00 00 10 00 00 00 10 00 00 00 01 00 00 00 FF 00 00 00 FF FF FF FF C0 C0 C0 00
E0 19 10 F8 8A 1F 05 14 2E 20 05 EA 70 DD 16 00 00 00 50 0E 5D 0F 01 42 41 19 01 ED FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
T  .  O  .  r  .  a  .  Q  .  u  .  e  .  r  .  y  .  .  .  \  .  .  .  .  .  .  .  «  «  «  «
«  «  «  «  .  .  .  .  .  .  .  .  Æ  .  .  .  ’  .  .  .  ð  !  :  w  H  I  M  L  p  !  :  w
L  !  :  w  ,  !  :  w  .  !  :  w  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .
.  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  ÿ  .  .  .  ÿ  ÿ  ÿ  ÿ  À  À  À  .
à  .  .  ø  Š  .  .  .  .     .  ê  p  Ý  .  .  .  .  P  .  ]  .  .  B  A  .  .  í  ÿ  ÿ  ÿ  ÿ
ÿ  ÿ  ÿ  ÿ  ÿ  ÿ  ÿ  ÿ  ÿ  ÿ  ÿ  ÿ  ÿ  ÿ  ÿ  ÿ  ÿ  ÿ  ÿ  ÿ  ÿ  ÿ  ÿ  ÿ  ÿ  ÿ  ÿ  ÿ  ÿ  ÿ  ÿ  ÿ
ÿ  ÿ  ÿ  ÿ  ÿ  ÿ  ÿ  ÿ  ÿ  ÿ  ÿ  ÿ  ÿ  ÿ  ÿ  ÿ  ÿ  ÿ  ÿ  ÿ  ÿ  ÿ  ÿ  ÿ  .  .  .  .  .  .  .  .
.  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .

--------------------------------2010/1/18 10:13:05--------------------------------
A memory block has been leaked. The size is: 100

The block is currently used for an object of class: TOCIFieldDesc

The allocation number is: 606055

Current memory dump of 256 bytes starting at pointer address 7F574B40:
BC 72 5F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 B5 02 40 80 70 F4 D4 00
70 F4 D4 00 70 F4 D4 00 00 00 00 00 11 0A 57 7F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
26 8B 09 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 56 00 00 00 E4 04 01 00 10 DC 61 7F
7C F1 D4 00 70 F4 D4 00 70 F4 D4 00 70 F4 D4 00 70 F4 D4 00 70 F4 D4 00 70 F4 D4 00 70 F4 D4 00
¼  r  _  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .
.  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .
.  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  µ  .  @  €  p  ô  Ô  .
p  ô  Ô  .  p  ô  Ô  .  .  .  .  .  .  .  W    .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .
&  ‹  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .
.  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .
.  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  V  .  .  .  ä  .  .  .  .  Ü  a  
|  ñ  Ô  .  p  ô  Ô  .  p  ô  Ô  .  p  ô  Ô  .  p  ô  Ô  .  p  ô  Ô  .  p  ô  Ô  .  p  ô  Ô  .

--------------------------------2010/1/18 10:13:05--------------------------------
This application has leaked memory. The small block leaks are (excluding expected leaks registered by pointer):

85 - 100 bytes: TOCIFieldDesc x 1

Note: To obtain a log file containing detail on memory leaks, enable the "FullDebugMode" and "LogMemoryLeakDetailToFile" conditional defines. To disable this memory leak check, undefine "EnableMemoryLeakReporting".
Here is the call stack:

Code: Select all

:7c812afb kernel32.RaiseException + 0x52
CLRClasses.Marshal.FreeHGlobal($12F404)
:005e99e2 N_213.N_207 + $B2
:005f3fb7 N_627 + $1F
:0060822c TOCICommand.GetFieldDesc8 + $104
:0060952e TOCICommand.GetFieldDesc + $52
:00610efe TOCIRecordSet.InternalInitFields + $232
MemData.TData.InitFields
MemData.TMemData.InitFields
:006103f1 TOCIRecordSet.DoExecFetch + $121
:00610992 TOCIRecordSet.ExecFetch + $116
CRAccess.TCRRecordSet.InternalOpen(???)
:00610135 TOCIRecordSet.InternalOpen + $21
MemData.TData.Open
MemData.TMemData.Open
CRAccess.TCRRecordSet.Open
MemDS.TMemDataSet.InternalOpen
DBAccess.TCustomDADataSet.InternalOpen
:0063bb5a TOraDataSet.InternalOpen + $22
DB.TDataSet.DoInternalOpen
DB.TDataSet.OpenCursor(???)
MemDS.TMemDataSet.OpenCursor(False)
DBAccess.TCustomDADataSet.OpenCursor(False)
:0063b92f TOraDataSet.OpenCursor + $17
DB.TDataSet.SetActive(???)
DBAccess.TCustomDADataSet.SetActive(???)
DB.TDataSet.Open
:00517b66 TDataSet.Open + $A
DBAccess.TCustomDADataSet.OpenCursor(False)
:0063b92f TOraDataSet.OpenCursor + $17
DB.TDataSet.SetActive(???)
DBAccess.TCustomDADataSet.SetActive(???)
DB.TDataSet.Open
Regards,
Andre.

a-s-z
Posts: 106
Joined: Wed 03 Dec 2008 06:01

Post by a-s-z » Fri 22 Jan 2010 06:52

Hi,

is there any progress on this issue?

This error in direct mode is critical, and because the error leads to a program hang when next memory block gets allocated, I cannot use direct mode at all and must use oci mode!

Plash
Devart Team
Posts: 2844
Joined: Wed 10 May 2006 07:09

Post by Plash » Fri 22 Jan 2010 13:29

We could not reproduce the problem. Please send to support*devart*com a complete small sample that demonstrates the problem, including the script for creating database objects.

Post Reply