View Issue Details

IDProjectCategoryView StatusLast Update
0038990FPCCompilerpublic2021-06-15 15:11
ReporterDenis Golovan Assigned To 
PrioritynormalSeverityminorReproducibilityalways
Status newResolutionopen 
Product Version3.3.1 
Summary0038990: Management operators produce memleaks in special cases
DescriptionHi all

See attached project for details.
Sorry for being rather large, but it seems some minor details influence code generation.

Compiling it with heaptrc unit under 3.3.1 rev.48167 results in following callstacks on exit:

================assign0 r.rc 0
================assign0 r.rc 2
Heap dump by heaptrc unit of "./project1"
41 memory blocks allocated : 4821/4840
39 memory blocks freed : 4789/4808
2 unfreed memory blocks : 32
True heap size : 425984
True free heap : 425504
Should be : 425568
Call trace for block $00007FFFF7FBE3A0 size 0
  $0000000000454E96 NEW_VECTOR, line 216 of uAST.pas
  $0000000000455071 VEC_FROM_ITER$1$CRC3FCD8CEA, line 229 of uAST.pas
  $0000000000454FBE NEW_LIST, line 222 of uAST.pas
  $0000000000455209 ASTNEWLIST4, line 249 of uAST.pas
  $000000000045508F TESTUNIT, line 261 of uAST.pas
  $000000000040117E main, line 16 of project1.lpr
Call trace for block $00007FFFF7FC7200 size 32
  $0000000000454E96 NEW_VECTOR, line 216 of uAST.pas
  $0000000000455071 VEC_FROM_ITER$1$CRC3FCD8CEA, line 229 of uAST.pas
  $0000000000454FBE NEW_LIST, line 222 of uAST.pas
  $0000000000455209 ASTNEWLIST4, line 249 of uAST.pas
  $000000000045508F TESTUNIT, line 261 of uAST.pas
  $000000000040117E main, line 16 of project1.lpr
Tagsmanagement operators
Fixed in Revision
FPCOldBugId
FPCTarget
Attached Files

Activities

Denis Golovan

2021-06-11 16:12

reporter  

RCBug2.tar.gz (4,485 bytes)

runewalsh

2021-06-14 16:12

reporter   ~0131309

Last edited: 2021-06-15 15:11

View 2 revisions

The comment in uAST.new_vector
>direct assignment to Result is invalid for some reason => leads for memleaks
reveals the incomplete understanding of what's going on. Not sure if your case is a bug or merely a consequence of things described below.

Managed 'result' can point not only to a just initialized object, but also to an object that was in use. Say, 'result' of type 'ansistring' can contain the old value of the target of the assignment on the caller side. Moreover, debug builds, maybe with -gt or other switch enabled, initialize string results with 'uninitialized function result in function...' values, to help catch their improper usage.

In general, 'result' is a valid object, but otherwise unpredictable. (Docs mention it, but I forgot where.)

So you need to DecRef the old value before assigning new reference, the same way as you do in 'class operator Copy'.

On the contrary, 'out' function parameters always come in just initialized state. But to achieve this, the compiler literally inserts 'Finalize(a); Initialize(a)' before each call. This can be a non-trivial overhead, so you probably won't want to use 'out' with managed types just to shut up the warning about an unitialized variable, but only when you indeed want a clean object.

Issue History

Date Modified Username Field Change
2021-06-11 16:12 Denis Golovan New Issue
2021-06-11 16:12 Denis Golovan File Added: RCBug2.tar.gz
2021-06-14 13:31 Sven Barth Tag Attached: management operators
2021-06-14 16:12 runewalsh Note Added: 0131309
2021-06-15 15:11 runewalsh Note Edited: 0131309 View Revisions