New Ticket     Tickets     Wiki     Browse Source     Timeline     Roadmap     Ticket Reports     Search

Ticket #12022 (closed defect: fixed)

Opened 6 years ago

Last modified 4 years ago

BUG: port doesn't release (any?) memory

Reported by: flob@… Owned by: macports-tickets@…
Priority: Normal Milestone: MacPorts 1.8.0
Component: base Version: 1.4.42
Keywords: port memory leak Cc: pguyot@…
Port:

Description

After doing a selfupgrade from 1.320 to 1.442 and doing a upgrade installed after that in a new port-shell i saw port eating up my memory while doing noting than providing its shell after it finished its process of updating.

  UID   PID  PPID CPU PRI NI      VSZ    RSS WCHAN  STAT  TT       TIME COMMAND
    0 29148  1711   0  11 20  1331116 804640 -      SN+   p2   11:09.87 /usr/bin/tclsh /opt/local/bin//port

Thats about 800 MB of memory for a shell??????

Change History

comment:1 Changed 6 years ago by markd@…

  • Component changed from ports to base
  • Summary changed from port doesn't release (any?) memory to BUG: port doesn't release (any?) memory

See related ticket #12022.

comment:2 Changed 6 years ago by eridius@…

markd, you do realize that you linked this very ticket, right?

comment:3 Changed 6 years ago by eridius@…

It's unfortunate that there aren't really any tcl debugging tools. There's no way (that I know of) to figure out what's going on here without random trial and error.

comment:4 Changed 6 years ago by jmpp@…

  • Milestone changed from Needs developer review to MacPorts base bugs

Milestone Needs developer review deleted

comment:5 Changed 6 years ago by nox@…

  • Priority changed from Expected to Normal

comment:6 Changed 4 years ago by toby@…

  • Milestone changed from MacPorts base bugs to MacPorts Future

Milestone MacPorts base bugs deleted

comment:7 Changed 4 years ago by jmr@…

  • Cc pguyot@… added

I've narrowed down the memory usage problems to the filemap code. It adds about 160 MB to port's RPRVT each time it is used on my system. To demonstrate, open up port in interactive mode, run the activate, deactivate, provides or contents target, and watch your free memory disappear.

Note that it's far worse on trunk because it now closes the filemap when it's done with it (so more memory gets allocated next time it's opened). Upon closing, the variable is unset, FreeFilemapInternalRep() is called, and the ref count goes to zero, but no memory seems to be freed up.

comment:8 Changed 4 years ago by pguyot@…

  • Status changed from new to closed
  • Resolution set to fixed

Congrats on narrowing the bug to filemap code. Indeed, there was a memory leak there, which I fixed in r51419.

comment:9 Changed 4 years ago by jmr@…

  • Milestone changed from MacPorts Future to MacPorts 1.8.0
Note: See TracTickets for help on using tickets.