View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0036136 | FPC | RTL | public | 2019-10-04 11:25 | 2019-10-07 12:06 |
| Reporter | Bryan Wells | Assigned To | Michael Van Canneyt | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Platform | i386 | OS | Windows and Linux | OS Version | |
| Product Version | 3.0.4 | Product Build | |||
| Target Version | Fixed in Version | 3.3.1 | |||
| Summary | 0036136: TInterfaceList.IndexOf function can cause reference counted Intefaced Objects to be destroyed. | ||||
| Description | The TInterfaceList.IndexOf function causes the passed in objects reference count to be incremented and then decremented. If the passed in object's reference count is already at zero (say because the object is still in the process of being initialised before assignment to a IInterface based field), then when passed to indexOf the destructor is called. This is caused by the function prototype for TInterfaceList.Indexof being: function IndexOf(item : IUnknown) : Integer; The Delphi equivalent is: function IndexOf(const Item: IInterface): Integer; The key difference here being the 'const' which does not cause the reference count to change. This leads to an incompatibility between FPC and Delphi behaviours. | ||||
| Steps To Reproduce | Run the attached program, the output is: Creating logger Creating Calling indexof Destroying Calling init This should show the number 1 -> 0 (This may be accompanied by an AV as well) What would be exptected is: Creating logger Creating Calling indexof Calling init This should show the number 1 -> 1 | ||||
| Tags | No tags attached. | ||||
| Fixed in Revision | 43138 | ||||
| FPCOldBugId | |||||
| FPCTarget | 3.2.0 | ||||
| Attached Files |
| ||||
|
|
indexofbug.lpr (1,868 bytes) indexofbug.lpi (2,018 bytes) |
|
|
(also be interesting for documentation purposes. If this CONST behaviour with interface params can be relied on, it should be documented, if not already) |
|
|
Already. From https://www.freepascal.org/docs-html/current/ref/refsu67.html#x179-20100014.4.4 "This is particularly important and visible when using refcounted types. For such types, the (invisible) incrementing and decrementing of any reference count is omitted when const is used."..."This behaviour is by design." |
|
|
Technically, FPC could use the slightly more efficient constref. The documentation on callee side is clear, however, on the caller side there are some circumstances where the const-ness of the parameter causes a new tempvar to be created, which then has exactly the same lifetime issues. Delphi can (and does) run into the same problem, but it's much rarer. |
|
|
I added the const, ref count is now 1 on exit. Please check& close if OK. Thanks for reporting ! |
|
|
This is exactly the fix I was expecting to see. Works fine. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2019-10-04 11:25 | Bryan Wells | New Issue | |
| 2019-10-04 11:25 | Bryan Wells | File Added: indexofbug.lpr | |
| 2019-10-04 11:25 | Bryan Wells | File Added: indexofbug.lpi | |
| 2019-10-04 13:44 | Marco van de Voort | Note Added: 0118320 | |
| 2019-10-04 18:31 | Serge Anvarov | Note Added: 0118329 | |
| 2019-10-05 19:42 | Martok | Note Added: 0118354 | |
| 2019-10-06 09:53 | Michael Van Canneyt | Assigned To | => Michael Van Canneyt |
| 2019-10-06 09:53 | Michael Van Canneyt | Status | new => assigned |
| 2019-10-06 10:05 | Michael Van Canneyt | Status | assigned => resolved |
| 2019-10-06 10:05 | Michael Van Canneyt | Resolution | open => fixed |
| 2019-10-06 10:05 | Michael Van Canneyt | Fixed in Version | => 3.3.1 |
| 2019-10-06 10:05 | Michael Van Canneyt | Fixed in Revision | => 43138 |
| 2019-10-06 10:05 | Michael Van Canneyt | FPCTarget | => 3.2.0 |
| 2019-10-06 10:05 | Michael Van Canneyt | Note Added: 0118365 | |
| 2019-10-07 12:06 | Bryan Wells | Status | resolved => closed |
| 2019-10-07 12:06 | Bryan Wells | Note Added: 0118390 |
