marionnet-dev team mailing list archive
-
marionnet-dev team
-
Mailing list archive
-
Message #00707
Re: [Branch ~marionnet-drivers/ocamlbricks/trunk] Rev 398: Fixed a possible very critical memory leak introduced in revno 388. The problem was occurring in ...
-
To:
Jean-Vincent Loddo <loddo@xxxxxxxxxxxxxxxxxxxx>
-
From:
Luca Saiu <positron@xxxxxxx>
-
Date:
Mon, 23 Jun 2014 08:32:59 +0200
-
Cc:
marionnet-dev <marionnet-dev@xxxxxxxxxxxxxxxxxxx>
-
Face:
iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAHSK9QiAAAABGdBTUEAALGPC/xhBQAAABtQ TFRFAQQACQIAFQsHJxYPLiEZQCwhUzwrZkw2fmNLe/YH5AAAAAF0Uk5TAEDm2GYAAAABYktHRACI BR1IAAAACXBIWXMAAAsTAAALEwEAmpwYAAAAB3RJTUUH3QUPESENHT2abgAAAgdJREFUOMulU8Fy mzAQ3dhOzpXs3o2Q70GI9OoayPToNkj2uTXCx0ynBo4dt3H02ZEAEWg600PfjFieHrta7S4AFnuz ki1A+giA38EVQs02aICpBJiUZuElfEZzsznbNlp1WpvnRO1+GnM1zxbWIIYofEMW0GPWBfttn5NL 0Zj00rgX+6Uxm1xZE1BujYe998Yg9BFxmNpYGJg1c3iDa63X/TnawBGWJ2Hy2BEiZPV8dkSWsujI FFFRVBtHGixb4iHCvACvpM3IbC9sAiHMYuSAISY9QfAPpNvX90/6AsOsXZ5wY8iTI1GtToUjqyjh d+6qhItqd9tlTfO8rtukYUJVea+jjvhFqY5hR4g8qdrvCOLyWC4cIVEczx1B5rJ46wgxrD3I3Htu uoAjW5DAkNhDmKdd2RJbHQ43X5rC2BXCYdMXh0HMBnVj3oD8B+6PWuV/27eT0M7bCEndCPpPn9md bpXn9ViIV1WeJbssPf0YC4yyh5B/eMrScByJUCHLfK9V8f12KEwJVQYHUevzcihMrFCVuTjqX3Qs EFlUh0zkxzMZnU1IZGOpovzqjwRTTi6EUFXurYaC7QomFqZndOzxCjrM1mtdPDsPmHCpuvsFTdP8 MCRNl/1MyFEknjRfIMJDbv/PTd/qpLM+MyUT2ejoTvHhmofBWwH78MDIYGj6NwLJYJiGLi/+3YGI guOyYAAAAABJRU5ErkJggg==
-
In-reply-to:
<20140619162031.28384.73732.launchpad@ackee.canonical.com> (noreply@launchpad.net's message of "Thu, 19 Jun 2014 16:20:31 -0000")
-
User-agent:
Gnus (Ma Gnus v0.8), GNU Emacs 24.3.50.2, x86_64-unknown-linux-gnu
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.
--
Luca Saiu http://ageinghacker.net
* GNU epsilon: http://www.gnu.org/software/epsilon
* Vaucanson: http://vaucanson-project.org
* Marionnet: http://marionnet.org
Follow ups
References