Hello,
We are using DOA 4.1.2 in Delphi 2010 with FastMM 4.99 with FullDebugMode enabled.
When we add a WideStringField as a calculated or lookup field to an OracleDataSet, open the dataset and finally close it at runtime, we get a "The block footer has been corrupted" error from FastMM (full error below).
With the StringField, there are no problems.
Is this a OracleDataSet problem or a FastMM problem ?
Thx !
Pieter
--------------------------------2012/5/10 14:45:09--------------------------------
FastMM has detected an error during a FreeMem operation. The block footer has been corrupted.
The block size is: 60
This block was allocated by thread 0x398, and the stack trace (return addresses) at the time was:
40467A
56640C
501D2F
501EBE
5002E1
50038B
500247
50008E
5CC117
4A065D
473013
The block is currently used for an object of class: Unknown
The allocation number is: 2536
The block was previously freed by thread 0x398, and the stack trace (return addresses) at the time was:
404696
4068FE
533D42
525C54
74206874 [Unknown function at DPA_Merge]
52794E
527991
43FC3B
43FDA1
4C3BCB
4CE551
The current thread ID is 0x398, and the stack trace (return addresses) leading to this error is:
404696
56657A
501CE5
5003C6
500299
50009A
5CC123
4A065D
473013
5C9D2C
473A79
Current memory dump of 256 bytes starting at pointer address 7FF8DDC0:
01 00 00 00 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 00 00 00 00 00 00 00 01 00 00 00 01 01 01 52 05
80 80 80 80 80 80 80 80 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
94 06 00 00 7A 46 40 00 83 83 40 00 08 7A 40 00 CE 98 41 00 43 99 41 00 4C 5B 50 00 5A 00 48 00
C1 5D 50 00 7F 63 50 00 DC 85 50 00 77 55 52 00 98 03 00 00 98 03 00 00 96 46 40 00 D5 68 40 00
22 7A 40 00 CE 98 41 00 43 99 41 00 4C 5B 50 00 C1 5D 50 00 7F 63 50 00 DC 85 50 00 77 55 52 00
4E 79 52 00 44 00 00 00 B0 04 02 00 E2 2B 46 86 68 12 5E 00 80 80 80 80 80 80 80 80 80 80 80 80
80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80
. . . .
We are using DOA 4.1.2 in Delphi 2010 with FastMM 4.99 with FullDebugMode enabled.
When we add a WideStringField as a calculated or lookup field to an OracleDataSet, open the dataset and finally close it at runtime, we get a "The block footer has been corrupted" error from FastMM (full error below).
With the StringField, there are no problems.
Is this a OracleDataSet problem or a FastMM problem ?
Thx !
Pieter
--------------------------------2012/5/10 14:45:09--------------------------------
FastMM has detected an error during a FreeMem operation. The block footer has been corrupted.
The block size is: 60
This block was allocated by thread 0x398, and the stack trace (return addresses) at the time was:
40467A
56640C
501D2F
501EBE
5002E1
50038B
500247
50008E
5CC117
4A065D
473013
The block is currently used for an object of class: Unknown
The allocation number is: 2536
The block was previously freed by thread 0x398, and the stack trace (return addresses) at the time was:
404696
4068FE
533D42
525C54
74206874 [Unknown function at DPA_Merge]
52794E
527991
43FC3B
43FDA1
4C3BCB
4CE551
The current thread ID is 0x398, and the stack trace (return addresses) leading to this error is:
404696
56657A
501CE5
5003C6
500299
50009A
5CC123
4A065D
473013
5C9D2C
473A79
Current memory dump of 256 bytes starting at pointer address 7FF8DDC0:
01 00 00 00 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 00 00 00 00 00 00 00 01 00 00 00 01 01 01 52 05
80 80 80 80 80 80 80 80 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
94 06 00 00 7A 46 40 00 83 83 40 00 08 7A 40 00 CE 98 41 00 43 99 41 00 4C 5B 50 00 5A 00 48 00
C1 5D 50 00 7F 63 50 00 DC 85 50 00 77 55 52 00 98 03 00 00 98 03 00 00 96 46 40 00 D5 68 40 00
22 7A 40 00 CE 98 41 00 43 99 41 00 4C 5B 50 00 C1 5D 50 00 7F 63 50 00 DC 85 50 00 77 55 52 00
4E 79 52 00 44 00 00 00 B0 04 02 00 E2 2B 46 86 68 12 5E 00 80 80 80 80 80 80 80 80 80 80 80 80
80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80
. . . .
