Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0006473OCamlstandard librarypublic2014-06-27 16:312017-03-15 11:37
Assigned Toweis 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0006473: Leak in fscanf
Description(Reported by Jean-Vincent Loddo on caml-list).

The 'memo' table in the Scanf module associates a lookahead buffer with each input channel: [^]

as explained by a comment in the Scanf code: [^]

Entries are added to the table for each input channel used for scanning, but there's no mechanism for removing entries, so the table only increases in size, retaining references to previously-used channels.
TagsNo tags attached.
Attached Files

- Relationships

-  Notes
weis (developer)
2014-06-29 20:22

Thank you for the bug report.

This problem was due to a short sighted implementation of Scanning.close_in. In the next version, calling Scanning.close_in ic will release the data associated with ic in the memo table.
doligez (administrator)
2015-02-06 20:22

Removing entries when the buffers get closed is a good first step, but not a complete solution because the user can just drop all references to the buffer (which then gets garbage-collected) without closing it.

A complete solution will have to use weak pointers.
frisch (developer)
2015-12-03 00:19

fscanf/kfscanf are now marked as deprecated. Was the leak only related to them? If so, one could probably mark this ticket as resolved for 4.03.
gasche (developer)
2015-12-03 07:42

No, bscanf also has the problem as soon as you open several scanning buffers per i/o channel (which is exactly what is done by code converting fscanf calls following the deprecation warning advice; sharing scanning buffers would require extensive reworking of the user code).
weis (developer)
2015-12-16 18:59

The memory leak is only related to fscanf/kfscanf and deprecating them removes the issue and closes the ticket.

To be clear, bscanf has no memory leaks and poses no semantics problems.

For sure, opening several scanning buffers for a given Pervasives.in_channel value is a bad idea and could create confusion. However, this bad idea only creates confusion in what you expect to read: what you get is correct.

The same problem already exists when reading with low level primitives: if you open more than one Pervasives.in_channel reading from the same file and then randomly read from any of those channels, you may have a hard time to understand what happens, but semantics is still ok.
frisch (developer)
2015-12-17 15:09

@gasche, @weis: can you please try to reach a consensus on whether this is resolved?

- Issue History
Date Modified Username Field Change
2014-06-27 16:31 yallop New Issue
2014-06-29 20:22 weis Note Added: 0011781
2014-06-29 20:22 weis Assigned To => weis
2014-06-29 20:22 weis Status new => assigned
2014-07-11 13:23 doligez Target Version => 4.02.1+dev
2014-09-04 00:25 doligez Target Version 4.02.1+dev => undecided
2014-09-14 21:49 doligez Target Version undecided => 4.02.2+dev / +rc1
2015-02-06 20:17 doligez Priority normal => low
2015-02-06 20:17 doligez Target Version 4.02.2+dev / +rc1 => 4.02.3+dev
2015-02-06 20:22 doligez Note Added: 0013247
2015-07-10 18:20 doligez Target Version 4.02.3+dev => 4.03.0+dev / +beta1
2015-12-03 00:19 frisch Note Added: 0014982
2015-12-03 07:42 gasche Note Added: 0014991
2015-12-16 18:59 weis Note Added: 0015163
2015-12-17 15:09 frisch Note Added: 0015172
2016-04-05 15:41 doligez Target Version 4.03.0+dev / +beta1 => 4.03.1+dev
2017-02-16 14:01 doligez Target Version 4.03.1+dev => undecided
2017-02-23 16:43 doligez Category OCaml standard library => standard library
2017-03-15 11:37 doligez Target Version undecided =>

Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker