← Back to team overview

marionnet-dev team mailing list archive

Re: [Branch ~marionnet-drivers/ocamlbricks/trunk] Rev 398: Fixed a possible very critical memory leak introduced in revno 388. The problem was occurring in ...

 

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, noreply@xxxxxxxxxxxxx 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.



References