Hi Luca,
I submitted the problem and my beginning of diagnosys (fscanf) to the
OCaml list.
The bug seems confirmed and someone has already written a patch for the
module Scanf.
Are you reading very large strings?
No, just small strings but many times (~100) and every a few seconds...
Very good catch anyway :-). This must not have been easy to isolate.
With a bit of luck it's easier ;-)
J.V.
On Mon, 23 Jun 2014 08:32:59 +0200, Luca Saiu wrote:
Hello.
On 2014-06-19 at 18:20, nore...@launchpad.net wrote:
Fixed a possible very critical memory leak introduced in revno
388. The problem was occurring in a thread calling the function
Linux.process.stat' repetitively in a loop. Strangely, the source of
the problem seems to be the standard function `Scanf.fscanf'. In a
way
that I don't understand, `fscanf' seems able to get the GC confused:
unused `Linux.process.stat' structures are indeed not collected
(even
forcing a collection with Gc.full_major). The workaround adopted
consists in replacing `Scanf.fscanf ch' by a `Scanf.sscanf line'
where
line' is read from `ch' by `Pervasives.input_line'. Now `stat'
structures seem to be correctly collected.
Interesting.
As a guess without looking at OCaml runtime source code, I'd suspect
this to be a buffering issue in fscanf, which gobbles up a large
memory
buffer as an OCaml string without releasing it, with the intent of
reusing it for the next read operation. By contrast sscanf takes a
string as a parameter which is explicitly supplied by the user, and
when
that gets unreachable it immediately becomes a candidate for
collection.
Are you reading very large strings?
Very good catch anyway :-). This must not have been easy to isolate.
_______________________________________________
Mailing list: https://launchpad.net/~marionnet-dev
Post to : marionnet-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~marionnet-dev
More help : https://help.launchpad.net/ListHelp
