|Anonymous | Login | Signup for a new account||2016-02-09 19:00 CET|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0006473||OCaml||OCaml standard library||public||2014-06-27 16:31||2015-12-17 15:09|
|Target Version||4.03.0+dev||Fixed in Version|
|Summary||0006473: 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.
|Tags||No tags attached.|
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.
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.
|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.|
|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).|
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.
|@gasche, @weis: can you please try to reach a consensus on whether this is resolved?|
|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|
|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|
|Copyright © 2000 - 2011 MantisBT Group|